Logging is a standard part of most software that is, all too often, only given a minimal amount of attention. However, by approaching logging with a more stringent point of view, we are able to design systems that allows us to quickly determine what is going on inside of them. This introspection in turn allows us to determine what the typical performance is for a system, as well as determine where a fault has occurred in the system.
Some typical information that is logged by a system includes, but is not limited to:
- When a process starts or stops.
- When a specific point in the process has been reached.
- When an error occurs.
- Information about the request sent to the service.
- Information about the response returned from the service.
- Configuration values used by a system.
Another aspect that is usually considered to be separate from logging is performance metrics. I am including metrics in this paper, since the overall design that will be discussed here lends itself to not only logging messages like the ones listed above, but performance metrics as well. Examples of metrics include:
- How long a process took to execute.
- How many times a process was called.
- How many errors have occurred.
The traditional location for a log has been a file located on the server that houses the service that is writing to the log. This is not always true, especially with the adoption of microservices. In the latter case, instead of writing to a file, the logging system sends the log line to another service, when then stores it in some type of database.
By abstracting the logging from the core code we will be able to take advantage of these features:
- Simplify the business logic code
- Simplify the logging code
- Update the logging code with minimal impact on the business code.
- Introduce standard formatting to the logged information.
Next: Design Concepts