---
title: "OpenTelemetry Go: instrumentação automática em tempo de compilação chega ao v1"
url: "https://golang.com.br/novidades/opentelemetry-go-instrumentacao-compile-time-v1/"
markdown_url: "https://golang.com.br/novidades/opentelemetry-go-instrumentacao-compile-time-v1.MD"
description: "A instrumentação automática de Go em tempo de compilação do OpenTelemetry chega ao v1 estável: adicione traces e métricas sem alterar o código-fonte."
date: "2026-07-20"
author: "Go Brasil"
---

# OpenTelemetry Go: instrumentação automática em tempo de compilação chega ao v1

A instrumentação automática de Go em tempo de compilação do OpenTelemetry chega ao v1 estável: adicione traces e métricas sem alterar o código-fonte.


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)](https://opentelemetry.io/docs/zero-code/go/) para observar o processo de fora, ou escrever a instrumentação na mão usando o [SDK OTel para Go](/blog/go-opentelemetry-observabilidade-tracing-metricas/). 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:

```bash
go install go.opentelemetry.io/otelc/tool/cmd/otelc@latest
```

Substitua `go build` por `otelc go build`:

```bash
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`:

```bash
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](https://opentelemetry.io/docs/specs/semconv/), 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:

1. **Mais instrumentações** — ampliar a cobertura para mais frameworks e clientes populares no ecossistema Go.
2. **Descoberta via Registry** — usar o [OpenTelemetry Registry](https://opentelemetry.io/ecosystem/registry/) para distribuir instrumentações, sem precisar aguardar release do `otelc`.
3. **Performance** — reduzir custo de build e runtime à medida que a base de regras cresce.

## Saiba mais

- [Anúncio oficial do v1 (opentelemetry.io)](https://opentelemetry.io/blog/2026/go-compile-time-instrumentation-v1/)
- [Documentação da instrumentação em tempo de compilação](https://opentelemetry.io/docs/zero-code/go/compile-time-instrumentation/)
- [OpenTelemetry em Go: Traces e Métricas — guia de instrumentação manual](/blog/go-opentelemetry-observabilidade-tracing-metricas/)
- [Observabilidade em Go: logs, métricas e traces](/tutoriais/go-observability/)