We’re going to instrument a Go program without touching its source, and the whole change fits in one build command. Here’s the before and after: 1 2 go build -o myapp . otelc go build -o myapp . Same flags, same package, one extra word in front. The binary that comes out has OpenTelemetry instrumentation compiled in for the libraries otelc knows about, net/http and gRPC among them, and nobody opened a handler file. ...
We’re going to put a probe on one small Go function, twice. First the way OBI (OpenTelemetry eBPF Instrumentation) does it today, then the way a USDT site would. On the way we’ll price a single probe hit, and find that USDT’s pitch is not a discount. This is a companion to the How to Instrument Go Without Changing a Single Line of Code series, between Part 2 and Part 3. The series accompanies my GopherCon UK talk. Part 2 showed what OBI sees. Here we look at how it gets its probes onto Go code, and why USDT keeps coming up. Our function is below. The //go:noinline keeps the compiler from folding it into main, so there is something left to probe. ...
Take one HTTP request, GET /orders/42, headed for a Go service nobody is going to rebuild this quarter. We want a span for it, another for its database call, and the trace context handed on to the next service, all without touching the service. “Zero code changes” travels far in conference talks and vendor docs. Today we watch that one request from the kernel and find out where the phrase holds. ...
Start a Java service with one extra flag and it gets traced, with no source change and no rebuild: 1 java -javaagent:agent.jar -jar app.jar The JVM offers each class’s bytes to the agent’s ClassFileTransformer before it defines the class, so the agent can rewrite a method on its way in. Python lets you swap a method at runtime, which is the monkey-patching of the title. That flag is Java’s agent slot, and Python doesn’t even need one. Go has no such slot, and that follows from how Go was designed. ...
This post expands on the FOSDEM 2026 Go Devroom talk I co-presented with Hannah S. Kim. The talk, demo code, and all benchmark scenarios are available in the fosdem-2026 repository. The Problem Go is one of the best languages for building production backend services. It compiles to native binaries, has excellent concurrency primitives, and produces predictable performance characteristics. But when it comes to auto-instrumentation — adding observability without modifying source code — Go is uniquely difficult. ...