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 is 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 behavior — 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?

Read the rest of the article on Medium.