Is there any reason not to include issue numbers in debug logs?

Question

I was going through the answers to this question:

What information must never appear in logs?

And noticed that nobody mentioned this particular attribute. It's something I find useful- whenever any logging is added to the system as a result of tracing a particular issue raised in the bug tracker, or adding a feature, I tend to include the ticket number of the related helpdesk element.

This means that when going through the log, any programmer can cross reference each log message with the associated ticket number. Now I understand that using proper VCS/helpdesk integration means most commits are attached to a ticket number anyway- but over time it makes it easy for us to diagnose problems on inspection whenever a log message comes up.

However it still makes me a bit uneasy leaving this in the logs. The problem is, I can't think of a scenario where this could become a problem. I'm hoping SE can help me out.

By the way- I'm talking about the "verbose" log level. This is never done in a logging level that will appear in production.

Answer 1

I can't think of a scenario where this could become a problem

In my past projects, I've been through 3 or 4 bug tracker migrations that changed (invalidated) all the bug IDs used in prior tracker.

Within bugtrackers themselves, that wasn't a problem since back-references to older issues at prior tracker were easy to discover. But I can easily imagine it making a major headache when posted in a plain text application log, especially when there will be mixes of "old" and "new" tracker IDs.

• known issue, details in PRJ-12345
  refers to old tracker used before Jun 2012
• known issue, details in PRJ-23451
  refers to new tracker used after to 2012

It would be quite difficult to figure which of (two) trackers above messages refer to.

I find that it's better to just make sure that log messages are unique, ie guarantee that developer will be able to track the message back to single point in source code (more on that below).

At that single point referred from logs, one can use comments to point reader to exact URL of the respective issue when needed.

    // known issue, details in http://oldtracker/PRJ-12345
    // known issue, details in http://newtracker/PRJ-23451

---

Side note, a "nice" example of what is bad about not having unique log messages is a Tomcat bug 27988 Unhelpful FileNotFoundException. Its description sounds like a royal road to maintenance nightmare...

org.apache.naming.resources.DirContextURLConnection raises FileNotFoundException on lines 311, 344, 382 and 396. It would be more helpful if these provided a message string

...and in my experience, it really was a nightmare.

Guess what happens when your application crashes with braindead file not found and there are (at least) four reasons for that and log doesn't give you a slightest idea what could really go wrong there.

Amount of curses I sent over to Apache developers is hard to count.