Guidelines for logging (tracing) in a Windows application [closed]

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

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).