Observability is a new term that’s slowly entered the mainstream over the last two years. Today it’s used in the context of monitoring, but it’s much more than that. And it also goes way beyond visibility. So, in this blog, we set out to explore observability vs visibility and find out, what’s the difference?
In a recent podcast, our friends at Riverbed neatly explained that seeing and observing are two different things, and can be compared to hearing vs listening. It’s a good analogy. Think about it.
While you may see or hear something as a one-off occurrence, the stimulus only becomes insightful and actionable once your brain can process it alongside other live inputs and give it context. But you’re unlikely to have predicted the exact series of inputs was going to happen.
What is visibility?
Visibility provides information about what’s already happened in our monitoring environments and allows us to understand the state of our systems retrospectively. Utilizing a monitoring tool, we can watch, analyze, and present data by gathering a pre-defined set of metrics or logs from pre-deployed sensors within a system. Typically, visibility concerns itself with monitoring tools, devices, services, applications, and locations.
What is observability?
On the other hand, observability provides information about what’s happening here and now, in the last second, minute, or hour. It brings together usable intelligence to enable a continuous, functional outcome. This happens by using data that understands the context of the wider ‘system’ – think infrastructures, architectures, and applications that make up a modern, digital organization, from endpoint to cloud and beyond.
What’s the difference between IT visibility and observability?
Put simply, visibility asks what information is already available, and allows you to identify when something’s wrong. But observability takes that so much further. It asks what information is needed to understand the system and allows you to understand exactly why something’s wrong. With observability, you can actively troubleshoot your system by exploring properties and patterns that weren’t already defined in advance.
Observability typically incorporates these three things to understand the system and identify what’s happening:
- Context, or what you know
Our CTO, Andy de Clerck, provides this helpful analogy. Consider you’ve called the emergency services. In this example, you’ve asked the ‘system’ for help. There’s an expected target outcome because we understand what the emergency services system delivers.
If we think of observability as the ‘system knowledge’, then the attributes this brings to the digital supply chain include functionality, performance, operability, maintainability, efficiency, learning, and usability. Following the same emergency services analogy, let’s look at those three observability points.
1 – Context, or what you know
So, we’re back seeking help from the emergency services. The context, or what you know in terms of observability refers to the alert received, and the type of help required. For example, alerts could come from a fire alarm, an intruder, or a gas sensor. And maybe there’ll be smoke or video detection. The emergency services know that something isn’t right and the nature of the alert. They can then take action.
2 – Validation/triage
Now that the emergency services know there’s an incident, they need to understand its scale, risk, and impact. Is it a local incident, and is it manageable? Or is it a more significant issue requiring additional help from other emergency services: police, ambulance, fire department, or indeed all three?
3 – Remediation
Let’s wrap up the emergency services analogy. With the exact context known, and the outcome expected to be a positive resolution of the incident based on what we know the system is capable of, we can move to resolution quickly.
Where observability counts today
Too many blind spots exist in today’s modern infrastructure, none more so than where there are interactions between services. For example, observability makes a huge difference in multi-cloud and Work From Anywhere environments.
If you consider serverless, containerized cloud architectures, the layer of monitoring you’d normally get from traditional visibility has disappeared. What makes these modern environments so agile and attractive is that they have no interface between the underlying infrastructure and operating system, often referred to as a hypervisor layer. Instead, these new systems directly access the kernel and infrastructure services.
Network systems too, both physical and virtual, become hidden along with any kind of interfacing, such as network namespaces. So too, are data flows.
Modern systems are also recyclable by design. This adds more challenges as infrastructure provisioning becomes dynamically configured and controlled, deployed on-demand, and governed by ongoing Machine Learning and Artificial Intelligence.
Observability is crucial for infrastructure and operations teams. Without it, it’s quite simply impossible to monitor service delivery and performance. However, this doesn’t mean you need to throw away all your current monitoring tools.
Observability is the next evolution of visibility. Organizations should build on what they already have, to attain the most important observability benefits.
At Teneo, we help teams to benchmark their current visibility capabilities, define gaps and overlaps, and identify their path to observability in simple steps. For more details, visit our Visibility Tools Suitability Assessment overview page, or book a 30 minute introductory session to explore how to implement observability today.