Go

Go is the one runtime the agent doesn’t 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 eBPF monitoring. There’s no SDK option for a Go service. It’s covered by eBPF wherever eBPF monitoring runs: on Linux, Kubernetes, and Docker, and on Amazon ECS EC2. Go isn’t traced on Windows or on ECS Fargate, neither of which runs eBPF, though the service still gets logs and metrics there.

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 offers Off and eBPF but not SDK. eBPF is already tracing it at the kernel level, so there’s no in-process agent to add.

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.