Monitoring or observability?
Summary: these two words are used as synonyms, wrongly. Monitoring watches indicators decided in advance — it answers the questions you knew you had to ask. Observability lets you investigate situations never anticipated. This lesson clarifies the distinction, explains the origin of the term, introduces the crucial notion of cardinality, and retraces the history since 1999.
1. The two definitions
The most useful formula to remember: monitoring answers "is my system working as expected?". Observability answers "why is it behaving in this way I had not expected?".
Essential clarification: observability does not replace monitoring, it encompasses it. You need both — alerts on known problems, and the ability to investigate the novel.
2. A concrete example that settles it
This is the canonical example of the field: a real problem, invisible on all the classic dashboards, because it affects only a precise subset of users. Monitoring aggregates, and aggregation hides minorities.
3. The origin of the term — control theory
The word observability was not invented by the software industry. It comes from systems engineering.
The box test in O4 is the best evaluation tool there is. Ask yourself: "the last time a novel problem occurred, did I have to add logs and redeploy?". If the answer is yes — and it is in most teams — you are doing monitoring, not observability.
4. Cardinality — the key technical notion
This is the concept that technically explains why classic monitoring cannot answer certain questions.
The most costly practical mistake in observability: adding a user_id label to a Prometheus metric. With 500,000 users, you create 500,000 time series for a single metric, and you take down your monitoring server. It is a classic outage, and it usually happens in production, not in testing.
The good practice: unique identifiers go into traces and structured logs, never into metric labels.
5. A brief history — from Nagios to OpenTelemetry
Why this change was inevitable: Nagios answered the question "is this server alive?" very well. But in an architecture where a request crosses fifteen services, all servers can be "alive" while the user-facing service is broken. The change of scale forced a change of approach.
The name to know: OpenTelemetry. It is today's instrumentation standard, a CNCF project, and it appears more and more in job postings. Its major benefit: you instrument once, and you can change visualization tools without rewriting your code.
6. The comparison table
| Criterion | Monitoring | Observability |
|---|---|---|
| Question addressed | Is it working? | Why is it behaving this way? |
| Type of problem | Known, already encountered | Novel, never anticipated |
| Approach | Predefined dashboards and thresholds | Free exploration of the data |
| Supported cardinality | Low | High |
| Main output | Alerts | Investigation |
| Storage cost | Moderate | Higher |
| Suited to | Stable, well-known systems | Complex distributed systems |
| Typical tool | Prometheus, Zabbix, Nagios | Tracing, structured logs, Honeycomb |
A practical reading of this table: you do not have to choose. Start with monitoring — alerts on a few key indicators bring immediate value. Add observability when your system becomes distributed and problems become hard to reproduce.
7. How to know where you stand
Progression advice: do not try to jump straight to level 5. Level 2 delivers most of the benefit for a modest effort — measuring the error rate and the latency of your entry points, and alerting on them. Many teams install a sophisticated tracing system before having a simple alert on their error rate.
Remember in 30 seconds
- Monitoring = watching indicators planned in advance. Covers known problems.
- Observability = understanding the internal state from what the system emits, including for novel questions.
- Observability does not replace monitoring, it encompasses it. You need both.
- The decisive test: faced with a new problem, do you have to add logs and redeploy? If yes, your system is not observable.
- The term comes from Rudolf Kálmán (1960) and control theory.
- Cardinality: never put a user identifier in a metric label — you will take down your server.
- Unique identifiers go into traces and structured logs.
- History: Nagios (1999) → Prometheus (2012) → distributed tracing (2015) → OpenTelemetry (2019).
- OpenTelemetry is the instrumentation standard to know: instrument once, change tools freely.
- Aim for level 2 first: error rate and latency of your entry points. That is where most of the gain lies.