13. Observability and Incident Response
Three pillars of observability
- Metrics: numerical time series for rates, latency, errors, saturation, and business outcomes.
- Logs: structured event records with useful context.
- Traces: request paths across services and dependencies.
Useful service indicators
- Request rate.
- Error rate, separated by meaningful error class.
- Latency percentiles, especially p95 and p99.
- Resource saturation: CPU, memory, connection pools, disk, and thread or event-loop pressure.
- Dependency latency and failure rate.
- Queue depth, oldest-message age, consumer lag, and retry counts.
SLO, SLI, and SLA
- SLI: the measured indicator, such as the proportion of eligible requests completed successfully within a latency target.
- SLO: the internal target for that indicator over a defined window.
- SLA: an external commitment, often with contractual consequences.
Logging checklist
- Use structured logs and correlation or trace IDs.
- Avoid secrets, credentials, and unnecessary personal data.
- Include meaningful error context without exposing sensitive payloads.
- Keep timestamps and service identity consistent.
Incident response
- Detect and assess user impact.
- Stabilize the service and reduce the blast radius.
- Communicate status and ownership.
- Restore service using a known safe mitigation.
- Preserve relevant evidence and investigate the cause.
- Conduct a blameless review and track corrective actions.
A dashboard is useful only if it helps someone identify impact, diagnose the problem, or take action. Alert on actionable symptoms and user impact rather than every noisy internal metric.
Key Takeaways
- Measure user-visible outcomes as well as infrastructure health.
- Use metrics, structured logs, and distributed traces together.
- Define SLOs and alerts around meaningful user impact.
- Treat incidents as opportunities to improve systems and procedures.