Mirror, mirror, tell me if I'm observable?
summary
Describes replacing ad hoc dashboard thresholds with a structured Failure Mode and Impact (FMI) analysis and Risk Priority Number (RPN) scoring to prioritize alerts and reduce false positives and MTTR. Shows how the monolithic FixeMyBike app was refactored into containerized microservices instrumented with OpenTelemetry and monitored with Prometheus, Grafana, Tempo and Loki to collect per-request traces and speed up failure investigation.
AI-written summary · about
chapters (15)
- 0:00Observability intro
- 1:04Monitoring vs observability
- 4:12Fix My Bike v1.0 case
- 6:04Monitoring failure & bad alerts
- 8:34FMEA for logs & monitoring
- 14:36Fix My Bike v2.0 evolution
- 17:28SRE service objectives
- 23:54Traditional monitoring limits
- 26:44Modern architecture needs
- 28:08Traces & OpenTelemetry
- 31:22OpenTelemetry instrumentation demo
- 33:06Grafana Tempo traces
- 35:37Performance & user stats
- 39:35Best practices
- 41:03Q&A
related talks
43mMirror, Mirror Tell Me If I Am Observable?
41mMetrics Applied
53mUnmask hidden issues with Observability superpowers!
52mHolistic Monitoring
29mParanoid Observability –Success Stories and Misfortunes observing an observability stack
52mIs your JVM app flying blind? Unmask hidden issues with Observability superpowers!
56mFull-stack observability and application monitoring with
38mThe Murphy's Laws of Observability