A few days ago the subjects of logging and tracing came up with a fellow architect and coworker. Too often I find that one person’s logging is another’s tracing or that what’s batted around as tracing is just verbose logging. Are the terms synonymous or do they support unique requirements?
From our discussion, the consensus seemed to be that tracing requirements are indeed different than logging requirements. Tracing is typically used by off-site technical support via customer enablement on-site to diagnose where a problem occurs. A trace represents a path through the system simultaneously in great detail and no detail at all. (You see entry and exit points, but you typically don’t get a sense of the processing in between the two.)
More importantly we agreed that a significant issue with logging implementations today is the lack of context or perspective applied by developers in determining what to log. Too often the customer is left with too little to too much information, or worse yet only irrelevant data or relevant data without critical context. Here are some questions you should consider when implementing logging:
- Who are the consumers of the logs you produce?
- What are their viewpoints of the system generating the logs?
- Does logging support preventative measures?
- Does it support post-mortem analyses?
- Does it support ongoing SLA verification and fine-tuning?
- Are all errors or warnings in your system equal?
- Is a warning in one part of the system a precursor to a critical failure in another?
- How can you categorize your system to log based on logical or functional domains?
Coincidentally after our conversation, my route back to my office took me past the mailslots. There in mine was the issue of InfoWorld where Jon Udell penned The Artful Logger (and added more perspective in a follow-up blog post).
As Jon says, in the end, logs should tell a compelling story.-Craig