10 Logging best practices

 

This chapter covers

  • Applying log levels to filter and prioritize actions
  • Identifying characteristics of good logs
  • Easing operational activities with good logs
  • Understanding the impact of legislation on logs
  • Coding practices for improved logging

The technology used is only as good as the log events themselves, regardless of how log entries are generated, whether applications write to stdout, stderr, OS event frameworks, or logging frameworks. To maximize the technical investment, we need to make the log events and their creation as effective as possible.

We have delved deeply into the technology, so we need to do the same for log events. This chapter will explore what should and should not be logged in terms of business data, and it will examine what information can make log events more helpful. With that, we’ll identify some practices to help get values from the log events. The business data our systems process can be subject to a wide variety of contractual and legislative requirements. So we’ll look at some of the better-known legislation needs, some options to mitigate their impact, and sources that can help us identify any other legislative requirements that can impact the use of logging.

10.1 Audit events vs. log events

When is an event an audit event, and when is it a log event? Let’s start with defining what the two events are (figure 10.1):

10.2 Log levels and severities

10.2.1 Trace

10.2.2 Debug

10.2.3 Info(rmation)

10.2.4 Warn(ing)

10.2.5 Error

10.2.6 Fatal

10.2.7 Extending or creating your own log levels

10.3 Clear language

10.4 Human and machine-readable

10.5 Context is key

10.5.1 Context: What