The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

What to log

Does anyone have any advice about where to find information about a logging strategy?

We have developed a number of web applications, all of them seem to be logging different things.

All articles and books I find about logging are to technical (log4j, jakarta-commons, etc.). What I am looking for is advice on what to log not how to.
Kristian Send private email
Thursday, December 13, 2007
 
 
Ask the people who need to use the logs to do their work; most probably the people who support these apps. Ask them what they want/need in the log, often this isn't the grab bag of random debuging output from bugs long fixed...

I've blogged about this kind of thing, here: http://www.lenholgate.com/archives/000033.html and here: http://www.lenholgate.com/archives/000438.html
Len Holgate Send private email
Thursday, December 13, 2007
 
 
People generally don't want a lot of logging, right up to the day that they have a crash, and start complaining that the logs don't have enough detail to find out what happened...
xampl
Thursday, December 13, 2007
 
 
Since you have conditional loggers, you can log anything that seems useful. A lot of (good) logging is really quite valuable and doesn't disfigure the code. If you have a distributed logging mechanism (with severities, notifications, etc) then logging is really quite powerful. Its great to be able to data mine months worth of logs or keep a personal dashboard of alerts you care about (personally responsible for those projects). Just use your best judgement, but lean towards being more liberal than conservative.
Benjamin Manes Send private email
Thursday, December 13, 2007
 
 
May be just add when you feel it is needed, remove when you feel too much??
Carfield Yim Send private email
Thursday, December 13, 2007
 
 
Some personal preferences:

Log properties, switches and options at startup or first time used.

Log nothing else when things are going well. A log that grows at 0 lines per day is sweet.

Don't grep your log to count successful transactions or whatever; write another output for general info.

Build a fine-grained ability to turn logging on and off in components, classes or methods of a running system - no restart to pick up config changes. "debug", "info" and "error" are too large grained if they affect a whole system.

Build a way to view the last n log entries (circular buffer maybe) without downloading files or logging into the server.

Write consistent messages on errors, with content aimed at the intended reader. With small, well named  methods, a message of "Class.method exception=" + e is enough.

Any of that sound useful?
Stan James Send private email
Saturday, December 15, 2007
 
 
"Any of that sound useful?"

It sounds like log4j :)
Dan Fleet Send private email
Sunday, December 16, 2007
 
 
Personally I like to have my application create two types of logs. Both types use log4j to drive the messages but the target audience is different to some extent.

The first is a log that is specifically targetted at the people who administer the application. Developers are envouraged to think of things that reasonably could go wrong and log them to this log. All log messages for this log come from a resource bundle and have a unique ID, we give the admins a list of these messages along with a description of how to rectify the problem. This logger only supports INFO and above, no DEBUG or TRACE levels.

The other type of logging is the standard class level log4j, the intent here is to use this for TRACE and DEBUG levels and developers should log as much information as they expect would be required to resolve an unexpected problem. This logger should not log at INFO and above, use the first type of logger for this.

Admins use a standard log4j properties file to control logging levels and can split the two logs into seperate files for better monitoring of the information they need to do their job. We monitor changes to the log4j properties file so they can change settings on the fly at runtime if we need to debug a problem.
Gerald
Monday, December 17, 2007
 
 
To the OP: You may want to consider having several log files: 1 for database-related errors, another for errors caused by any framework you're using, etc.
Full name
Thursday, January 03, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz