What is the best practice in using log4j levels while coding. I mean when do we use INFO logging, when do we use DEBUG logging / ERROR logging etc.
问题:
回答1:
The best way to learn is by example. Read source of some open source things, like, oh, Tomcat or whatever is in your application area, and see what you see.
回答2:
In general, I follow these guidelines:
- DEBUG : low level stuff. cache hit, cache miss, opening db connection
- INFO : events that have business meaning - creating customer, charging cc...
- WARN : could be a problem but doesn't stop your app. email address not found / invalid
- ERROR : unexpected problem. couldn't open db connection. etc...
回答3:
My baseline is always that INFO level is equivalent to System.out, and ERROR is equivalent to System.err.
DEBUG - Here you put all your tracing information, and specifically information that you don't want to see when your "comfort level" is system.out.
INFO - use this one for general messages, progress messages, for application related messages, but not for tracing.
WARN - provide alerts that something is wrong, perhaps unexpected, or that a workaround is used, but the application can still continue (socket timeout/retries, invalid user input, etc.).
ERROR - alerts about problems that prevent your app from continuing normally, e.g. database is down, missing bootstrap configuration.
A common mistake when writing libraries is to use ERROR level to indicate problems with the calling application (the code that uses the library) instead of indicating real errors within the library itself. See for example this hibernate bug -> http://opensource.atlassian.com/projects/hibernate/browse/HHH-3731
This is really annoying because messages from ERROR level are really difficult to suppress, so use them only to indicate problems with your own code.
All - I don't really use this one, it is practically the same as DEBUG or TRACE.
回答4:
Despite this question is pretty old, this is really an important point that every developer should know, I highly recommend you to check the official page of Apache log4j.
Also I have found and useful image that describes this perfectly, log4jImage taken from supportweb.cs.bham.ac.uk/documentation/tutorials/docsystem/build/tutorials/log4j/log4j.html
回答5:
TRACE: The least level of log. Provides most detailed level of information.
DEBUG: Log statement here are meant to help developers. Detailed state of your application.
INFO: General business information. Progress and state of your application
WARN: Warnings about unexpected events. These are not serious enough to abort your application.
ERROR : Serious problems in your application.
Also having the right level of logging turned on in different environments is equally crucial.
回答6:
ERROR logging should always be on.
INFO + DEBUG should be on when tracking down problems/bugs.
回答7:
To what others mentioned, I'd add TRACE and FATAL levels, the former is good for very verbose logging, the later is to indicate total show stopper. There are general guide lines on how you use levels, as mentioned by other above. However, the most important is how YOU will use it and how your USERS will interpret them. You need levels to focus on problems, so decide what is the problem in your case. Your users will hardly ever need trace or debug statements, but they will definitely want to nail problems and report them to you.
回答8:
Here are some guidelines I use:
- TRACE: verbose logging for very low level debugging, things I would not normally need to see in a log unless there is some very obscure or unusual issue.
DEBUG: logging intended for developers' eyes only - contents of variables, results of comparisons, and other bits of information that help debug business logic.
INFO: high level information such as task X is now complete or some rule is satisfied and here is what I'm going to do next because of that rule.
WARN: there might be a problem but it's not severe enough to do any real harm to the flow of the business logic. For example maybe some variable is sometimes going to be null but we don't necessarily need it or we can work around it somehow. At the same time we still want to know about it just in case we're told later we need to find examples of it or investigate more carefully why it happens.
ERROR: A serious problem that definitely needs to be investigated further, but not serious enough to stop the application from accomplishing the task at hand.
FATAL: A very serious unexpected problem that we can't work around or recover from and may even prevent the application from doing something useful.