While the answer to that question varies, depending on who you ask, IT experts agree that observability practices and tools hold certain attributes that distinguish them from those of "legacy" IT monitoring.
But to grasp the key differences between these two classes of tools, it's best not to think strictly in terms of observability vs. monitoring. Instead, consider the former an evolution of the latter.
Observability and monitoring for IT teams
Observability is more of practice than a product, said Joseph Ours, director of modern software delivery at Centric Consulting, a technology consulting firm based in Dayton, Ohio. IT teams gain deep insight into application environments and stay one step ahead, in terms of issue resolution.
"Observability is about what can we learn, and how we can proactively respond to what we are seeing, and what the customer is experiencing," Ours said.
That said, to achieve observability, IT teams do need the right set of tools. Observability tools -- now offered by vendors such as New Relic, Sumo Logic and AppDynamics -- have capabilities that extend beyond those of traditional IT monitoring systems.
For example, observability tools use APIs to collect data from a broader range of sources, said Federico De Silva, Gartner senior research director. These sources include log files and application traces, and even social media and other non-technology data feeds. This provides IT admins with a more comprehensive view of system performance and health than domain-specific IT monitoring tools and practices that focus, for example, on just network traffic or storage devices.
This holistic view lets IT teams move beyond the what and arrive at the why, said Thomas Martin, director of site reliability at 27Global, a custom software development firm based in Leawood, Kansas. For example, a traditional IT monitoring tool like Zabbix provides alerts when CPU or RAM usage is high, and then the admin determines the cause manually. Observability tools -- usually aided by machine learning -- connect those dots on the admin's behalf, identifying that a memory leak, for example, is causing RAM to spike.
"You're observing your whole entire infrastructure from a single [location], and you're not having to work for that information," said Martin, whose team uses New Relic's observability platform. "It's there for you."
Another big difference between observability tools and monitoring tools is that the latter tend to provide the same set of standard metrics for every application, said Buddy Brewer, field CTO for the Americas at New Relic, based in San Francisco. For example, they report on page load times for the application front end, method call timings for the application's middle tier and query response times for the database.
[Observability is] a precursor to a self-healing architecture.
Joseph OursDirector of modern software delivery, Centric Consulting
But as application complexity increased -- particularly with the emergence of containers and microservices -- so did the mean time to resolution with traditional IT monitoring tools and practices. This is because, in these modern environments, there's a lot of data that's bespoke to the application, Brewer said. To address this, observability tools and practices push deeper into application code.
"Engineers are now exposing information about what's happening inside applications that might be totally unique to the workload they're trying to observe," Brewer said.
In addition to providing a broader, end-to-end view of the IT environment, observability enables admins to resolve issues more proactively, Ours said. With traditional monitoring, IT teams rely on alerts from preset thresholds. But observability tools identify indicators in the environment that suggest a problem is forthcoming. Alerts then occur preemptively, giving admins a chance to react to an issue before it arises.
Observability also emphasizes automation. For example, an IT team might know it needs to reboot a service once CPU utilization reaches 70%. With observability, a preplanned automation script can perform the necessary reboot, as CPU utilization approaches that threshold.
"It's a precursor to a self-healing architecture," Ours said.
But even with all its benefits, observability doesn't negate the need for traditional monitoring tools and practices -- in fact, the two go hand in hand.
"Once you've achieved observability -- and you're emitting enough information from inside your application in order to reason about what's going on -- then you need something that's going to watch all that data and let you know when there's a change in that data that will impact the customer experience," Brewer said. "So monitoring, in that sense, sits on top of observability."
AIOps and observability
Just as the line between observability and monitoring can easily blur, so too can the line between observability and AIOps.
Martin describes observability as a kind of steppingstone to -- or catalyst for -- AIOps. "It's the beginning of the process," he said. "Observability can help find anomalies, but it's not addressing them."
Observability and AIOps go hand in hand, Ours agreed, as the AI component is what actually drives the automated response to whatever the observability process uncovers. "Observability response and AIOps are in the same category," he said. "It's going to be difficult to separate them out."
Observability and DevOps
DevOps culture breaks down barriers and encourages collaboration between IT ops and development teams. Observability -- a practice that spans both disciplines -- naturally complements DevOps. After all, neither can occur in a silo.
"The whole DevOps culture and mentality is to bring everyone in the same room and say, 'Hey, I'm responsible for the infrastructure, and you're responsible for the code, but the product is ours, so we have to watch both sides of it,'" said 27Global's Martin.
Like DevOps, observability encourages developers and IT ops staff to work together toward a common goal: deeper and more actionable insight into the IT environment, as well as the applications it supports.
"I wouldn't know how to debug a .NET app," Martin said. "But [with observability], I can at least point to the problem, where it is, and work together [with developers] to get it out the door."
When DevOps teams adopt observability tools and processes, they tend to do so on the ops side -- specifically, as part of their workflow automation efforts, Ours said. But those tools and processes propagate through the release and development cycles, and eventually become part of the build process, as well.
Ultimately, observability fosters -- and requires -- the same cross-functional collaboration seen in DevOps.
"As operational teams [start working] with the developers, they say, 'Let's start developing some runbooks for these applications [that automate reactions] to certain types of situations,'" Ours said.
First steps toward observability
Of course, not every organization should strive for observability -- at least not yet. An effective observability strategy requires large volumes of monitoring data. Small- to medium-sized businesses, in particular, tend to struggle with observability, because they simply don't produce enough data within their IT environments, according to Ours.
Data integrity, in addition to volume, is another big factor.
"It's easy to collect data," Ours said. "It's hard to standardize it in such a way to make it meaningful, and to implement a standardized set of processes and practices around it."
Lastly, as is the case when implementing any new IT tool or process, IT teams must develop a clear vision around observability. From the outset, set goals that are unique to your specific business and technical needs.
"If [observability] is not going to solve a problem for your organization -- or [if] you can't articulate that -- it's too soon for you," Ours said.
