Improving Observability of Distributed Systems
summary
A concrete playbook for turning a startup stack into an observable system: add trace ID in logs to correlate multi-service failures, collect the four golden signals (latency, traffic, errors, saturation), and sample traces with OpenTracing, Jaeger, Zipkin rather than logging every event. Shows building an in-house tracer, then using Zipkin UI to see waterfall traces; metrics store a year of history, logs keep errors 30 days/warnings one week/info one day; detects an AWS Frankfurt outage in ~1 minute and opens a 5‑minute war room.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 3:44What is Observability
- 5:43Three Pillars of Observability
- 8:45Service Level Agreements
- 12:11How do you know its working
- 17:06Reddit
- 18:22How we get there
- 23:19The Four Golden Metrics
- 27:46Bad Example
- 28:41Good Example
- 34:02Logs
- 36:26Traces
- 39:49Propagation
related talks
01h 02mAdding Observability to Distributed Systems
16mThe State of Observability
01h 07m"Adding Observability to Distributed Systems"
55mBeginner's guide to observability
42mDistributed Monitoring: How to understand the Chaos
33mEffective observability in microservice architectures
31mObservability for Developers: How to Get There
48mObservability or How to Know the State of Your System