Observability is the ability to infer a system’s internal state from what it emits. The term marks a distinction from classic monitoring: monitoring checks states defined in advance, observability lets you ask questions you had not thought of.
Why the distinction matters
Classic monitoring answers known questions: is the service up, is the disk full, is the database responding? That suffices for known failure modes. In distributed systems, though, the interesting failures are usually unknown: a particular request type is slow for a particular customer group, but only at certain times. That question cannot be set up in advance as a check — you must be able to put it to the data afterwards.
The three signal types
A three-way distinction is conventional. Logs are event records with detail; they answer what exactly happened. Metrics are aggregated series over time; they answer how much and how fast. Traces follow a single request across several services; they answer where the time went. Each type alone has blind spots, and only together do they form a picture.
Correlation is the real value
The decisive point is not the volume of data collected but the ability to join it. A metric shows response times have risen; a trace shows which step is slow; a log shows why. Without a shared identifier making a request identifiable across all three layers, each layer stands alone and debugging becomes guesswork.
What should raise an alert
The most common design flaw is alerting on technical quantities rather than on impact. High processor load is not a problem as long as users notice nothing. What makes sense is alerting on what affects users: error rate, response time, availability of a core function. Everything else belongs in a dashboard you look at when needed, not in a notification that wakes somebody.
Alert fatigue
Too many alerts are worse than too few. Anyone receiving daily notifications that require no action stops looking — and then misses the one that counts. Every alert should therefore answer what the person woken should concretely do. If that cannot be answered, it is not an alert.
Practical consequence
A pragmatic start consists of three steps: a request identifier carried through all services, structured rather than free-text logs, and a small number of alerts on user-visible impact. That is considerably less effort than a full observability stack and covers most of the value.