Monitoring tells you when something is broken. Observability tells you why. This is not a semantic distinction — it represents a fundamentally different philosophy about how you instrument, collect, and analyze the signals your systems emit. In an era of microservices, serverless functions, and ephemeral containers, monitoring alone is no longer sufficient to understand the behavior of production systems.
The Three Pillars: Metrics, Logs, Traces
Metrics are aggregated numerical measurements over time — request rate, error rate, latency percentiles, CPU utilization. They are efficient to store and fast to query, making them ideal for alerting on known failure modes and capacity planning. Prometheus is the dominant metrics collection standard; its data model (labeled time series) and PromQL query language have become the lingua franca of metrics.
Logs are timestamped, structured records of discrete events — an HTTP request was received, a database query was executed, an exception was thrown. They provide granular context that metrics cannot. Structured logging (JSON with consistent field names) is essential for effective log analysis at scale; free-text log parsing at high volume is operationally unsustainable.
Distributed Tracing: The Missing Link
In a distributed system, a single user request may traverse dozens of services. Metrics tell you that your API has a high 99th percentile latency. Logs tell you individual services are processing requests slowly. But neither tells you which specific service in a multi-hop request chain is the bottleneck, or how latency propagates across service dependencies.
Distributed tracing solves this. By propagating a trace context (W3C Trace Context is the standard) across service boundaries and recording spans at each hop, you can visualize the complete execution path of any request — including timing, errors, and contextual attributes at each step. Jaeger, Zipkin, and Grafana Tempo are the dominant open-source tracing backends; OTLP (OpenTelemetry Protocol) is the vendor-neutral wire format.
OpenTelemetry: The Unified Standard
OpenTelemetry (OTel) is the CNCF project that is standardizing observability instrumentation across all three pillars. OTel SDKs for every major language provide auto-instrumentation for common frameworks (HTTP servers, database clients, message queue consumers) and a consistent API for manual instrumentation. The OTel Collector serves as a vendor-agnostic pipeline for processing and exporting telemetry to any backend.
The strategic value of OTel is vendor portability. Organizations that instrument with OTel can route telemetry to Datadog today and switch to Grafana Stack tomorrow without re-instrumenting their services. For enterprises evaluating or migrating observability platforms, OTel adoption is now a prerequisite for maintaining flexibility.
Key Takeaway
"The shift from monitoring to observability is not just a tooling upgrade — it changes how engineering teams reason about production systems. Truly observable systems can be debugged by asking questions that were not anticipated at instrumentation time, using the raw telemetry data to reconstruct system behavior. Building observability into services from the start, using OTel for vendor-neutral instrumentation, and investing in the analytical platforms that make telemetry queryable will pay compound returns across every production incident."
Topics
