What is observability?
Observability is how well you can understand what is happening inside a system from the data it emits, usually metrics, logs and traces, without shipping new code to answer a new question. Monitoring tells you that a known check failed; observability helps you find out why, including for failures nobody predicted.
Why observability matters
Modern systems fail in new ways: one customer's requests are slow, one region's queue backs up, a release breaks only in one browser. Predefined dashboards cannot cover every case, so you need data rich enough to slice by user, endpoint, version or host after the fact.
The term comes from control theory, where a system is observable if its internal state can be inferred from its outputs. In software it is a practice rather than a product: instrument well, keep context such as trace IDs and release versions on every signal, and connect the signals.
How to measure observability
metric time series (cardinality) = product of the number of values of each label example: region × endpoint × status code
Worked example
A request-count metric has labels for region (3 values), endpoint (20) and status code (5).
- Series = 3 × 20 × 5 = 300 time series, cheap to store and query.
- Adding a user_id label with 10,000 users makes it 300 × 10,000 = 3,000,000 series.
- That per-user detail belongs in traces and logs, which store it per event, not in metric labels.
Result: Good observability puts each question in the signal that answers it cheaply: totals in metrics, individual requests in traces, details in logs, all linked.
Common mistakes
- Three tools with no links. Metrics, logs and traces that cannot be joined by a trace ID or a timestamp make every investigation slow.
- Unbounded labels. User IDs, request IDs or URLs with IDs in metric labels explode cardinality and cost.
- Collecting everything, reading nothing. Data without questions is just a bill. Start from the questions your incidents ask.
- Dropping the outside view. Inside data can be green while DNS, TLS or a CDN keeps users out. Keep external checks too.
How Vigil handles observability
- Vigil takes traces, metrics and logs over OpenTelemetry (
/otlp/v1/traces,/otlp/v1/metrics,/otlp/v1/logs), plus its own server agent, Prometheus remote write, Sentry-protocol errors and real user data. - Log lines link to their traces, and Time Detective shows failed checks, alerts, host peaks, errors, log errors, deploys and traces around any moment in one view.
- Log pipelines can turn log fields into metrics, so you can chart something without changing code.
Observability: frequently asked questions
What is the difference between monitoring and observability?
Monitoring watches known conditions and alerts when they break. Observability is the property that lets you investigate unknown problems from the data. You need both: monitoring to know something is wrong, observability to find out why.
What are the three pillars of observability?
Metrics, logs and traces. Many teams add events, profiles and real user data; what matters most is being able to move between them for one request or one moment.
Is observability only for microservices?
No. A single application on one server still benefits from traces, structured logs and metrics; the need grows with the number of moving parts.