Observabilidade não é mais um diferencial – é requisito para qualquer sistema em produção. Mas por muito tempo, métricas (Prometheus), logs (ELK/Loki) e traces (Jaeger) viviam em silos, cada um com sua instrumentação. OpenTelemetry veio para unificar tudo: um único padrão aberto para gerar, coletar e exportar dados de telemetria.
Neste post, vamos entender o que é OpenTelemetry, como instrumentar aplicações Go para gerar métricas, logs estruturados e tracing distribuído, e como enviar esses dados para backends como Prometheus, Jaeger e Loki. Tudo com exemplos práticos e boas práticas.
O que é OpenTelemetry?
OpenTelemetry (também chamado de OTel) é um projeto da CNCF (mesma fundação do Kubernetes) que surgiu da fusão do OpenTracing e OpenCensus. Ele fornece:
- APIs e SDKs para instrumentar aplicações em diversas linguagens (incluindo Go).
- Um formato padrão para dados de telemetria (traces, métricas, logs).
- Coletores que recebem, processam e exportam dados para backends.
A grande vantagem: você instrumenta uma vez e pode enviar para qualquer backend compatível.
Os três pilares da observabilidade com OpenTelemetry
| Pilar | O que é | Backend comum |
|---|---|---|
| Traces | Rastreiam uma requisição por vários serviços (distributed tracing) | Jaeger, Tempo, Zipkin |
| Métricas | Agregados numéricos (ex: latência, taxa de erro, contagem) | Prometheus, VictoriaMetrics |
| Logs | Eventos estruturados com timestamp e contexto | Loki, Elasticsearch |
No OpenTelemetry, logs são o mais novo pilar e ainda estão evoluindo, mas já é possível enviar logs estruturados através do SDK.
Instrumentando uma aplicação Go com OpenTelemetry
A instrumentação pode ser manual (via SDK) ou automática (via bibliotecas de contribuição). Vamos ver os passos principais.
Passo 1: Adicionar as dependências
go go.opentelemetry.io/otel
go go.opentelicom.io/otel/sdk
go go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc
go go.opentelemetry.io/otel/exporters/prometheus
go go.opentelemetry.io/contrib/instrumentation/net/http/otelhttpPasso 2: Configurar o provedor de traces (ex: Jaeger via OTLP)
No código, é necessário criar um provedor de traces e registrá-lo globalmente. O SDK lida com a criação de spans e a propagação de contexto.
Passo 3: Instrumentar o servidor HTTP
Use o middleware otelhttp para capturar traces automaticamente:
handler := otelhttp.NewHandler(meuMux, "servidor")
http.ListenAndServe(":8080", handler)Passo 4: Adicionar spans customizadas
Para pontos específicos do negócio, crie spans manuais:
ctx, span := tracer.Start(ctx, "processar-pagamento")
defer span.End()
// lógica de pagamentoPasso 5: Exportar métricas para Prometheus
Configure um exportador Prometheus e exponha o endpoint /metrics.
Passo 6: Logs estruturados com contexto de trace
Use uma biblioteca de log (ex: slog ou logrus) que injete trace_id em cada entrada.
Exemplo prático: API de pedidos monitorada
Uma API de pedidos instrumentada com OpenTelemetry pode:
- Gerar um trace desde a requisição HTTP até as chamadas de banco e serviços externos.
- Coletar métricas de latência e taxa de erro por endpoint.
- Associar cada log de erro com o
trace_idcorrespondente.
Com isso, quando um cliente reporta “pedido falhou às 14:32”, você localiza o trace pelo horário, vê exatamente onde a falha ocorreu (ex: timeout no serviço de pagamento) e consulta os logs daquele trace específico.
OpenTelemetry Collector: o roteador de dados
O Coletor OpenTelemetry é um componente que recebe dados de telemetria de várias fontes, processa (amostragem, enriquecimento, filtragem) e exporta para um ou mais backends. Ele pode ser executado como um sidecar, daemon ou deployment no Kubernetes.
Vantagens:
- Desacopla a instrumentação do backend.
- Permite enviar o mesmo trace para Jaeger e também para um storage de logs.
- Oferece amostragem adaptativa para reduzir volume.
Comparativo: OpenTelemetry vs. bibliotecas específicas
| Aspecto | OpenTelemetry | Prometheus + Jaeger + libs separadas |
|---|---|---|
| Curva de aprendizado | Média | Alta (cada ferramenta tem sua API) |
| Vendor lock-in | Baixo (padrão aberto) | Médio (cada backend exige instrumentação própria) |
| Facilidade de troca de backend | Alta | Baixa (reinstrumentação) |
| Maturidade | Em evolução, mas estável | Madura |
Para projetos novos, OpenTelemetry é a recomendação. Para sistemas legados, pode-se migrar gradualmente.
OpenTelemetry e Go: dicas práticas
- Propague contexto explicitamente em chamadas HTTP: adicione headers (
traceparent,tracestate) ou useotelhttppara fazer automaticamente. - Para gRPC, use as interceptoras
otelgrpc. - Em workers de fila, extraia o contexto do envelope da mensagem e crie spans filhos.
- Cuidado com overhead: traces têm custo; use amostragem (ex: 1% de requisições) em alta carga.
- Use
otel.SetErrorStatuspara marcar spans como erro quando ocorrer exceção.
Caso real: marketplace com observabilidade total
Um cliente marketplace com 50 microsserviços Go sofria para identificar gargalos. Implementamos OpenTelemetry com:
- Exportador OTLP para Jaeger (tracing).
- Exportador Prometheus (métricas).
- Logs estruturados com
sloginjetandotrace_id. - Coletor OTel agregando dados e aplicando amostragem.
Resultado: tempo médio para identificação de causa raiz caiu de 2 horas para 15 minutos. Migração de um backend de tracing foi feita sem alterar código.
Conclusão
OpenTelemetry é o futuro da observabilidade em sistemas modernos. Em Go, o suporte é maduro e a integração com bibliotecas padrão é direta. Instrumente sua aplicação uma vez e ganhe a flexibilidade de enviar métricas, traces e logs para qualquer backend. O esforço inicial se paga em horas de debug economizadas.
Na Jacobus Software, adotamos OpenTelemetry como padrão em novos projetos. Se você ainda não conhece, vale a pena investir.
🔍 Quer implementar OpenTelemetry nas suas aplicações Go?
Nossos especialistas configuram o SDK, o coletor e os backends – garantindo observabilidade total sem sobrecarregar o time.
👉 Fale com a Jacobus Software