Top 5 Things to Know Running OpenTelemetry on Kubernetes
summary
OpenTelemetry is vendor‑neutral and production‑ready for many languages, with Java and .NET SDKs marked stable while Node/Python approach stability; OTLP sends instrumented metrics, logs and traces to a backend (New Relic shown as an example) via a collector: receiver, processor, exporter that supports tail-based sampling to keep only actionable traces and dramatically reduce stored traces. Deployment options: agent/daemonset or standalone collector (scaleable) and a stable Kubernetes operator plus sidecar auto-injection for quick rollout.
AI-written summary · about
chapters (13)
- 0:00OpenTelemetry on Kubernetes intro
- 1:06Why OpenTelemetry grows fast
- 3:16Four strengths of OpenTelemetry
- 5:25Design before implementation
- 7:35Six planning questions
- 11:25Core instrumentation concepts
- 13:21Auto vs manual instrumentation
- 16:32OpenTelemetry Collector explained
- 19:01Head vs tail sampling
- 21:09Collector deployment options
- 22:15Deploying with Kubernetes Operator
- 23:42Recap and key takeaways
- 26:11Q&A
related talks
30mOpenTelemetry 101
20mObservability and Open Telemetry
46mThe State of OpenTelemetry
50mGuide to Observability with OpenTelemetry
50mOpen Source Instrumentation - The Rise of OpenTelemetry
34mOpenTelemetry: The Vision, Reality, and How to Get Started
47mWhat Is This OpenTelemetry Thing?
22mOpenTelemetry – An Observability Framework for Cloud-Native Software