OpenTracing Project Deep Dive
summary
OpenTracing provides a narrow, stable API to instrument libraries so they propagate trace id and span id without hardwiring a backend; it uses inject/extract HTTP headers and supports child_of and follows_from causal links plus tags like an error tag and timestamped span events. It deliberately avoids storage or analysis, expects sampling, notes clock-skew and long-running-trace limits (e.g., multi-hour MapReduce needs custom visualizers), and flags serverless (Lambda) as an implementation challenge.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 2:20What is distributed tracing
- 7:05Why there is confusion
- 12:50Shared Libraries
- 14:14API Standardization
- 15:41Analysis Systems
- 17:39Reference Types
- 19:11Shopping Cart Experience
- 21:59Tracing vs Logging
- 26:39Adding Trace IDs
- 30:00Errors and Exceptions
- 33:32API Stability
related talks
23mIntroduction to OpenTracing
26mOpenTracing Isn't Just Tracing: Measure Twice, Instrument Once
33mOpenTracing and Containers: Depth, Breadth, and the Future of Tracing
16mPragmatic execution tracing
19mKeynote: OpenTracing and Containers: Depth, Breadth, and the Future of Tracing - Ben Sigelman
13mStart Tracing on Day Zero
21mOpen Telemetry
48mOpenTelemetry: Backwards Compatibility with OpenTracing and OpenCensus