O OpenTelemetry anunciou a primeira versão estável da instrumentação em tempo de compilação para Go: troque go build por otelc go build no seu pipeline e a ferramenta injeta traces e métricas em binários Go, dependências e biblioteca padrão incluídas — sem uma linha de código alterada na aplicação.
O problema que isso resolve
Java, Python, Node.js e .NET têm suporte a agentes de instrumentação automática há anos: você anexa o agente na inicialização e a telemetria começa a fluir. Go ficou de fora. Um binário Go é estático, sem runtime para interceptar em tempo de execução — e isso obrigava times a instrumentar manualmente cada handler, cada chamada de banco, cada cliente HTTP.
A saída existente era usar o eBPF Instrumentation (OBI) para observar o processo de fora, ou escrever a instrumentação na mão usando o SDK OTel para Go. Ambas têm limitações: OBI não cobre todos os padrões de código Go; instrumentação manual demanda esforço contínuo à medida que o serviço cresce.
A instrumentação em tempo de compilação fecha esse gap. Ela usa o mecanismo -toolexec do toolchain Go para intervir durante o go build e injetar a telemetria nas bibliotecas à medida que o código é compilado. O resultado é um binário normal, sem agente externo, sem overhead de reflexão em runtime.
Como usar
Instale o otelc com o próprio toolchain:
go install go.opentelemetry.io/otelc/tool/cmd/otelc@latest
Substitua go build por otelc go build:
otelc go build -o meuapp .
Tudo que viria depois de go é repassado ao toolchain normalmente. Flags, tags, variáveis de ambiente — nada muda. O otelc descobre as bibliotecas instrumentadas presentes no módulo e injeta a telemetria automaticamente.
Se você quiser manter go build intacto no comando mas ainda passar pela ferramenta, a alternativa é configurar via GOFLAGS:
otelc setup
export GOFLAGS="${GOFLAGS} '-toolexec=otelc toolexec'"
go build -o meuapp .
O mesmo vale para Dockerfiles com multi-stage build: instale o otelc na stage de compilação e substitua a linha de build. O binário final fica idêntico em tamanho e comportamento — a diferença está na telemetria que flui para o seu backend OTel.
O que é coberto no v1
O v1 estável inclui instrumentação para as bibliotecas mais comuns no ecossistema Go de produção:
net/http(servidor e cliente)database/sql- gRPC
- Redis
- Métricas de runtime do Go
A telemetria segue as convenções semânticas do OpenTelemetry, o que garante compatibilidade com qualquer backend — Jaeger, Grafana Tempo, Datadog, Honeycomb, entre outros.
Para bibliotecas ainda não cobertas, o projeto usa um formato de regras extensível. Você pode escrever uma regra para a biblioteca que precisa sem esperar uma nova release do otelc.
Quando usar cada abordagem
O OTel para Go agora oferece três formas complementares de obter telemetria:
| Abordagem | Quando usar |
|---|---|
Compile-time (otelc) | Você pode reconstruir o binário e quer cobertura de dependências sem alterar o código |
| eBPF (OBI) | Você não pode recompilar, ou precisa observar múltiplas linguagens de fora do processo |
| Instrumentação manual | Spans customizados, telemetria específica de domínio — compõe bem com as outras duas |
As três abordagens se complementam. Um serviço pode usar otelc para a cobertura automática de net/http e database/sql e ainda adicionar spans manuais nos pontos críticos do negócio.
O que vem a seguir
O roadmap público do projeto lista três prioridades após o v1:
- Mais instrumentações — ampliar a cobertura para mais frameworks e clientes populares no ecossistema Go.
- Descoberta via Registry — usar o OpenTelemetry Registry para distribuir instrumentações, sem precisar aguardar release do
otelc. - Performance — reduzir custo de build e runtime à medida que a base de regras cresce.