48.9k
Monitoring is the practice of watching known indicators for known failure modes; observability is a property of a system: the ability to infer its internal state from its outputs. The distinction dates to control theory (Rudolf Kálmán, 1960) and decides how teams debug: check a dashboard, or interrogate raw telemetry.
What is the difference between monitoring and observability?
Monitoring asks predefined questions about failures you have seen before: is CPU above 80%, is the error rate over 1%. Observability supports questions you didn't think to ask until the incident: arbitrary queries over raw telemetry, after the fact. Monitoring is something you do; observability is something a system has.
| Dimension | Monitoring | Observability |
|---|---|---|
| Questions | Known in advance ("is p99 above 500 ms?") | Arbitrary, asked after the fact ("why are checkouts slow for iOS users in Frankfurt?") |
| Data | Pre-aggregated metrics, predefined dashboards, threshold alerts | Raw, context-rich telemetry: wide events, traces, structured logs |
| Cardinality | Low: bounded label sets (host, service, status code) | High: unbounded attributes (user ID, request ID, build hash, feature flag) |
| When it helps | Recurring, well-understood failure modes | Novel failures and emergent behaviour in distributed systems |
| Cost model | Cheap to store aggregates; adding a new question means new instrumentation and waiting for data | More raw data retained; new questions cost nothing beyond a query |
In practice teams need both. Google's SRE book treats monitoring as the base of the reliability hierarchy: alerts tell you something is wrong, and observability is what lets you find out why.
What is monitoring?
Monitoring is the practice of collecting predefined metrics from a system, displaying them on dashboards, and alerting when values cross thresholds. It encodes past experience: every chart and alert rule represents a failure mode someone anticipated. Prometheus alert rules and Grafana dashboards are the canonical form.
Monitoring is deliberately reductive. A counter like http_requests_total{status="500"} compresses millions of requests into one time series, which makes it cheap to store and fast to evaluate every 15 seconds. The trade is context: the aggregate can tell you that 0.4% of requests failed, but not which customers, which endpoints, or what those requests had in common. Google's SRE book narrows the signals worth alerting on to a deliberately small set of four: latency, traffic, errors, and saturation.
What is observability?
Observability is the property of a system whose internal state can be inferred from its external outputs. Rudolf Kálmán defined the term for control systems in 1960; software engineering borrowed it for distributed systems, where "outputs" means telemetry (logs, metrics, traces, and events) rich enough to reconstruct what happened.
In Kálmán's formulation a system is observable if you can determine its full internal state from output measurements alone. Applied to software: if you can diagnose a failure you have never seen before using only the telemetry the system already emits, without shipping new code to add print statements, the system is observable. Twitter's engineering team was using the term for its telemetry platform by 2013, and the OpenTelemetry observability primer now anchors the same definition across CNCF projects.
Is observability just monitoring rebranded?
No. A rebranded monitoring product still evaluates predefined checks against pre-aggregated data; an observability platform preserves raw, high-cardinality context so engineers can ask unanticipated questions during an incident. A threshold alert can report that a failure happened, never why.
The confusion is understandable, because vendors relabelled monitoring products as "observability platforms" faster than the underlying capability changed. The test is mechanical: whether you can group last week's raw data by a field nobody planned for, such as customer ID or build hash. If every question must be anticipated by a dashboard, the capability is monitoring regardless of the label. If the data model supports high-cardinality ad hoc queries, the label observability is earned.
How do monitoring tools differ from observability platforms?
Monitoring tools scrape metrics, render dashboards, and fire threshold alerts over pre-aggregated time series. Observability platforms store raw, high-cardinality telemetry (wide events, traces, structured logs) and expose a query engine over it, so an engineer can slice an incident by any attribute the system recorded.
The difference shows up in the data at rest. A monitoring store holds compact series keyed by a bounded label set. An observability store holds one wide row per request or span, often 50-200 columns of context: trace ID, user ID, region, build, feature flags, timing breakdowns. Debugging becomes an analytical query:
-- "Why are checkouts slow?" as a query, not a dashboard
SELECT build_hash, payment_provider, count() AS requests,
quantile(0.99)(duration_ms) AS p99
FROM otel_traces
WHERE service = 'checkout' AND timestamp > now() - INTERVAL 1 HOUR
GROUP BY build_hash, payment_provider
ORDER BY p99 DESCGrouping by build_hash wasn't planned in advance. That's the capability monitoring can't offer, and it's why storage and query engine choice drives observability platform design. The signals themselves stay familiar, since these platforms ingest the same three pillars of observability that monitoring draws on; what changes is that they arrive raw instead of pre-aggregated.
Do you need observability if you already have monitoring?
Yes, once failures stop repeating themselves. Monitoring covers the failure modes you have already met; distributed systems generate novel ones, emergent behaviour across services that no dashboard anticipated. If on-call engineers regularly exhaust the dashboards and resort to guessing or redeploying with extra logging, monitoring has hit its ceiling.
The dependency also runs the other way: you monitor because a system is observable. An alert is a standing query over system outputs, so every monitoring signal is drawn from whatever telemetry exists. Rich instrumentation improves both at once. Teams running a monolith with well-known failure modes can live on monitoring alone for years; teams running dozens of microservices usually cannot, because the space of possible failures outgrows the space of dashboards. Network and security teams often call the same capability "visibility"; the observability vs visibility split is largely one of vocabulary between disciplines.
When should a team move from monitoring to observability?
Move when unknown-unknowns account for most of your incidents: when the cause of a typical outage is something no existing dashboard shows. Common triggers are a microservices migration, incidents where most of the time to resolution goes to "finding the right dashboard", and postmortems that end with "we added a new alert for this".
Concrete signals that the ceiling is close:
- Debugging requires redeployment: engineers add log lines and ship to reproduce an issue, meaning the system's outputs cannot answer new questions.
- Teams strip user IDs or endpoint labels from metrics to keep the monitoring bill sane, deleting exactly the context incidents need.
- Dashboards multiply faster than they help, and each new incident still needs another one.
The move is instrumentation-first, not tool-first. Adopting OpenTelemetry SDKs and emitting wide, structured events makes a system observable; whatever backend you choose then has raw material to query.
Where ClickStack fits
ClickStack is the ClickHouse observability stack: OpenTelemetry for instrumentation and collection, ClickHouse as the telemetry store, and HyperDX as the UI. It targets the observability column of the table above: raw, high-cardinality wide events, traces, and logs kept queryable at scale, so the "group by any attribute" queries in this article run as plain SQL over columnar storage.
Because it is OpenTelemetry-native, it fits the instrumentation-first path: the same OTel SDKs and Collector pipelines that make a system observable feed ClickHouse directly, and ClickHouse's compression makes retaining raw events viable where metrics-only systems force pre-aggregation. Monitoring-style alerting runs on top of the same store, as saved queries with thresholds, so there is no separate alerting silo to keep in sync.
FAQ
Can you have observability without monitoring?
In principle yes, in practice no. Observability is a property of the system (telemetry rich enough to answer arbitrary questions) and it exists whether or not anyone watches it. But without monitoring, nothing tells you when to start asking. Every mature setup layers alerts on top of observable telemetry.
Can you buy observability?
No. Observability comes from instrumentation: your code must emit telemetry rich enough to reconstruct internal state, which is why OpenTelemetry adoption matters more than tool choice. A vendor can sell storage, query, and visualisation for that telemetry. Point any platform at an uninstrumented system and you get empty dashboards, not observability.
Is observability more expensive than monitoring?
It shifts cost rather than simply adding it. Raw high-cardinality events need more storage than pre-aggregated metrics, though columnar compression narrows the gap. In exchange, new questions are free at query time, while monitoring pays for new questions in engineering time: new instrumentation, a deploy, and waiting for data to accumulate.
Does observability replace monitoring?
No. Monitoring detects that something is wrong; observability determines why. Mature teams run both from shared telemetry: alerts as standing queries for known failure modes, ad hoc queries for novel ones.
To see the observability side of this comparison in practice, ClickStack is open source and runs locally; the getting started guide takes one Docker command.
