Your observability stack is collecting 2TB of telemetry data per day. Metrics from every service. Traces across every request path. Logs from every container. You can query anything, visualize everything, and answer any question about your system — in theory.
In practice: when something breaks, your team still spends 20–40 minutes correlating data across three tools before they understand the problem. The data was all there. The insight wasn’t.
If we can see everything, why does it still take so long to understand anything?
The answer requires distinguishing between two eras of observability — and understanding what the transition from one to the other actually demands.
Observability 1.0 vs. 2.0
Observability 1.0 (2018–2024): The three pillars era
- Metrics: Aggregate numerical data — Prometheus, Datadog, CloudWatch
- Logs: Event records — ELK, Splunk, CloudWatch Logs
- Traces: Distributed request paths — Jaeger, Zipkin, Datadog APM
The 1.0 thesis: if you collect all three pillars with sufficient granularity, you can answer any question about your system’s behavior. Observability is the ability to infer internal system state from external outputs.
What 1.0 got right: It fundamentally changed how we think about monitoring. Moving from “alert on known conditions” to “investigate novel conditions” was a paradigm shift. The tooling matured enormously. A decade ago, correlating metrics with traces was a research project. Now it’s a dashboard feature.
What 1.0 got wrong: It assumed the bottleneck was data collection. It wasn’t. The bottleneck was — and is — interpretation.
Collecting 2TB per day is a solved problem. Understanding which 50MB of that 2TB matters right now, at 3 AM, during an incident — that’s the unsolved problem. More data didn’t close that gap. It widened it.
Observability 2.0 (2025+): The interpretation era
- Correlation: Automatically connecting metrics, logs, and traces for the same event — not just collecting them in the same tool
- Context: Understanding business impact, not just technical signals. “CPU at 90%” means nothing without knowing it’s the checkout service during Black Friday
- Prediction: Using historical patterns and ML to surface problems before they cause impact — not after
- Action: Closing the loop from detection to response — not just surfacing data for humans to interpret
The 2.0 thesis: observability isn’t about how much data you collect. It’s about how quickly you can go from “something is wrong” to “this is what happened, this is the impact, and this is what to do about it.”
The gap between those two eras is where most teams are stuck. They have 1.0 tooling — excellent data collection — and are trying to operate at 2.0 standards with human effort alone.
Why OpenTelemetry Is Necessary But Not Sufficient
OpenTelemetry’s role in this transition is significant. OTel standardizes telemetry collection — metrics, logs, and traces in a vendor-neutral format. It’s becoming the de facto standard, and for good reason:
- No vendor lock-in on data collection
- Consistent instrumentation across languages and frameworks
- Community-driven, widely adopted
- Separates the “how you collect” from the “where you send” decision
What OTel solves: The data collection problem. You no longer need to re-instrument your application when switching observability vendors. The plumbing is standardized.
What OTel doesn’t solve: What to do with the data once it’s collected.
OTel gives you high-quality, standardized telemetry. It doesn’t tell you:
- Which signals matter for your specific system
- How to correlate a metric spike with a deployment, a traffic pattern, and a customer complaint
- When a detected anomaly is a real problem vs. expected behavior
- What to do about it — and how urgently
The pattern recognition problem: Mature observability practices correlate with ~40% reductions in MTTR. But “mature” doesn’t mean “more data.” It means better interpretation, faster triage, and structural accountability for acting on what the data shows.
OpenTelemetry is the foundation of Observability 2.0. It is not Observability 2.0 itself. The gap between standardized data collection and operational intelligence is where most teams struggle — and where the most value is created.
The Interpretation Layer
What’s missing between data and decisions is a layer that most organizations don’t have — and that no single tool provides.
Level 1: Collection (where most teams are)
- Telemetry is collected and stored
- Dashboards visualize the data
- Alerts fire on threshold breaches
- Engineers query data during incidents
This is functional. Alerts work. Dashboards exist. But every incident starts with a human staring at multiple screens, trying to correlate what they’re seeing across tools. The alert fatigue problem lives here — too many signals, not enough context.
Level 2: Correlation (where advanced teams are)
- Related signals are automatically grouped — metric spike + error log + trace slowdown = one event
- Service dependency maps show blast radius
- Change detection links deployments to behavioral shifts
- Noise reduction through deduplication and grouping
Level 2 is a meaningful improvement. Incidents that took 40 minutes to correlate now take 15. But the human still needs to make every decision: Is this important? What’s the business impact? What do we do?
Level 3: Interpretation (where almost no one is)
- Business impact is assessed automatically — “this affects 12% of checkout requests”
- Historical context is surfaced — “this happened before; last time it was a memory leak in the payment service”
- Severity is determined by impact, not just metric deviation
- Recommended actions are presented with confidence scores
- The system learns from each incident — which interpretations were correct, which actions resolved the problem
Why Level 3 is rare: It requires a combination of deep system knowledge (not just data — context), operational experience across many similar systems (pattern recognition), continuous investment in improving the interpretation models, and someone accountable for the quality of interpretation over time.
Tools can automate Level 1 and partially Level 2. Level 3 requires human judgment — at least for now. The question is: whose judgment? Your on-call engineer at 3 AM, or someone who’s seen this pattern across dozens of similar systems?
Judgment as an Operational Function
The core argument: Observability 2.0 isn’t just a technology upgrade. It’s an operational model upgrade.
What the technology provides: Better data collection (OpenTelemetry), faster correlation (AI/ML-powered platforms), richer context (service maps, deployment tracking, business metadata).
What the technology doesn’t provide: The judgment to turn data into decisions. The accountability to act on those decisions. The feedback loop to improve the system based on what happened.
This is the same gap that AIOps promises to close but doesn’t — because AI can accelerate detection and correlation, but the interpretation step requires context that lives outside the data.
The interpretive layer as a service:
- A team that knows your system deeply enough to interpret signals correctly
- Experience across dozens of similar systems to recognize patterns faster than anyone could on a single system
- Continuous improvement: every incident makes the interpretation better
- Accountability: someone owns the quality of observability outcomes, not just the quality of data
The parallel to other industries: A radiologist doesn’t just produce medical images — they interpret them. The value isn’t in the MRI machine (the tool). It’s in the judgment applied to the output. The MRI vendor doesn’t own the diagnosis. The radiologist does.
Infrastructure observability is no different. The observability vendor provides the data. But the interpretation — which signals matter, what they mean in context, what action to take — requires judgment that lives outside the tool.
The responsibility boundary is the same pattern applied to telemetry: who owns the outcome of the data, not just the data itself?
From Data to Decisions
Observability 2.0 is about moving from data to decisions. The technology is ready — OpenTelemetry for collection, AI for correlation, modern platforms for visualization. The gap is in the judgment layer: the operational intelligence that turns 2TB of telemetry into the three things that matter right now.
Vigil by IOanyT provides the interpretive layer for your infrastructure. We turn telemetry data into operational decisions, not just dashboards. We correlate, interpret, and act. You get outcomes, not data.