Traditional logging, and how it is used in the majority of enterprise projects, is a suboptimal choice for concerns that are better handled using different approaches.
The question is: what do developers want to log, anyway? What about metrics, such as the current resource consumption? Or business-related information, such as car manufactured? Should we log debugging and tracing information such as request with UUID xy originated from application A, and called subsequent application B? What about occurring exceptions?
Attentive readers will see that most of the use cases for traditional logging are far better handled using other approaches.
If logging is used for debugging or debug tracing applications, the approach with using trace or debug levels doesn't help much. Information that will not be available in production can't reproduce a potential bug. Logging a huge amount of debug or trace events in production, however, will affect the application's responsiveness due to disk I/O, synchronization, and memory consumption. Debugging concurrency-related errors may even lead to a different outcome, due to the modified order of execution.
For debugging functionality, it's much more advisable to use actual debugger features during development, such as IDEs that connect against a running application. Logging that is used for business-motivated journaling is better accomplished via a proper journaling solution, as we will see later in this chapter. The plain text log messages are certainly not the ideal solution. The chosen technology should minimize the performance impact on the application.
Another approach to realize the same motivations behind journaling is to introduce event sourcing. This makes the domain events part of the application's core model.
Business-motivated tracing, this should be part of the business use case as well, implemented using an adequate solution. As we will see in the next sub-section, there are more suitable tracing solutions that require less parsing and have a smaller performance impact. Tracing solutions also support the consolidation of information and requests across microservices.
Monitoring information that is stored in log messages is better managed via the use of proper monitoring solutions. This approach is not just much more performant, it is also a more effective way of emitting the information in proper data structures. The examples we have seen earlier in this chapter illustrate monitored data and possible solutions.
Logging is also traditionally being used to output exceptions and errors that cannot properly be handled in the application otherwise. This is arguably the only reasonable use of logging. Together with other potential metrics that may capture the error, such as error rate counters at the system boundary, the logged exception may support developers in investigating errors.
However, errors and exceptions should only be logged if they in fact concern the application and represent an error that can be resolved by developers. With monitoring and alerting solutions in place, the need to look into logs should indicate a serious problem with the application.