What should I log in production app

Question

I'm starting up a new project and am thinking of what things I should be logging. The logfile is only intended to help developers find bugs. The use case is that when an unhandled exception is thrown a notification is send to the developer, who have access to the logfile and stacktrace.

What things should I include in the logfile? Logging everything isn't going to work. I know it's difficult to say, as the answer probably requires deep knowledge about the system. So I guess I'm really asking for "best practices". Please give specific examples.

Also does it depends on the application type such as desktop client application, desktop server or a webserver?

Answer 1

I have two separate environments where the logging requirements are totally different.

1. Office application

Here we log exceptions, common things like login , app start etc plus the editing/deleting/insertion of objects. Enough to check what happened when things go boom. We log enough to be able to reproduce the case. The log is allowed to grow unbounded in our case so we can check for problems way back.

2. Industrial application.

Here we log almost everything plus the kitchen sink. This is softeare that needs to run 24/7 so even a simple warning can be a hint of coming disaster. An example is that we had some strange timeouts and did not meed some time contraint requirements. In the end the logfile gave us the informatio: saving a textfile of a few 100 bytes sometimes took more than 5 seconds. Usually the problems that present themselves are things that you didn't think of at all, so logging, logging, logging is what you should do! Logs are automatically cleaned after a few days.

What we also did is implement a loglevel that the end user can set: if set to verbose, we save all logging, if set to minimal only errors come through. SO after a few weeks of stable running we slowly decrease the log level towards minimum and stop there were we are comportable with.

So I would say: It depends on your application.

Answer 2

In general

• If you log DateTime values (not talking about timestamp header fields of logging frameworks) make sure you log them in a meaningful format. "ToString()" usually is not sufficient if you need information about Local vs. Utc or about milliseconds (I use "yyyy-MM-dd HH:mm:ss.fff zzz", YMMV)
• If you log exceptions, go for "ToString()" rather than anything else. Controversial maybe, but look here for reasons.

About senstive or detailed information, as others have already said, you have to watch out. It is not only about people who are entitled to read your production logs getting more information than necessary, also think about the case that any intruder to a system can get valuable information for overly verbose logs (which is why I wouldn't log a set of users permissions with the error that he hasn't got a particular one, was was suggested in another answer).

It might depend on your environment or customer what is considered sensitive, but examples are: - Actual user input in error messages. - User permission sets, etc. - SQL statements, especially with actual parameters - XML request/response structures

Finding the right granularity of information to log is always a tradeoff between the amount of information logged, the performance it costs to not only write but also to produce this information in code and the senstivity of that information. And that is the reason why any serious logging system sports "levels" or "categories".

You could log potentially senstive information at a "level" or "category" that can be switched on in development but off in production. If you really want to go overboard, you could write an EventLog entry when your application detects that such logging is enabled, so it doesn't "slip" through in production.

Finally, consider using a logging framework that allows changing those levels or categories during runtime. This way, you can enable more information if required, in a controlled way without disrupting the application's work or resetting a situation that you wanted to inspect by the need to restart the application first.