What should I log in production app_问答_开发者

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?

First rule is "Don't log sensitive information!". For example: social security number, credit card numbers, passwords etc ... You don't know who may get permissions to see it and this can bring you some legal issues.

It is useful to log communication with third party components (for example web services or so..). You will be able to provide useful information to the third party vendor or to you if a problem occurs.

It is useful to track very briefly the actions that users make ... going to particular page ... doing somethings. So if a client calls you on the phone and says there is something wrong with your product - you can check what he is doing now.

In our company it is a common practice to track how much a database query takes to complete. This is the way to identify bottle-necks sometime or to identify some problems with your system (application server or database server).

You can track also some attempts to break your system DOS attacks, brute force bots ... and so on.

Hope that helps!

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

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.

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.

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.

Have a look at the documentation for something like nLog. It will give you some ideas as to what you should be logging and how this can be controlled.

Log the name of the method that threw the exception and any parameters it was using (i.e. state). Log the user's ID and privileges. In a web scenario, log the IP address and headers.

Logging is your Saviour when it comes to "all hell broke loose" situation in production. As you said it does require more knowledge of the application but over all your should think about couple of things.

Log every exception and errors. Nothing should escape.
Consider logging user login and logout action. This is a good info to have to monitor your application for malicious attacks and stuff.
You can surly not log every method but you if the system is designed right and if you have single point of entry for your communication between n layers then you can log that method. i.e. Save , Delete , Update methods etc.
Also provide some logging inside if#debug code so that you can turn the debugging on in production and produce more logging if needed. This is very helpful specially while working in dev environment and debugging production database.