Observability is how you understand what your system is doing from its outputs. The three pillars — logs, metrics and traces — answer different questions, and together they tell the full story of a request.
The distinction matters: monitoring asks "is it up?" Observability asks "why is it slow?" The first needs dashboards; the second needs data you can interrogate.
Logs: what happened
Logs are timestamped records of events. They are the most detailed pillar and the noisiest.
- Best for debugging specific failures.
- Structured (JSON) logs are searchable; free-text logs are not.
Metrics: how it is behaving
Metrics are aggregated numeric measurements over time: latency, error rate, CPU.
- Best for dashboards and alerting.
- Cheap to store; designed for trends, not details.
Traces: where the time went
Traces follow a single request across services, showing each step and its duration.
- Best for finding bottlenecks and latency.
- Connect the dots that logs and metrics leave open.
Start with metrics for alerting and one good trace per service. Logs are where you end up investigating — keep them structured so you can search them.
The practical setup
Use a stack like Prometheus (metrics), OpenTelemetry (traces), and a structured logging pipeline. Start small: instrument your critical path first.
Observability FAQ
What is the difference between monitoring and observability?
Monitoring checks known indicators with alerts. Observability lets you answer unknown questions by exploring rich telemetry data.
Do I need all three pillars?
For a serious production service, yes — they answer different questions. Start with metrics, add traces, then enrich logs.
