How OpenTelemetry Instrumentation Works Under the Hood

Add OpenTelemetry to a Python or Node application and traces often appear as if by magic. A launcher patches your libraries, you restart the app, and suddenly Jaeger is full of spans.

Try the same thing in Go and you quickly discover there's no opentelemetry-instrument command that just works. Why not?

This talk starts with that question and follows the path of a span through a Go application. We'll briefly look at what instrumentation really is just code that starts and ends spans at the right moments, and why manual instrumentation remains the norm in Go, using context.Context and libraries such as otelhttp, otelgrpc, and otelsql.

From there, we'll explore the three places where telemetry can be injected into a Go program: directly in your source code, at build time through compiler-assisted rewriting, or externally using eBPF agents attached to a running binary.

By the end of the session, attendees will be able to examine any span in a Go service, explain how it was created, and understand the trade-offs among manual instrumentation, build-time tooling, and eBPF-based observability. loooks good?

• What instrumentation really is: code that starts and ends spans at the right moments, and in Go, that code has to be explicit, because nothing patches it in for you at runtime.

• Why Go has no opentelemetry-instrument: Go compiles to native machine code with no VM and no mutable runtime functions, so the monkey-patching and bytecode agents used in Python, Node, and Java simply don't apply.

• Manual is the norm in Go: the SDK plus context.Context propagation and libraries like otelhttp, otelgrpc, and otelsql are how most real Go services get traced.