Effective Logging

I’ve been debugging a lot of different code lately, and it has helped me remember the importance of logging in an application. Especially when you application is going to be used in the real world. You can plan, and code, and try to account for every situation that might happens, but eventually something you didn’t plan on will hit, and if you have logging, you can use those message to trace down the cause of your problems. However, it isn’t enough just to be able to say “Yeah, my app has logging”. You have to make sure you have logging in the right places, and that it is reporting the right information. Without those two conditions being met your logging can be next to worthless. The worst thing that can happen is for your logs to be ignored because they don’t give useful information. These are my suggestions for making sure your application has effective logging.

1. Put logging into your application - Yes, this is very obvious but it is something that needs to be said. An application that dies without telling you anything doesn’t really help you very much does it? Put logging messages in it! Even if you have to resort to just printing out messages to the command line, this is better than nothing. There are plenty of good logging solutions out there (like Log4J), check them out and try to integrate them into your application.
2. Put logging messages in the right locations - The number one problem that developers seem to have with using logging messages is that they print out too much. Most of the time this is because the logging messages aren’t put in the most effective locations. What is an effective location? Any place where you find yourself setting a break point is a good rule of thumb. Other good spots include: + Catch Blocks (because its nice to find out quickly what caused that initial exception) + Business Logic Layer (errors in this layer are hard to pin down) + Any spot that has external I/O (disk reads, network calls, these can all fail for many reasons) + Sections of complicated logic (if its hard to understand when you are writing, imagine trying to understand it when you angry customer is breathing down your neck to get the system back up and running)
3. Make your log statements count - You’ve got to get a message out, make sure you communicate the right things. If you app runs in a multi-user environment (like a web app), then maybe the log message should include the user’s name so you can track down and monitor a particular user’s situation. Where in the code was the message generated? (Some logging solutions like Log4J take care of this for you.) If you had to have this message read to you over the phone at 2 in the morning, what info would help you diagnose the problem the fastest?
4. Log consistently - Once you start logging, make sure you log everywhere. If you and your support staff get used to good logging from one module, they are going to assume all modules have equally good logging. Don’t disappoint them! Logging statements should be uniform both in format and in usage through out the application. Also, make sure your logging statements are all being written to a single location. The more places you have to hunt to find a message, the less likely you are to go find it.

As I said earlier, there are many logging solutions available no matter which language/editor/environment you are coding in. A good spot to check out is the Apache Logging project. Another bit of advice is to become fluent in tools like grep. Log files can get large, but grep and other tools can help cut the job down to a manageable size. Most importantly, remember that while it is a pain up front sometimes, the logging messages will pay for themselves when things go wrong. Notice that I said “when” and not “if”. So get your logging in place!