No observability without theory
summary
Claim: more telemetry alone doesn’t buy observability; interpreting outputs requires a maintained theory of system behavior. Practical moves: design dashboards as compact sections (black‑box metrics saturation latency error rate throughput, developer internals like cache hit rate and goroutine counts), name alerts conversationally, include dashboard/log/trace links, and aim for a minimal covering set of monitors. During incidents run explicit differential diagnosis (list symptoms, propose falsifiable hypotheses, take rule‑out actions). At HashiCorp practice: embed devs in production hunts and shrink dashboards to the smallest useful symptom set.
AI-written summary · about
chapters (8)
- 0:00Introduction and perspective
- 1:34The role of theory
- 3:34The data-theory balance
- 8:10Communicating theory in dashboards
- 13:33Integrating alerts and monitors
- 15:28Hypothesis-driven incident response
- 18:14Developing system intuition
- 20:18Q&A and closing
related talks
25mBeyond Dashboards: Cultivating the Observability Mindset
24mObservability Through Users' Eyes and How To Fix the Knowledge Disc...
39mThe 5W’s of Observability with Practical Examples
42mObservability can help you understand change
38mThe Ticking Time Bomb of Observability Expectations
40mDemystifying Observability and Monitoring
31mObservability for Developers: How to Get There
29mObservability for Developers: How to Get From Here to There