Logging, monitoring and observability are often used interchangeably — what does each one actually mean, and which question does each answer?
Logging records what happened, monitoring checks whether the system is healthy against predefined metrics, and observability infers the internal state from external signals to explain why it behaves as it does.
| Aspect | Logging | Monitoring | Observability |
|---|---|---|---|
| Definition | Recording discrete activities, events and states in structured or unstructured logs | Continuous collection and evaluation of predefined metrics and states | The ability to derive a system's internal state from external signals (logs, metrics, traces) |
| Question | "What happened, and when?" | "Is the system healthy? Is something broken?" | "Why is it broken? What is the cause?" |
| Data | Discrete events | Predefined metrics | Correlation across metrics, logs and traces |
| Typical tools | ELK, Splunk, Loki | Prometheus, Zabbix, CloudWatch | OpenTelemetry, Datadog, New Relic, Grafana Tempo |
| Scaling | Very detailed, but hard to correlate | Limited once complexity rises | Scales well with complex distributed systems |
The three are layers, not competitors. Monitoring tells you that something is wrong; logging gives you the raw record of what occurred; observability is what you get when those signals are correlated well enough to answer why. A shop with excellent logging and no monitoring finds out about outages from its customers; a shop with excellent monitoring and no observability knows a service is slow but not which of its twelve dependencies is to blame.
Tip: three questions, three words — what (logging), whether (monitoring), why (observability).
Go deeper:
Observability (software) — Wikipedia — the term's origin in control theory and how it came to mean logs, metrics and traces.