When it comes to monitoring and specifically IT Operations Monitoring (ITOM), everyone is saying monitoring is dead – you need observability. Vendors are jumping on the observability bandwagon. There’s a lot of noise about observability, network observability, full-stack observability and every other kind of observability you can imagine. This is a topic we have touched on in the past. Today I want to drill much deeper into the details of network observability and whether you really need it.
One of the challenges with observability (and thus terms like network observability or full-stack observability) is that the term is used differently by different vendors and different people. If we look at the history of the term observability (something discussed in an earlier blog post) we see that:
Observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs. In control theory, the observability and controllability of a linear system are mathematical duals. The concept of observability was introduced by the Hungarian-American engineer Rudolf E. Kálmán for linear dynamic systems.[1][2] A dynamical system designed to estimate the state of a system from measurements of the outputs is called a state observer or simply an observer for that system.
It’s All in the Packets
So what does this have to do with networks? Well, if we consider that observability is how well a system can report its internal state via external outputs, then networks are pretty darned observable. While functionality varies by solution, Packet Analyzers or Sniffers allow you to see, collect and analyze the network packets traversing the wire (or through the air for wireless networks):
- See – view packets as they appear in real-time
- Collect – store the packets for later retrieval and analysis
- Analyze – leverage the packets viewed and/or collected to identify the cause of network and application issues
The type of traffic is irrelevant – encrypted, plain text or anything in between. Packets are packets and contain useful information about the state of the network and the applications traversing that network.
These solutions have been around for literally decades (The Sniffer was one of the early appliances released by Network General Corporation in 1986) and come in a variety of flavors such as:
- Physical appliances that connect to the network and collect, analyze and store traffic on the wire.
- Software that collects, analyzes and stores traffic on the local system.
- Virtual solutions that can operate on virtual hosts or physical networks to collect, analyze and store traffic.
Where does observability fit into this? Let’s take a brief detour and talk about where observability does fit, and that fit is with applications.
Application Observability
Historically, applications have been considered black boxes – only providing limited outputs on their state natively. APM vendors require third-party agents to get real state information. The concept of observability in relation to applications is generally considered leveraging technologies like OpenTelemetry to allow applications to be natively instrumented to provide state information irrespective of the tools used for analysis of that data. Basically, observability really relates directly to applications as they historically provided limited outputs.
Network Observability
Now let’s get back to network observability. If observability is related to applications and making those applications provide state information, do we need observability for networks? Not really, networks have always been observable and pretty much always will be. The payload of each packet is not visible, but I don’t need that to understand the performance of the network.
So what the heck is network observability and do I need it? Vendors define network observability differently, but according to Gartner, the term does not mean anything specific:
“Network observability” is largely a buzzword, with no concrete definition beyond “network visibility.” It’s not meaningfully different from what has long been available in NPMD products. Observability (by itself) is a key application monitoring construct, particularly for transitioning from external monitoring to both internal and external instrumentation. Networks have existed in an “observable” state for many years; thus, the term “network observability” is largely meaningless.1
And that very much sums up the reality with network observability. Vendors are leveraging the buzz around “observability” to convince their prospects that they are getting something they are not. Networks have always been observable and highlighting a new buzzword does not mean you get any new functionality.
Choosing the Right Tool for the Job
To take it a step further, avoid selecting or paying a premium for products because they’re marketed as providing network observability. The function of network observability offers nothing different or unique from the functionality provided by network monitoring tools. Investing in such tools and expecting more or better functionality/visibility than traditional visibility/monitoring solutions is unrealistic and unnecessary.
Focus on identifying tools that meet your specific needs for network monitoring based on specific features, functionality and workflows. APM and NPMD are specific examples of tools that offer more tangible benefits.
And always remember, the customer remains king. For IT departments, customers include external and internal users accessing enterprise resources both remotely and locally. When investing in “true” observability initiatives, focus on the customer experience and solutions that provide RUM (real user monitoring), DEM (digital experience monitoring) or anything that gives you insight into the customer experience, rather than a single technology area. Better still, schedule a Netreo demo today!
1 – Gartner “Hype Cycle for Monitoring, Observability and Cloud Operations, 2021”