Guia completo de observabilidade com OpenTelemetry: como instrumentar métricas, logs e traces e visualizar no Prometheus, Grafana e Jaeger
Se a sua pilha em microsserviços e serverless parece um “avião sem instrumentos”, este guia prático resolve o problema: mostra como implementar observabilidade de ponta a ponta com OpenTelemetry, cobrindo tracing distribuído, logs estruturados e métricas em Kubernetes e funções serverless. O objetivo é reduzir MTTR, cortar ruído e dar visibilidade real de causa raiz, com decisões arquiteturais que funcionam no cenário de 2026. O texto prioriza escolhas pragmáticas, apontando ganhos, trade-offs e armadilhas comuns que drenam tempo e orçamento.
Por que começar pelo Collector: o OTel Collector desacopla sua instrumentação do backend de observabilidade. Isso permite trocar Jaeger, Tempo, Prometheus, Loki, OpenSearch, CloudWatch, BigQuery ou o que vier, sem refatorar cada serviço. Em ambientes heterogêneos, é a peça que evita retrabalho e mantém padronização.
Topologias possíveis no Kubernetes:
Em serverless, geralmente use Collector como gateway gerenciado ou externo, recebendo OTLP/HTTP ou OTLP/gRPC da função. Sidecar não é opção em FaaS. Em provedores com saída restrita, avalie VPC endpoints e compressão.
Dica de ouro: padronize a Resource dos sinais (service.name, service.namespace, deployment.environment). Essa coerência multiplica o valor dos dados e evita “ilhas” de telemetria que não se correlacionam.
Auto-instrumentação acelera e cobre HTTP, gRPC, bancos e filas mais comuns. Instrumentação manual é necessária para spans de domínio, filas proprietárias e pontos críticos do funil. Combine as duas para equilibrar velocidade e profundidade.
Siga as convenções semânticas do OpenTelemetry: http.method, http.route, db.system, messaging.system e user.id (apenas se anonimizado). Nomeie spans pelo que fazem (checkout.process) e não pelo componente interno (functionX), facilitando correlação por negócio.
Ative W3C Trace Context (traceparent, tracestate) em todos os serviços e frontends. Sem isso, seu trace se fragmenta. Para ambientes de alto tráfego, prefira amostragem head-based agressiva em produção com regras por rota/erro e tail-based no Collector para reter somente traces valiosos (alta latência, 5xx, pedidos VIP).
O objetivo do tracing distribuído é encadear a jornada de uma requisição entre serviços, filas e bancos, revelando gargalos e falhas intermitentes. Em Kubernetes, injete bibliotecas OTel nos serviços, exporte via OTLP para o Collector e, dele, para seu backend de traces.
Em serverless, envolva o handler com middlewares OpenTelemetry, inicie o span logo na entrada e garanta flush síncrono no final para não perder dados em execuções de curta duração. Em provedores com cold start, registre um atributo cold.start=true quando detectado; isso evita diagnósticos falsos de latência.
Insight prático: traces “bonitos” mas inúteis geralmente ignoram filas e jobs assíncronos. Propague contexto nas mensagens (headers, atributos) e crie links entre spans quando não há relação direta pai-filho.
Troque logs de texto livre por logs estruturados em JSON. Cada log deve conter timestamp com timezone, severity padronizada, service.name, trace_id e span_id. Isso habilita o “pivot”: do erro para o trace, do trace para o log detalhado.
No Kubernetes, encaminhe stdout/stderr dos pods para o Collector via receiver de logs ou use agentes em DaemonSet. Em serverless, utilize o SDK OTel para logs ou faça export OTLP do provedor para o Collector, mapeando campos para manter trace_id e span_id.
Correlacione tudo com trace_id. Um erro em gateway HTTP deve alavancar a busca por spans descendentes e métricas da instância impactada. Para facilitar, padronize nomes de recursos e mantenha o mesmo conjunto mínimo de atributos em todos os sinais.
Métricas sustentam SLOs e alertas silenciosos. Foque no essencial antes de instrumentar “tudo”.
Exportar métricas do Collector para um backend compatível e estável reduz acoplamento. Se usar pull (scrape), mantenha tempos de scrape e retenção alinhados ao volume. Se usar push OTLP, proteja o pipeline com batching e retry.
Ao implantar o Collector como DaemonSet e Gateway, separe pipelines por sinal (traces, logs, métricas) e por ambiente (prod, staging). Defina requests/limits conservadores e monitore fila interna e latência de export. Trate o Collector como software crítico: saúde, readiness, autoscaling e versionamento controlado.
Para workloads, injete variáveis padrão de ambiente com endpoint OTLP, amostragem e atributos de recurso no Deployment/StatefulSet. Em Istio/Linkerd, alinhe portas e timeouts para não truncar tráfego OTLP. Em ambientes multi-tenant, aplique rate limiting e filtragem por namespace no Collector.
Em FaaS, não há daemon local. Os desafios são tempo de execução curto, conexões efêmeras e cold start. Utilize SDKs leves, exporte em lote no final da invocação e habilite compressão. Se o provedor oferecer export nativo para OTLP, aproveite para reduzir sobrecarga. Em rotas de alto volume, imponha amostragem adaptativa para manter custo sob controle.
Pareto da observabilidade em serverless: um bom trace de entrada, logs estruturados com trace_id e um histograma de duração já resolvem 80% dos incidentes comuns.
Não é sobre coletar tudo, é sobre coletar o que responde perguntas. Use processadores do Collector para:
Crie dashboards operacionais do Collector (fila, retries, tempo de exportação). Se o pipeline travar, sua visibilidade acaba no momento mais crítico.
Defina SLOs por rota crítica e conecte alertas a runbooks com passos objetivos: onde olhar, como isolar, como mitigar. Faça revisões trimestrais de instrumentação para cortar métricas obsoletas e ajustar amostragem. Em auditorias, mantenha inventário de serviços com nível de cobertura OTel e lacunas conhecidas.
Para um mergulho complementar nos fundamentos e integrações por linguagem, veja o guia completo de observabilidade com OpenTelemetry em microsserviços.
Não. O OpenTelemetry padroniza coleta, correlação e envio de sinais. Você ainda precisa de um backend para armazenar, consultar e visualizar traces, logs e métricas.
Depende da linguagem e do volume, mas configurações com batch e amostragem adequada costumam ter impacto baixo. Valide com testes de carga e monitore a latência adicionada.
Sim. Estruture logs hoje, inclua trace_id/span_id e, depois, habilite tracing e métricas. A correlação já trará ganhos rápidos de diagnóstico.
Evite coletar PII. Quando necessário, aplique mascaramento e truncamento no Collector, segregue pipelines por sensibilidade e limite quem pode consultar.
Não necessariamente. Use export síncrono no término da invocação, lotes pequenos e conexões persistentes quando disponíveis. Teste sob picos e simule timeouts do provedor.
Pronto para aplicar no seu ambiente? Coloque uma parte deste guia em prática hoje, registre os aprendizados e compartilhe nos comentários. Explore também outros materiais no appnoodles.com para aprofundar sua jornada de observabilidade.
