Observability, Monitoring, and Logging
What the exam tests
Observability, Monitoring, and Logging tests metrics, logs, traces, SLIs and SLOs, alert design, and cost-aware telemetry. Expect golden signals, structured logging, distributed tracing, and error budgets.
Core rules
- The three pillars are metrics (aggregated numbers), logs (discrete events), and traces (request paths). Correlate them with trace IDs.
- Monitor symptoms users feel: latency, traffic, errors, and saturation-the four golden signals. Alert on SLO burn, not every CPU spike.
- Use structured JSON logs with consistent fields; redact PII and secrets before ingestion.
- Set retention by value: short hot retention for debugging, longer cold storage for audit.
Worked example
An API has an SLO of 99.9% availability over 30 days. The error budget is about 43 minutes. Create a multi-window burn-rate alert: page if the 1-hour burn rate exceeds 14.4x (2% of budget in one hour), and ticket if the 6-hour rate exceeds 6x. Reasoning: burn-rate alerts catch fast outages and slow leaks while ignoring brief blips that do not threaten the SLO.
Traps
Alerting on causes such as high CPU rather than symptoms such as elevated errors. High-cardinality labels such as user ID in metrics. Logging credentials or tokens. No trace context propagation. Retaining everything forever.