Logging, when and what?

Question

I am currently working on a rather large multi tiered app that will be deployed overseas. Although I hope it won't fall over or blow up once depolyed I can't be 100% sure of this. Therefore it would be nice to know that I could request the log file, to work out exactly what went wrong and why.

So basically as the title suggests I would like to know when and what to log? I would like to know this to ensure I have comprehensive log files that can be examined easily to determine what has happened if my app falls over.

Answer 1

1 - Make a single log, with a standardized format. Doesn't matter much what it is, but ensure that ever entry has the same basic fields. Just calling "printf" probably won't cut it ( substitute System.err.println or whatever as appropriate )

2 - Allow for at least one field to be an arbitrary string... the developer will know better then you what needs to be there.

3 - Include a high resolution time-stamp on each entry. You will need it eventually, trust me.

4 - If possible, include the file and line number of the origin of the error. That's easy in C, and a bit of a pain in Java. But it's incredibly useful later on, especially when people start to cut+paste code, including the error messages.

5 - Ensure the log is at a place that any level of the code can use it.

6 - I've often used "Primary" and "Secondary" error tags, where "Primary" means "I'm the guy who detected there is a problem", and "Secondary" means "I called a function which reported an error". That makes it easy to find the source of the problem ( "Primary: file not found" ) and still report the meaning of the error ( "Secondary: can't load calibration table" ).

7 - Include some capability to log non-errors as well as errors.

The hardest part I find is when an error isn't necessarily an error. If you call a function with a file, and the file doesn't exists, is that an error that should be logged or not? Sometimes it's a critical failure, and sometimes it's expected. It's pretty much up to the API of the function; if the function has a way to return an error, I will usually have it do that without logging; then it's the job of the higher level code to decide if it needs to report that error or if it is expected.

Answer 2

First off, grab yourself a logging framework - you haven't mentioned any specific language, but any of the frameworks based around the Apache log4j would be a safe bet. The most important thing is that the framework supports different levels of verbosity (debug messages, warnings, error messages). You can configure the logger at run time as to which messages it will actually write, and to where - there's no point re-inventing the wheel to work with logging.

Implement your logging framework in your source. As a minimum, you should be looking to record and then "add value" to exceptions that can occur in your application. Writing a stack trace to a log file is all well and good, but it's very rarely enough to be able to diagnose the problem - consider logging things like the value of method parameters in a catch {}.

At a higher level, you can utilise the power of the different levels of verbosity to record what it happening in your application. This is especially useful if errors are only occurring on production systems where you can't attach a remote debugger - you can just increase the level of verbosity in the log framework config file, and watch as all your debug("Calling method X with parameter Y") messages appear in the log.