OpenTelemetry: Panel Discussion and Q&A
summary
OpenTelemetry merges OpenTracing and OpenCensus into one project that prioritizes backwards compatibility with two years of guaranteed bridges and migration paths while the older projects become read only. It plans canonical client libraries (Java prioritized, September milestone), a standalone collector/agent for buffering, tail based sampling and runtime exporter changes, and adoption of the w3c trace context for propagation. It already targets Jaeger Zipkin Prometheus compatibility, offers bridges for mixed formats, and uses elected governance modeled on Kubernetes.
AI-written summary · about
chapters (31)
- 0:00Intro
- 1:25Who is using OpenTelemetry
- 5:30What is problematic about OpenTelemetry
- 7:10What would you like to see
- 7:30Ecosystem confusion
- 8:55What is OpenTelemetry
- 9:13What does OpenTelemetry do
- 9:58Instrumentation API
- 11:30Client Libraries
- 12:27Data Collection
- 14:33Goals Timelines
- 14:45Static
- 15:49Goals for the year
- 17:33Governance
- 19:26Panel Discussion
- 20:03Whos joining
- 20:41Introduce yourself
- 22:36W3C headers
- 27:08What should you use
- 30:31dynaTrace
- 32:39OpenTelemetry vs Open Census
- 35:46Operation names in trace context
- 37:59Standardizing the context API
- 40:29Context should be split out
- 42:28Open Metrics
- 43:57OpenTelemetry Formats
- 45:17OpenTelemetry Protocols
- 48:59Correlation
- 54:02GRPC support
- 56:57Elastic project
- 58:12Vendor support
related talks
34mOpenTelemetry: Overview & Backwards Compatibility of OpenTracing + OpenCensus
34mOpenTelemetry: Overview & Backwards Compatibility of OpenTracing + OpenCensus
01h 08mOpenTelemetry: The First Release, What’s Next, and How to Get Involved
36mPanel: OpenTelemetry...
43mWhat is this OpenTelemetry thing?
21mOpen Telemetry
46mThe State of OpenTelemetry
22mOpenTelemetry – An Observability Framework for Cloud-Native Software