Re: Logging - Best Practices
Rhino wrote:
I'm trying to figure out the best way to set up logging for my
development shop. In a nutshell, I'd like the advice of experienced
Logging isn't for development, it's for production.
Not that developers won't find it useful, but the focus on your
logging strategy should be to support maintenance in the field. That
will make it the most useful for other project phases as well.
Consider: A successful project should spend lots more time in
production than in development. In production, problems are always
urgent and tend to be expensive. The ability to troubleshoot and fix
problems in the field is commensurately important.
Design your logging strategy, including a *standardized* log-file
format, to support maintenance and troubleshooting in the field.
developers/designers to figure out how many logs I should have and where
I should set each one up. To clarify what I mean, please allow me to
Set up logging wherever it makes sense for each deployment
environment. There should be, generally, one log or set of logs per
deployed application.
sketch a hypothetical situation which would illustrate my concerns.
Let's say that my company is called Foo Inc. My Java development is done
using Eclipse. Various projects are on the go, including Baz and Fuzz.
There is also a body of existing code that does various useful things,
like general utilities.
... blah, blah, ...
The more general code is in its own project, Common, and is organized
into various specialized packages, including:
... blah, blah, ...
1. Should I make use of levels of Loggers here? For example, should I
Yes.
have a master Logger that contains all important messages written to any
package whose name starts with com.foo, i.e. any message written by any
of my classes that is of appropriate severity? And then have separate
Severity is adjusted in the field as problems or concerns arise, and
not fixed at design time.
... blah, blah, ...
2. Should there be a separate log for log records written by common code,
That depends. Consider if you were the sysadmin for the project in
production. Where would you look for logs? How many logs would you
want to wade through to find the important information? What
information should be presented, and in what layout to make relevant
data accessible?
Don't think so much in terms of packages as applications. You will
adjust logging levels in the field, i.e., long after development is
done, and then you will likely do so on a package-by-package basis
depending on whence the trouble emanates. Typically one logs at ERROR
or WARN level (thinking in log4j here) until there's trouble, then
drops to INFO or DEBUG for selected packages to narrow down where the
problem lies.
There is no static answer; logging is a dynamic beast. Don't design
logging like a programmer - we programmers are stupid about making
software actually work in real life. Think like a sysadmin - those
are the folks with the real brains.
--
Lew