Logging Practices

Application logs provide information beyond, and separate from, what is presented to the end-user. The audience for application logs typically includes support personnel at all levels. Well organized and written log data can help with troubleshooting as well as being aware of, and proactive about, problems that occur.

Generally speaking, there are two classifications of log output: Errors and information about what the application is doing. Whenever possible, the code should attempt to anticipate potential errors and respond accordingly. Errors that are not handled by the code are referred to as unhandled Exceptions. Capturing and reporting such errors requires a different approach than reporting other log information.

Standard practices

The college has defined the following standard practices for configuring logging:

In production environments

• By default, Info messages and above should be written to the common log database.
  • When troubleshooting an issue, the log level may be temporarily raised in order to obtain more information about what the application is doing, but should be returned to the default levels as soon as possible.
• Log levels of Error and above - including unhandled Exceptions - should send an e-mail notification to those who directly support and/or maintain the application.

Log levels

Most logging frameworks, support 6 levels of log output. From the most serious to the least, they are:

Target		Level	When to use	Example(s)
DB	E-mail	Fatal	An error has occurred that the application cannot reasonably recover from. This level of error typically results in a message to the user suggesting they notify support personnel and/or try again later.
		Error	Either an Exception occurred - and was handled by the code - or an error occurred but the application was able to reasonably continue.	The application might retry a connection.
		Warn	The application has detected a situation that could result in an error or unexpected behavior later. An Exception may also be logged as a Warning if the developer deems it is not serious enough to cause an actual Error, but should still be noted for troubleshooting purposes.	A database query returned multiple records when only one was expected.
		Info	Information that may be useful to those monitoring the application under normal conditions.	An upload has completed. "XX records processed."
		Debug	Information that may be useful in troubleshooting and/or monitoring application behavior which 1) would be too verbose for Info and does not meet the criteria specified for other levels.	"Beginning upload."
		Trace	e.g. verbose. Every little piece of minutia added in the course of troubleshooting an issue or researching functionality. ALSO any sensitive information (such as authentication credentials) in the rare situations where it may be needed. Never log sensitive information under any other level.	Current security context. Output of each iteration of a loop.

See also

• Logging Practices for .NET