Question

As Jeff Atwood asked: "What’s your logging philosophy? Should all code be littered with .logthis() and .logthat() calls? Or do you inject logging after the fact somehow?"

Answer 1

My logging philosophy is pretty easily summarized in four parts:

Auditing, or business logic logging

Log those things that are required to be logged. This comes from the application requirements, and may include logging every change made to any database (as in many financial applications) or logging accesses to data (as may be required in the health industry to meet industry regulations)

As this is part of the program requirements many do not include it in their general discussions of logging, however there is overlap in these areas, and for some applications it is useful to consider all logging activities together.

Program logging

Messages which will help developers test and debug the application, and more easily follow the data flow and program logic to understand where implementation, integration, and other errors may exist.

In general this logging is turned on and off as needed for debugging sessions.

Performance logging

Add later logging as needed to find and resolve performance bottlenecks and other program issues which aren’t causing the program to fail, but will lead to better operation. Overlaps with Program logging in the case of memory leaks and some non-critical errors.

Security logging

Logging user actions and interactions with external systems where security is a concern. Useful for determining how an attacker broke a system after an attack, but may also tie into an intrusion detection system to detect new or ongoing attacks.