Observability: Building Confidence & Answering the What, Where, How
summary
Defines observability as being able to understand any system state from outside and contrasts it with monitoring, names Honeycomb, Prometheus, Datadog and OpenTelemetry, warns against renaming teams without changing practice, and says auto‑instrumentation fails without intentional fields. Reports typical implementations put 300–500 dimensions per event and use bubble query diffing to find correlated causes. Recommends SRE-driven onboarding, puts engineers on call to teach curiosity, and treats observability as tooling plus human judgment.
AI-written summary · about
chapters (15)
- 0:00Observability introduction
- 2:08Observability vs monitoring
- 5:15Market confusion on observability
- 8:46Observability team structure
- 12:39From NOC to user-centric
- 15:49Myth of three pillars
- 16:51User perspective observability
- 18:36Key metrics to measure
- 21:45Human thinking in observability
- 24:12User expectations and reliability
- 25:35OpenTelemetry data role
- 27:20Engineer empowerment
- 28:24Teaching observability skills
- 31:55Breaking silos with peers
- 33:19Avoiding leapfrogging pitfalls
related talks
42mObservability can help you understand change
29mObservability; a gentle introduction
39mThe 5W’s of Observability with Practical Examples
45mObservability is for User Happiness
48mOur Path to Observability
08m“Observability for testers”
13mObservability Where are We Headed?
32mThe Role of Observability in Cloud Native Environments