What is the difference between monitoring and observability, and why do SREs need both?

Question

Accepted Answer

Monitoring and observability are related but distinct concepts that together give SREs the ability to understand and maintain system health. Understanding the difference helps you build effective systems for detecting and diagnosing problems.

Monitoring is about collecting predefined data points and checking them against known thresholds. You decide in advance what to watch: CPU usage above 90%, response time above 500 milliseconds, error rate above 1%. When a threshold is crossed, an alert fires. Monitoring answers the question "is something wrong?" It is excellent for known failure modes and expected problems. Traditional monitoring tools include Nagios, Zabbix, and basic Prometheus alerting.

Observability goes deeper. It is the ability to understand the internal state of a system by examining its external outputs. Observability answers the question "why is something wrong?" even for problems you did not anticipate. An observable system lets you ask new questions without deploying new code or adding new instrumentation. The three pillars of observability are metrics, logs, and traces, which work together to provide a complete picture.

Metrics are numerical measurements collected over time, like request count, latency percentiles, and error rates. They are efficient to store and great for dashboards and alerts. Logs are detailed records of discrete events, containing rich context about what happened. They are verbose but invaluable for debugging specific issues. Traces follow a single request as it flows through multiple services, showing where time is spent and where failures occur.

SREs need monitoring to detect problems quickly and automatically. You cannot watch dashboards 24/7, so alerting based on monitored metrics is essential for incident detection. But monitoring alone is not enough because production systems fail in unexpected ways. When you get a page at 3 AM saying latency is high, you need observability to figure out why.

A practical example: monitoring tells you that the checkout service error rate jumped to 5%. Observability lets you drill into the metrics to see that errors are only happening for requests to a specific endpoint, pull up the logs to see that a downstream payment API is returning 503 errors, and trace a failing request to see that the timeout is occurring at the database connection pool level because the payment service is exhausting connections.

The combination gives you detection speed from monitoring and diagnostic depth from observability. As an SRE, you build both into your systems from day one rather than adding them after problems occur.