# Observability vs Monitoring

While often used interchangeably, Observability and Monitoring are distinct concepts in the world of DevOps and Site Reliability Engineering (SRE).

## 1. Monitoring: "Is the system healthy?"

Monitoring is the process of collecting, analyzing, and using information to track the progress of a program toward reaching its objectives. It tells you **when** something is wrong.

*   **Focus:** Known Unknowns. You monitor for things you *expect* might fail (e.g., CPU usage > 90%, Disk space < 10%).
*   **Output:** Dashboards, Alerts (Red/Green status).
*   **Question:** "Is the database up?"

## 2. Observability: "Why is the system unhealthy?"

Observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs. It allows you to understand the internal state of the system by inspecting the data it generates.

*   **Focus:** Unknown Unknowns. It helps you debug issues you never predicted.
*   **Output:** Granular insights, ad-hoc queries.
*   **Question:** "Why is the checkout latency high for users in Germany on iOS devices?"

## 3. Key Differences

| Feature | Monitoring | Observability |
| :--- | :--- | :--- |
| **Goal** | Track system health | Understand system behavior |
| **Perspective** | External (Black Box) | Internal (White Box) |
| **Data** | Aggregated Metrics | High-cardinality events |
| **Action** | React to alerts | Debug and explore |

## 4. The Three Pillars of Observability

To achieve observability, you typically need three types of telemetry data:

1.  **Logs:** Discrete events (e.g., "User X logged in at 10:00 PM"). Good for detail but expensive to store.
2.  **Metrics:** Aggregated numerical data (e.g., "Average CPU load over 1 minute"). Cheap to store, good for trends.
3.  **Traces:** The journey of a request as it moves through various services in a distributed system. Essential for microservices.

[[programming/microservices-architecture]]
[[programming/distributed-systems]]
[[programming/debugging-techniques]]