Logging on the cheap

To log or not to log?

Writing new code is a relatively small part of application development. A much larger part of a software engineer's life involves supporting and maintaining existing systems. First and foremost, this requires the right level of insight — understanding what exactly the system is doing, particularly when this isn't quite what you (and your customers) were expecting. Logging, tracing, remote debugging, and application performance monitoring are essential in attaining the level of observability required to comfortably operate and support a modern application suite.

When building conventional applications, the question of whether an action should be logged or not is rarely a subject of rigorous debate. (By 'conventional', we mean most e-commerce applications with fairly routine non-functional requirements concerning throughput, latency, availability, and so forth.) Occasionally, we come across a class of applications that breaks that mould. Sometimes particular modules of an otherwise conventional system might be subject to very stringent constraints around their performance. An application might perform an expensive calculation in a tight loop, or it may be required to respond (on average) within a tight time frame. Invasive instrumentation of these applications changes their timing behaviour — even simple log calls carry an overhead that might cardinally impact the customer experience. In these sorts of scenarios, the question posed at the beginning of the article — To log or not to log? — becomes a real point of debate. Do you sacrifice break-neck performance for observability, or is performance the coveted money-maker that dwarfs every other concern?

---

Introducing Zerolog?

This article is going to explore Zerolog (abbreviated to Zlg) — an ultra-low-overhead logging façade for performance-sensitive Java applications. The objectives of Zlg are twofold —

1. Ultra-low overhead for suppressed logging. In other words, the cost of calling a log method when logging for that level has been disabled is negligible. Furthermore, it is possible to invoke Zlg in such a way as to reduce these costs to absolute zero.
2. Uncompromised code coverage. Suppression of logging should not impact statement and branch coverage metrics. A log entry is a statement like any other — if it's worth writing, it's worth testing.

Read the rest of the article on Medium.