Go (eBPF)

Go is the one runtime the agent does not inject. It compiles to a static binary with no runtime to attach an agent to. So instead of code injection, the agent covers Go services through extended Berkeley Packet Filter (eBPF) monitoring. There is no Instrument toggle to turn on for a Go service. It is covered automatically wherever eBPF monitoring is active: on Linux, Kubernetes, and Docker, but not on Windows, which has no eBPF.

Rich eBPF coverage for Go

Go gets more from eBPF than other runtimes do. The agent’s eBPF tracer follows Go programs closely enough to produce traces across many protocols:

• HTTP
• gRPC
• Kafka
• Redis
• SQL
• MongoDB

The result is close to what a language SDK would produce, without changing your code or your build.

How Go traces connect to other services

eBPF monitoring and the language agents both propagate W3C trace context (traceparent). So when an instrumented service calls a Go service, the Go service’s eBPF span joins the caller’s trace. You see one connected trace with the correct parent-child links, not two separate views.

Note

In the Discovered Services list, a Go service is marked as covered by eBPF rather than as one you can instrument, and its Instrument toggle is disabled. This is expected: eBPF monitoring is already tracing it.

Next steps

eBPF observability Configure eBPF monitoring that covers Go.

Application APM overview How opt-in instrumentation works for other runtimes.

View traces See the distributed traces in KloudMate.