Good application logging is invaluable to a well-functioning application team. From troubleshooting problem incidents to collecting and plotting performance trending, good logging is one of the best ways to track application health. Better logging will set you apart from the rest, and give your operations staff the tools it needs to succeed.

Good application logging is:

  • Complete: Each line contains the event timestamp, log level transaction ID, and other relevant transaction processing data such as user or account ID, IP address, other logical application addresses.
  • Regular: Each line follows the same format and order of fields. Timestamps and other data items are all in the same format. If lines don’t follow the same format, parsing will be difficult.
  • Leveled: Each line will record the log level (DEBUG, INFO, WARNING, ERROR) that is appropriate to the event logged. There should also be a way to set the application to only record log messages above the specified level.
  • Coded: Error and warnings will have numbers or specific messages to categorize them each by type.
  • Documented: There will be a legend available to look up log error messages and error/warning codes.

Inferior application logging will cause the staff to disregard the tool. It’s similar to spam in an inbox. Sometimes the problem with log data is that they include too much data at the normal log level. Extremely verbose messages should be reserved for debug level logging. What we shouldn’t see is log messages that appear and no one can explain except to say, “That should be no problem; we’ve seen that before.” Every message should be explainable. And the “INFO” level should record meaningful transaction data, as well as WARNING and ERROR level data, but not DEBUG data.

If your programmers can adhere to these guidelines when they develop applications, the application will be a much healthier and easy to diagnose application.

© Copyright 2020 Rex Consulting, Inc. – All rights reserved

Logs