What makes a system observable?

Monitoring answers known questions with dashboards and alerts. Observability lets you ask new questions during an incident without shipping code. The three pillars are metrics, logs and traces, but the value comes from correlating them around a request, a user or a deployment.

The pillars

• Metrics: cheap time series for rates, errors, durations and saturation, ideal for alerting
• Logs: detailed events with context, useful for debugging but expensive at high volume
• Traces: a request's path across services with span timings and attributes
• Profiles: continuous CPU and memory samples that show where time is spent
• Events: deploys, feature-flag changes and config updates that explain a change in behavior

Useful conventions reduce guesswork. RED metrics cover rate, errors and duration for services; USE covers utilization, saturation and errors for resources. Include a correlation id at the edge, propagate it through every call, and attach it to logs and traces. Record the deploy version and region on every signal so a spike can be tied to a rollout.

Cardinality is the budget. A metric labeled by user id or request id explodes the time-series count and can take down the monitoring system. Keep high-cardinality dimensions in logs or traces, not metric labels. Sample traces at the edge with a strategy that keeps all errors and a representative share of successes.