Observability that matters
summary
Argues that observability pays only when tied to concrete goals: define SLIs/SLOs, use instrumentation to answer specific questions, and measure whether fixes actually reduce incidents. Warns against an obsession with tooling and against bolting observability on after release, urges developers to emit logs, metrics, traces during development. Recommends starting small, educating teams, preferring open standards to avoid lock‑in, and designing for different needs—firefighting vs optimization—so queries run fast for incidents and comprehensive for gradual improvement.
AI-written summary · about
chapters (19)
- 0:00Intro
- 0:33B17 Flying Fortress
- 1:26Abraham Wald Walt
- 1:47Army Analysis
- 3:12Tradeoffs
- 3:51Complex systems
- 4:21Observability
- 5:37Distributed traces
- 5:58Theory and practice
- 6:25Obsession with tooling
- 6:35Symptoms ofObsession
- 6:56Observability Tools
- 7:26Mike Julian
- 9:24How do you change this
- 9:46Antipattern
- 10:01No value in observability
- 10:36Optimization vs firefighting
- 11:32Remedies
- 11:43Conclusion
related talks
29mObservability; a gentle introduction
24mOperationalizing Observability: The Invisible Parts
29mObservability for Developers: How to Get From Here to There
27mOpening the Door to Observability
42mObservability can help you understand change
53mObservability Driven Development
30mObservability is More than Logs, Metrics & Traces
31mObservability for Developers: How to Get There