Signals in context
No single signal tells the whole story.
Metrics summarize behavior over time, such as error rate, latency, saturation, or request volume. Logs record events and context. Traces connect spans from one request as it crosses services and dependencies.
Useful observability joins these signals by time, service, request identity, and deployment context. It also records enough scope to distinguish one client failure from a broad incident.
Judge a change
A signal needs a baseline before it becomes an alert.
Compare a metric with normal behavior for the same service, route, region, and time pattern. A threshold that ignores daily peaks can create noise; a threshold that is too broad can hide a real failure.
Keep enough dimensions to find the affected scope, but avoid labels that create a separate time series for every transient value. Good observability makes alerts actionable: the alert states what changed, where it changed, and which next check can confirm it.
Build the model
Four observability questions
What changed?
Which metric moved from its normal baseline?
Where?
Which service, region, route, or dependency is affected?
Which request?
Can logs and traces follow the same operation end to end?
What next?
Which reversible test can confirm or reject the hypothesis?
Mini investigation
Inspect an observability signal
Select the observed signal and identify the most direct question it can answer.
A metric shows how behavior changed across a population or time window.
Compare the trend with a baseline, scope, and deployment timeline.
Knowledge check
Test your observability model
Answer eight questions. The answer order changes each time.