OnelineLog - Logging for Production
Every piece of code uses logging to tell the outside world what is happening inside - some verbose, some limited with their use of words. Nevertheless they talk all the time in a 1-way communication. It is as if they are making up for their creator's absence to tell about the glory and gory details of their existence.
Logging has to be done for 2 things:
1. Provide feedback about its performance so it can be tuned till it is most efficient
2. Call loud and clear when in need of help
This has to be done with minimal overhead to application performance or system resources.
As a side note log messages for tracing like "entered helloworld method" have no place in the final production executable code. They have to be ripped out of the code before it is checked in.
Feedback about performance
This data is primarily for analysis and the best place to store such data is in a structured way - something like a database. Data in a database is ready for analysis - why should there be log parsers to cull out such data from log files into a database or excel? Why not just log it in the right place? I can hear "a database write for a log record - that's so non-performant" and it contradicts the statement of "logging to be done with minimal overhead". But are database inserts that expensive? Yes if they are done one insert after another but when they are done in bulk - remember? databases are designed for set processing - it is not an overhead on the system. Obviously this should be done on a separate thread and in bulk. Our results on database performance and comparison of onelineJdbc with iBatis and Hibernate is here. I have done it in a previous application and it gives comfort to know that system is operating at 40% capacity.
Call For Help
An application should call for help when needed and never else. When it does it should be loud and clear with all details and how things can be fixed or corrected. Assume the code is decent enough not to swallow exceptions and making sure it has got all information before providing any service. In such a code any exception or error starts and ends with a single transaction. In that case all information regarding a transaction and its progress can be collected in memory. In case an error happens all this information is written to the log file otherwise it is discarded. At this time the application can also record any measures that can be taken for recovery if these are anticipated situations. Support team will thank you for these little considerations.
We are developing onelineLog to meet these 2 requirements, will announce when it is ready.
Btw have you seen a system designed from a support team's perspective? Let's talk about it in the next post. Until then good reading.
Below are links to some blogs from Hani Suleiman (of the bileblog fame) on logging. Not the best language for public consumption - you have been warned.
http://www.bileblog.org/?p=22
http://www.bileblog.org/?p=119
http://www.bileblog.org/?p=52
Comments
I don't quite agree with the suggestion of stripping off debug messages before checking in the code. In fact there are cases where these may be helpful. What if the application has falws in logic as opposed to system errors. We then have a situation where the business users are crying for help in stead of the application :) Many logging framework allow configurable capabilities to turn off debug logging without having to make code changes.
On the other hand, I agree with the concept of database logging. As long as it is carefully designed [make it asynchronous and do it in bulk as you suggested] there should not be a performance issues. I know some people cry a lot about overhead :) but then they need to ask themselves "how much is too much"!