// the find
alibaba/loongsuite-go
OpenTelemetry Compile-Time Instrumentation for Golang
A Go variant of OpenTelemetry auto-instrumentation that works by wrapping `go build` instead of requiring manual SDK calls or runtime agents — you prefix your build command with `otel` and it rewrites the code at compile time to inject spans/metrics for ~60 supported libraries (gin, grpc, redis, mongodb, kafka, plus newer entries like anthropic-sdk-go, openai-go, mcp-go). Aimed at teams who want OTel coverage across a Go service fleet without touching every call site by hand.
Compile-time rewriting avoids both the runtime cost of reflection-based agents and the maintenance cost of hand-wiring OTel calls into every HTTP/DB/queue client — a real architectural difference from typical Go instrumentation, not just a wrapper around otelhttp. Library coverage is unusually wide and current, including GenAI SDKs (anthropic, openai, eino) that most OTel Go tooling hasn't caught up to yet. CI is serious: separate workflows per instrumentation depth and per plugin batch, plus muzzle-style tests pinning min/max supported versions per library, which is the kind of thing that actually catches breakage before users do. It's not a one-off fork either — this codebase was upstreamed and became the seed for the official opentelemetry-go-compile-instrumentation project, so the approach has outside technical validation.
Hard requirement of Go 1.25+ for both the tool and the instrumented application is a real adoption blocker — most production Go codebases aren't on the latest release, and this isn't a 'works on older Go with a flag' situation. Wrapping `go build` means changing your build pipeline (Dockerfiles, Makefiles, CI scripts) to call a separate binary instead of the standard toolchain, and the README's own caveat — 'if you find compilation failures while go build works, it's likely a bug' — admits the rewriting step isn't bulletproof yet. The project sits alongside a paid Aliyun ARMS commercial tier and leans on DingTalk (a Chinese enterprise chat app) for community support, so non-Chinese-speaking users may find documentation and community help thinner than the library list suggests. No published overhead numbers in the README itself — there's a benchmark example directory, but you'd have to run it yourself to know the actual compile-time and runtime cost before adopting this at scale.