Logging is Key to obtaining visibility into the application’s performance. Every application should log in order to provide visibility into Application Execution.

Logging should be configurable at various levels – Informational, Warning, Errors, Success Audits and Failure Audits. It is recommended to use an ECL while logging from within applications, even across platforms. While it is ideal to log to the Windows event log or a database table, logging to a Text File is acceptable under exceptional circumstances. Understand that file I/O happens in all cases, however, directly logging to a file is an extremely single threaded activity.

In any event, the Fire-and Forget Model (Asynchronous Logging) should be utilized or Logging will impede the primary thread of execution. The Enterprise Instrumentation Framework (EIF) in Windows has a Fire-And-Forget Event Logging Model. A good example is the EventLog.WriteEntry method in the .NET Framework. An application can initiate numerous logging requests in multiple threads. All the requests are queued and control returns to the primary invoking thread almost instantaneously, ensuring that logging will happen, but in a lower priority thread, thus ensuring performance.

In any case, Logging does otherwise have a performance impact. Therefore, informational message logging should only happen when the application is run in Debug mode during troubleshooting. Logging to a Database is also permitted, as long as it is not performance intense (Append only – No Key Lookup) and asynchronous.

Documentation is also key to visibility. It should be mandatory for applications to use standard, well-defined error codes on a per-application basis. These should be documented centrally and made available to the Production Support team as it will aid them in both identifying the error and route the corrective action accordingly.