The continuation of our discussion about logs references the famous phrase “Quis custodiet ipsos custodes?” (“Who will guard the guards themselves?” or “Who watches the watchers?”).
Any large systems—whether technical or social (for example, society and its institutions)—require monitoring and logging tools to understand what went wrong in case of an abnormal situation and trace the entire chain of events back to the source of the problem (in programmer jargon, this is called debugging).
Once the problem is found, it can be addressed, and everything possible can be done to prevent it from recurring in the future. But as long as the causes of the problem are unclear, our hands are tied by uncertainty.
Note: However, even under conditions of uncertainty, there are ways to prevent abnormal situations, even if we don’t know their potential source in advance. Such methods are called “fences” (“let’s put a fence here”) or “guards” in programmer jargon. We will discuss them separately in due time.
Yet the paradox is that the monitoring, tracking, and logging system is itself a system and is also prone to errors (and abuse, if we’re talking about society). In a sense, it’s like a cat chasing its own tail.
Because such a serious “mission” is entrusted to logging / monitoring systems, they require more thorough design and debugging. Errors in this system will be more costly, as they permeate the entire system. The same can be said for law enforcement agencies, internal security departments, and similar services tasked with ensuring everything proceeds as it should.
But that’s not all. Besides the fact that the logging and monitoring subsystem can itself be a source of errors that no one will be able to detect, its use within the overall system is not free. Just as society must (through taxes) pay for the work of all controlling and law enforcement agencies, within a technical system, logging and monitoring:
-
consume CPU time;
-
eat up part of the RAM;
-
use disk space (SSD / HDD / flash card), also increasing disk wear;
-
load the network when transmitting logs or monitoring signals to a centralized storage.
And most importantly—to create and maintain logging and monitoring systems, developer time (what’s called man- or human-hours must also be spent on them, not just on developing the main program.
All of the above increases the cost of the final software product. But for many systems, having logging and monitoring subsystems is not a luxury but a necessity, because the damage from an abnormal situation can often outweigh everything you saved earlier on these systems.
And finally: we add logging to our programs to better understand what they are doing and when. To better understand the causes of potential problems. But sometimes the very addition of logs changes the program’s behavior (after all, we affect both CPU load and memory data distribution, as well as the timing characteristics of our program).
A parallel can be drawn here with physics: the observer effect—when the observer influences the system simply by the fact of their presence. This is particularly evident in quantum physics.
By the way, in quantum cryptography, the observer effect is used positively—any attempt to eavesdrop on the “transmission” irreversibly changes it, thus allowing the detection of eavesdropping.
In the final part of our (asterisked) discussion about logs, we will talk about how to reduce the impact of the logging system on the overall system: lower the CPU load, reduce memory consumption, etc. We will also discuss how to avoid drowning in logs.