Monitoring, Logging, and Observability
What this domain tests
Monitoring, Logging, and Observability tests the three pillars of metrics, logs, and traces; SLIs, SLOs, and error budgets; golden signals; alert design; structured logging; and distributed tracing.
Core rules and concepts
- Metrics are cheap aggregates for trends and alerting; logs carry discrete event detail; traces show request paths across services. Correlate them with trace and request IDs.
- Define SLIs as user-centric measures such as availability, latency, and error rate. Set SLOs and derive an error budget. A 99.9% monthly SLO allows about 43 minutes of unavailability.
- Alert on symptoms users feel, such as error rate and latency, rather than every cause such as CPU or disk. Cause-based signals belong on dashboards or tickets.
- Use multi-window burn-rate alerts for SLOs: a fast burn catches outages, a slow burn catches chronic erosion.
- Logs should be structured, include correlation IDs, and exclude secrets and personal data.
- Watch metric cardinality: user ID or request ID as a label can explode storage and cost.
Worked example
Checkout latency SLO is 99.9% under 300 ms. A dashboard shows CPU at 95%, but latency is normal. Reasoning: CPU is a cause signal, not a user symptom. Paging on CPU would wake an engineer for a non-incident. Instead, alert on the latency burn rate and use CPU saturation to explain a confirmed latency incident. If CPU stays high and latency degrades, the burn-rate alert fires with actionable context.
Traps that cost marks
- Calling a tool observability while only collecting pre-defined dashboards.
- High-cardinality labels on metrics.
- Logging full request bodies containing tokens or personal data.
- Alerting on every threshold change, producing fatigue and ignored pages.
- Setting SLOs from infrastructure metrics rather than user experience.