The Murphy's Laws of Observability
summary
Claims that observability needs raw high-resolution data not glossed aggregates backed by tools: use OpenTelemetry collector to unify traces metrics logs, avoid no-sampling traces loss that masks 95th-percentile latencies (sampled 1–2s vs true 29–40s in an example). Shows architectures with ~43 microservices per product and monitoring across 2247 instances, recommends RED (rate error duration) and service maps to find a 25% error hotspot and tie alerts to trace ids rather than averages.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:16Murphy's Law and observability
- 5:27Deep observability data
- 8:01Microservices and cloud monitoring
- 10:04Tracking unknown unknowns
- 12:55Microservices complexity at scale
- 16:47Serverless challenges
- 18:34Testing at scale
- 20:40Sampled data problems
- 23:24Accuracy vs precision
- 27:37Monitoring hybrid systems
- 30:05Observability to OpenTelemetry
- 34:59DevOps shared responsibility
- 36:24Unknown unknowns importance
- 37:05Closing and Q&A
related talks
30mMurphy’s Laws for observability
32mRules of Observability: The Data Edition
33mEffective observability in microservice architectures
26mYou Can’t Fix What You Can’t See: Tales from the Observability Frontier
39mThe Ticking Timebomb of Observability Expectations
29mObservability; a gentle introduction
33mWhat Developers Should Know About Observability
39mObservability for Emerging Infra: What Got You Here Won't Get You There