The distinction between observability and monitoring is a subtle, yet important one. Reviewing the capabilities and objectives of each can help teams better understand this distinction, and get more out of their observability strategies.
Monitoring allows users to watch and interpret a system’s state using a predefined series of metrics and logs. In other words, it empowers you to detect known sets of failure modes. Monitoring is crucial for analysing trends, building dashboards and alerting response teams to issues as they arise. It provides information about how your applications are working, how they’re growing and how they’re being used. However, monitoring depends upon a clear understanding of potential failure modes. In other words, it can help you identify “known unknowns” (risks you are already aware of); it can’t help you deal with unknown unknowns (risks that are completely unexpected, have not been considered, and thus are impossible to fully monitor).
This is problematic, because in most complex systems, the unknown unknowns greatly outnumber the known unknowns that are relatively easy to prepare for. More daunting still is the fact that most of these unknown unknowns - often referred to as blind spots - are so unlikely that identifying and planning for each would be a colossal waste of effort; it’s only the sheer volume of possible unknown unknowns that makes them a threat. So, because you can’t predict what these problems are going to be or even how to monitor them, you must instead constantly gather as much context as you possibly can from the system itself. Observability provides this context. Observability avoids health checks, and instead digs deeply down into how the software itself works. It measures your understanding of a system’s internal state based on its external outputs, using instruments to help you glean insight and assist monitoring.
Monitoring is what happens after something is observable. Without observability, monitoring is not possible.