Guidelines for logging (tracing) in a Windows application

Question

As I see it there are two different types of logging:

• User-focused logs, like those produced by my anti-virus ("started scan", "no threats found", etc.)
• Developer-focused traces, which may be as simple as a log of exceptions or as detailed as a log of every method call

I'm currently planning how to incorporate the second type of logging into our application, so that we are able to get some record of what went wrong when a user reports a problem. I've seen several discussions of how verbose these traces should be and of available frameworks, but here I'm looking for some more general guidelines.

Particular questions I have include:

• Should we be logging to a file, to the Windows Event Log or somewhere else? For these developer-focused logs that are probably of no interest to the user, I feel that a file would be most appropriate. But in that case:
  
  
  • Where should the file be located?
  • Should we implement some form of log rotation to prevent the file growing too large?
  • How can we handle multiple instances of the application accessing the log simultaneously?
    
    
• Should this tracing be switched on by default? If it is, I am a little concerned about performance; but if it is not, will we end up responding to many users' issues with "turn on tracing and try to reproduce the problem"? This doesn't sound too helpful.

I hope you can help me with these questions. I'd also appreciate any other advice you have on this topic.

Answer 1

The Art of Logging has some helpful guidelines.

For logging, I'm using Simple Logging Façade as an abstraction for the real logging framework used.

More info:

• An Introduction to SLF, the Simple Logging Façade
• SLF Hands-on Tutorial, Part 1

Answer 2

You should use an established logging framework for the platform if it's available. For log4j (java) , log4net (.net) etc. Most established frameworks will have ways of increasing and decreasing the logging (and thus affecting performance) in very precise ways. You would have to replicate all of this.

If not, the the ETW (event tracing for windows) is a highly performant logging system built right into windows. And I'd recommend it in each case where the logging framework wasn't available.

Oh and don't worry about performance until its an issue (this doesn't mean don't think about it, just don't micro optimise till you need to).

Answer 3

I've found log4net very effective. I normally use both a rolling file appender in the log4j XML format that can be read and display neatly by Chainsaw and another appender that logs directly to the debug console.

Logging level can be easily set in an XML file. For distribution I turn the logging level to Info or off completely. In the case of a problem this can be turned back into debug.

I find it powerful because it logs both the thread and the function the log entry was called from.

Answer 4

I would agree that the Windows Event Log is an improper place for developer logs. While they serve as a convenient logging location exporting log information is somewhat problematic and ultimately I feel that the Event Log should only used to log information of concern to the System Administrator.

As far as where this file should be stored, wherever the location be aware that Windows 7 and Vista are making a move towards further isolating Users which means that writing to the Program Files folder will require administrative privileges. Work with this and do not require that the application be run as an administrator. Beyond that I have no recommendations.

I'm not sure what kind of application you're working with but I've found that too much random trace information is useless. I would spend most of my efforts identifying large portions of code that only make use of very limited set of information. If done properly this will allow you to reproduce most runtime errors with as little as a single trace statement. This would also effectively make the log size insignificant.

Unless multiple instances of the application interface with one another they should keep separate log files. There would be no reason to combine log information of two entirely separate processes.

Full fledged tracing should be off by default. If a customer reports an error that you cannot reproduce you should then recommend they turn on trace information so you can further identify what the issue might be.

Answer 5

You might wish to use Enterprise Library Logging Application Block. This is a simple configurable logger with many many easy-to-use features. Following both links above will make you functional in no time.

Answer 6

I suggest using an existing library such as log4net or Ent lib Logging application block.

Personally the Logging application block was overkill and to complicated for my purposes.

Any exceptions should be logged by default and you should have the option to enable a verbose tracing / logging mode for the strange issues you are unable to gather enough info on with the standard exception logging.

You never know what will go on when users are using your code. the more info you have to find and fix problems the better.

Answer 7

I think you should consider centralized logging and direct all you logs into one location. The bigger and more distributed your application becomes the harder it's getting to manage the logs and understand what is going on and what happened. It's particularly true about magnitude of the log files and decisions you have to make what goes into each one and when. If you are using log4j or some of it's flavors, have a look at logFaces, it will spare you the time dealing with log files, formats, race conditions and storage concerns. It only deals with application logs though, if you need to consolidate all sorts of logs from infrastructure, consider looking into bigger solutions (like Splunk?) which aggregate any log data.