Strategies for Auto-Instrumenting Go Applications Without Code Changes
summary
Benchmarks compare OpenTelemetry eBPF runtime hooking vs Orchestrion (DataDog) compile‑time instrumentation using K6 load tests and a simple HTTP+DB example with a 1-in-10 injected error. Baseline sees ~21 errors/sec; P99 latencies land around 32–33 ms for both auto‑instrumented runs versus ~39 ms default and ~33/27 ms for manual spans. eBPF uses kernel trampolining and needs Linux + privileged access; Orchestrion uses tool exec to bake instrumentation into the build and is more stable, secure, and portable.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 2:14What is telemetry
- 3:16Auto instrumentation types
- 4:19Runtime eBPF
- 5:44Compile time Orchestrion
- 7:31Benchmark setup
- 10:25Live demo results
- 14:45Runtime vs compile time
- 17:37Which approach wins and why
- 18:00Future of auto instrumentation
- 19:24Final thoughts
related talks
39mAuto-Instrumenting Go Libraries for Tracing with eBPF and OpenTelemetry
33mInstrument Go Without Changing a Single Line
30mDynamically Instrumenting Go Programs
43mAutomatically Instrument Your Go Source Code with Orchestrion
25mWhere’s the Auto in Auto-Instrumentation? A Look at Current Automation Strategies with OTel
45mSimplifying Instrumentation in complex systems at scale with Open Telemetry
40m"Auto-Instrumenting Rust Applications Using eBPF and OpenTelemetry"
19mInstrumenting Go Apps With OpenTelemetry