Published May 20, 2020
10 Steps to making a great log message!
- Timestamp – This may seem obvious, but many log files do not have time stamps. And to ensure that they can be consistently used, timestamps also must have a time zone or be set to a standard time zone, such as UTC.
- Host/VM Source – The name or IP address of the host where the log message is emitted. Developers need to know where messages are coming from, especially when running in dynamic VM/container environments.
- App Source – The name of the part of application module reporting a message. This could be a class name, module, or some other string. The source must be easily identified by developers so that it can be quickly mapped to source code.
- Log message – The actual message the describes what the application is trying to communicate. Log messages should not be just free text, instead they should use token/value pairs to make it easily on log parsers. Example: “Failed request name=X, stats=Y, varN=ValueN” is much better than hiding these tokens into a sentence. Avoid using highly verbose message sentence structures.
- Message code – Application specific message codes should be prefixed to every message. Message codes allow quick message identification and makes log message management a lot easier. Example: “LOG1001: Failed request…” is much better than “Failed request…”. A message dictionary can be extremely helpful in managing messages and codes.
- Severity – Is the message debug, trace, error, fatal? Most logging platforms also allow you to extend severities to user defined levels. Generally built in severities will be sufficient in most cases.
- Correlator – A string that allows multiple log messages to be tied together to a common request or process. Typical server applications process requests from multiple users. Printing out log messages without a correlator makes it impossible to connect what log messages are related to which request. Include a correlator into your log messages to make it easy to identify related log messages. Log analytics tools make use of such correlators to group related messages.
- Stack Trace – Developers want to know the code path when critical problems occur (such as an exception). Always include a stack trace along with the error message.
- Elapsed time calculation – Often log messages are used to mark the beginning and end of an activity or requested process. Include a correlator and elapsed time in the message that marks the last step in the process. This makes it a lot easier to spot trouble areas or performance problems. Example: “LOG1001: Process request=Correlator, elapsed.ms=3281”.
- Input arguments – Developers should include important method input attributes into log messages to quickly identify problem areas. Often failures occur due to unexpected input attributes. Include them into your messages to help with problem determination and make log messages more useful.
- Tags:
- app source,
- log message,
- stack trace,
- timestamp