Time for some buzzword bingo. Monitoring and Observability are often used interchangeably. They’re usually seen in the context of discussions about architecture and distributed systems, with Observability being touted as the “new kid on the block.” or “rebranded monitoring.” It’s not new, though. Nor is it the same thing as Monitoring.
Despite the typical jaded backlash to the contrary, they are very different things. Baron Schwartz has a great, short definition: “Monitoring tells you whether the system works. Observability lets you ask why it’s not working.”
An Observable system is one that is generating enough data through metrics, logs, traces, and events to be analyzed so that questions about a system may be answered. A monitoring solution may provide some of that data, and usually has some mechanism of alerting as well.
Cindy Sridharan visualizes this as an Observability pyramid:
But there is no benefit from Observability without Analysis. Without the right people to Analyze the data, from Monitoring or otherwise, coming from an Observable system, the enterprise won’t gain any real value.
There may be an Observability Pyramid, but the system as a whole is more like a scientist in a lab. A microscope slide contains plenty of data, it is observable through mechanisms like magnification, but no useful information can be derived unless someone is on the other end thinking about what’s going on.
What’s the point of this disambiguation though? By separating these terms into distinct concepts we gain two things. We can more easily determine when to implement them in a system design (start thinking about Observability at the beginning), and they become distinct offerings.
In short, Monitoring can be bought. Observability can be achieved. Value is only added if you have the right people for Analysis.
Some additional info: