DEV.co
Open-Source Observability · alibaba

loongsuite-go

Loongsuite Go Agent is an Alibaba-maintained OpenTelemetry instrumentation tool for Go applications that requires zero code changes—instrumentation happens at compile time by prefixing `go build` with `otel`. It automatically instruments tracing, metrics, and logs across 80+ popular Go libraries and frameworks.

Source: GitHub — github.com/alibaba/loongsuite-go
879
GitHub stars
118
Forks
Go
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositoryalibaba/loongsuite-go
Owneralibaba
Primary languageGo
LicenseApache-2.0 — OSI-approved
Stars879
Forks118
Open issues30
Latest releasev1.12.0 (2026-06-25)
Last updated2026-07-07
Sourcehttps://github.com/alibaba/loongsuite-go

What loongsuite-go is

A compile-time instrumentation wrapper around Go's build toolchain that injects OpenTelemetry probes into binary artifacts without modifying source code. Supports 80+ libraries including gRPC, database/sql, gin, Kafka, Elasticsearch, and AI SDKs; distributed as prebuilt binaries for Linux AMD64/ARM64, macOS, and Windows.

Quickstart

Get the loongsuite-go source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/alibaba/loongsuite-go.gitcd loongsuite-go# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Rapid APM enablement without code refactor

Add observability to large legacy Go codebases or third-party binaries where modifying source is infeasible or undesirable. Simply re-compile with the otel wrapper.

Multi-library microservice instrumentation

Uniformly instrument microservices using diverse frameworks (Gin, Kratos, gRPC, Kafka) and databases (PostgreSQL, MongoDB, Elasticsearch) via a single build flag.

Compliance-driven observability rollout

Enforce OpenTelemetry observability across teams and services without requiring training on instrumentation SDKs; build process handles signal collection.

Implementation considerations

  • Prebuilt binaries (Linux AMD64/ARM64, macOS, Windows) are the recommended installation method; curl-based install script is available for *nix. Verify binary architecture matches your build environment.
  • Build command syntax is minimal—replace `go build` with `otel go build`—but ensure build flags (e.g., `-gcflags`, `-ldflags`) are compatible. README notes compilation failures are treated as bugs.
  • Instrumentation is automatic but output configuration (exporter, endpoint, sampling) requires runtime setup via environment variables or config files; tool itself has no built-in OTEL endpoint defaults.
  • Test compile-time builds in CI/CD pipeline before deployment; rollback strategy is to re-compile without `otel` prefix if overhead or side effects surface in production.
  • Supported library versions have explicit min/max constraints (e.g., gRPC v1.44.0–v1.63.0, MongoDB v1.11.1–v1.15.2). Pin exact library versions in go.mod to ensure predictable instrumentation.

When to avoid it — and what to weigh

  • Need runtime configuration flexibility — Compile-time instrumentation is static; dynamic feature flags, sampler changes, or library list updates require rebuilds. Not suitable for volatile observability policies.
  • Require custom instrumentation logic — Tool provides fixed instrumentation patterns. If your use case needs bespoke probe placement, context propagation, or domain-specific metrics, manual SDK integration is necessary.
  • Targeting exotic or cutting-edge libraries — Support matrix is fixed to 80+ popular libraries. Newer or niche packages not in the supported list will not be instrumented automatically.
  • Minimal binary size or startup overhead critical — Instrumentation increases compiled artifact size and runtime overhead (benchmark example provided but real impact varies). Latency-sensitive applications should measure before committing.

License & commercial use

Licensed under Apache License 2.0 (Apache-2.0), a permissive OSI license.

Apache-2.0 is a permissive license allowing commercial use, modification, and distribution with minimal restrictions (provide copy of license, note changes, retain copyright). However, Alibaba also offers a commercial variant (Aliyun ARMS) referenced in README; ensure your commercial use aligns with this open-source version's obligations and does not conflict with any commercial offerings you may be considering.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityLow
DEV.co fitGood
Assessment confidenceHigh
Security considerations

No security audit, CVE history, or vulnerability disclosure process mentioned in provided data. Compile-time instrumentation could mask or interfere with binary hardening (e.g., stripping, PIE); test security scanning tools post-compilation. Execution of prebuilt binary requires trust in Alibaba's build pipeline (no reproducible build evidence provided). Binary injection of probes increases attack surface for supply-chain compromise if binary source is compromised; verify checksums if available.

Alternatives to consider

OpenTelemetry Go SDK (manual instrumentation)

Full control over instrumentation granularity and logic; requires code changes and developer discipline but offers flexibility for custom metrics, dynamic sampling, and business context.

Datadog Go agent or New Relic Go agent

Commercial APM agents with pre-built instrumentation for popular libraries, runtime overhead optimization, and vendor-managed exporter. Trade-off: vendor lock-in and commercial licensing.

eBPF-based observability (e.g., Cilium, Pixie)

Kernel-level instrumentation without binary modification or recompilation; captures network and syscall-level observability. Trade-off: requires Linux, no application logic visibility, different observability model.

Software development agency

Build on loongsuite-go with DEV.co software developers

Try the tool with your largest microservice: download a prebuilt binary, re-compile with `otel go build`, and run a benchmark. Compare overhead and coverage against manual SDK instrumentation. If zero-code instrumentation aligns with your deployment workflow, request a Devco architecture review for integration planning.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

loongsuite-go FAQ

Do I need to change my Go source code to use loongsuite-go?
No. The tool instruments at compile time via the `otel` wrapper. Simply replace `go build` with `otel go build`. No code modifications required.
What if a library I use is not in the supported list?
Unsupported libraries will not be automatically instrumented. You have two options: (1) manually add OpenTelemetry SDK instrumentation for that library, or (2) request support by filing an issue on GitHub.
How do I configure where traces and metrics are exported?
The tool itself does not configure exporter endpoints. Runtime OpenTelemetry configuration (exporter, collector endpoint, sampling policy) is managed via environment variables or config files passed to your application at runtime. Refer to OpenTelemetry Go SDK docs for details.
What is the runtime overhead of instrumentation?
Overhead varies by library and workload. Examples are provided in the benchmark directory; you should measure in your own environment before production deployment. Overhead is static (compile-time) and cannot be toggled at runtime without recompilation.

Work with a software development agency

Adopting loongsuite-go is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate open-source observability software in production.

Evaluate Loongsuite Go for your observability strategy

Try the tool with your largest microservice: download a prebuilt binary, re-compile with `otel go build`, and run a benchmark. Compare overhead and coverage against manual SDK instrumentation. If zero-code instrumentation aligns with your deployment workflow, request a Devco architecture review for integration planning.