My father speaks on logging

After reading a recent article on logging, and when you should and shouldn’t do it, I asked my father for his views. He has about 25 years of experience in both small companies and large corporations, and got me thinking about some things that I hadn’t before.

Here is his message:

—-

“This is a subject about which there are (obviously) religious wars. If you don’t have it when you need it, you regret it, because you end up spending days or months adding it, to find some problem.

If you have it, its use needs to be controlled. Program flow tracing, or logging variable and argument values, (DEBUG level IMO) is something that one should be able to turn on and off at will (potentially at a subsystem, transaction type, service call, class hierarchy, or function/method call level), and should go to separate log files. The cost of this level of logging can be huge (in both performance and system resources… CPU _and_ DASD, as well as analysis resources).

Logging inputs and outputs of services, where transactions MUST succeed, is a very good idea, if one is to be able to recover from system errors, and one does not have another “back channel path or reconciliation interface” that guarantees you can recover.

When you have business requirements for measuring and reporting and system and component performance, sometimes down the the transaction level, you need a mechanism for doing this that is FAST, failure tolerant, AND does not involve locking exclusions. The mechanism we developed, involved dropping messages into an MQ Series Q, and then having a listener (Message Delivery Bean) on the Q, pick up the messages and write them to a database, which is then dumped nightly and sent to an analitic data store. Data is keep in the operational database (for triage purposes for 45 days on average). If the MQPUT operation fails, the system reports an exception (logged to file system, and sent to an operations monitoring console), and then continues.

Simple systems need less logging than more complex systems. And don’t forget that logging at least service inputs and outputs, can be a good way to prove to a client L2 or L3 triage team that inputs to your service were bad, or proving that the outputs were good. Similarly for called services (as a client). Logging the outputs and inputs, enables one to prove a services was called correctly, but generated bad results or failed. Needless to say, all logs for any transactions, need unique transaction identifiers (TraceIDs) typically, UUIDs a good choices for this.”

—-

It runs in the family:

My father(and mother) has always challenged me to evaluate all sides of a situation, and in the end, I believe his most important message is that every system has different requirements, and every system will require different levels/degrees of logging. You need to analyze what is right for you, because if you mimic someone else’s system blindly, you will surely be missing some chances to get a logging system in place that provides what you need without becoming needlessly cumbersome. I’ve tried to take this to heart when working on all of my projects with OcpSoft, and my own pet project of PrettyFaces for JSF; needless to say, it’s hard what we do. There’s a lot to think about, and in order to be at our best, we have to continuously analyze as many angles as possible. Logging is no exception.