A observabilidade já não é responsabilidade exclusiva das equipes de confiabilidade de sites; os desenvolvedores são cada vez mais chamados a adicionar traces, logs e métricas ao código que escrevem, para que possam diagnosticar falhas e compreender o comportamento das aplicações antes e depois de chegarem à produção. Em uma publicação no blog da CNCF em 25 de agosto de 2026, Adriana Villela, gerente da comunidade OpenTelemetry e embaixadora da CNCF, e Diana Todea, responsável pela documentação do OpenTelemetry e embaixadora da CNCF, apresentam um caminho prático para reduzir o peso dessa tarefa usando OpenTelemetry.
As autoras partem de uma objeção comum entre desenvolvedores: adicionar Instrumentation significa manter mais código, aumentar a complexidade e correr o risco de introduzir erros ou dívida técnica. No entanto, elas relacionam esse custo a ganhos práticos diretos, principalmente a redução do tempo de depuração, a aceleração da conclusão e da implantação de recursos e a identificação de caminhos lentos, novas tentativas não aparentes e casos extremos, além de uma melhor compreensão dos sistemas distribuídos. As autoras também consideram que a observabilidade ajuda a decompor aplicações produzidas com o auxílio de ferramentas de inteligência artificial quando sua qualidade é variável.
Comece pela automação e depois adicione o que faltar
A primeira recomendação é usar Zero-code instrumentation sempre que disponível. Esse mecanismo adiciona Instrumentation à aplicação sem modificar o código-fonte, interceptando chamadas de frameworks e bibliotecas comuns em tempo de execução ou durante a compilação. De acordo com o artigo, esse tipo de suporte está disponível para as linguagens Java, .NET, Python, JavaScript, PHP e Go.
As autoras não consideram a automação uma solução completa; ela necessariamente não sabe o que é importante na própria lógica da aplicação. Por isso, deve ser complementada com Manual instrumentation para adicionar traces, metrics, logs, propagação de contexto e atributos específicos do código. Elas também propõem a prática de Observability-driven development, isto é, adicionar observabilidade durante a escrita de código novo, em vez de voltar a ele dias depois, quando os detalhes do projeto estão menos presentes na mente do desenvolvedor.
O que merece ser medido?
- Unidades importantes de trabalho: adicione spans para solicitações recebidas, como chamadas HTTP, conexões de saída com bancos de dados, caches, APIs e Queues, além de operações sensíveis para o negócio. O artigo alerta contra a criação de um span para cada pequena chamada, pois isso pode gerar ruído que oculta os sinais importantes.
- Eventos relevantes: use logs para explicar por que algo aconteceu, concentrando-se em erros, falhas de validação, caminhos de novas tentativas e alternativas, além de eventos de segurança, como falhas de autenticação e recusas de autorização.
- Tempo de resposta: as métricas de latência ajudam a identificar por que uma determinada solicitação demorou mais do que o normal, especialmente em fluxos com várias etapas, como adicionar um item ao carrinho e depois concluir a compra.
- Frameworks e bibliotecas internas: a Instrumentation dos frameworks e bibliotecas desenvolvidos pela própria equipe pode oferecer ampla cobertura, pois grandes partes da aplicação passam por eles.
Use a inteligência artificial como assistente, não como substituta da revisão
As autoras consideram que as ferramentas de programação baseadas em inteligência artificial podem reduzir o tempo de exploração das interfaces do OpenTelemetry e dos diferentes SDKs, além de ajudar a lidar com código legado. No entanto, seu uso exige orientação precisa. Elas sugerem definir o papel do assistente, o objetivo, a localização do código e a linguagem utilizada, bem como as saídas desejadas, anexando links da documentação ou exemplos de código relevantes.
Elas também recomendam pedir ao agente que explique suas decisões e, quando possível, usar outro agente como avaliador para questioná-las; em seguida, deve-se repetir a tentativa e melhorar os resultados, em vez de aceitar a primeira alteração sugerida pela ferramenta. Essas recomendações refletem a opinião e a experiência das autoras e não são uma garantia de que o código produzido pela inteligência artificial será correto ou adequado à aplicação.
Um caminho local para compreender os dados de telemetria
A Instrumentation não se completa sem um meio de ler os dados gerados. O artigo explica que o OpenTelemetry Collector funciona como um agente neutro em relação a fornecedores: recebe traces, logs e métricas de várias fontes, processa-os quando necessário e depois os envia para um ou mais destinos. Ele é composto por Receivers, que recebem os dados; Processors, que modificam, ocultam ou amostram atributos; Exporters, que os enviam; e Pipelines, que definem o caminho de cada tipo de sinal, além de Connectors, que conectam dois pipelines.
Para fins de desenvolvimento, o artigo propõe uma configuração simples que recebe dados por OTLP usando gRPC ou HTTP e os exporta para um módulo Debug, com o uso do SpanMetrics Connector para converter a duração do span em dados de métricas que ajudam a monitorar problemas de latência. Em seguida, apresenta três ferramentas de código aberto que podem ser executadas com o Collector e o Docker Compose: OTel Desktop Viewer, para visualizar traces; otel-tui, para visualizar traces, logs e métricas e as relações entre serviços por meio de uma interface de terminal; e OTel Front, para exibir os mesmos três tipos com um painel.
Limitações que devem ser consideradas
A experiência mostra que essas ferramentas não estão livres de obstáculos. Configurá-las foi mais fácil para as autoras graças à experiência anterior com o OpenTelemetry Collector e o Docker, enquanto iniciantes podem enfrentar dificuldades maiores. Além disso, as ferramentas dependem de projetos de código aberto de terceiros e podem nem sempre acompanhar as versões mais recentes da API e do SDK do OpenTelemetry ou oferecer paridade completa de recursos.
O artigo destaca desafios mais amplos no ecossistema, incluindo a atividade desigual dos grupos de interesse específicos de cada linguagem, a ausência de automação para algumas linguagens, como Rust e Elixir, e o grande número de opções entre SDKs, eBPF e Instrumentation em tempo de compilação, além de problemas de estabilidade das interfaces de programação, atualização de dependências e alta Cardinality em alguns atributos.
Leitura editorial: o valor prático aqui não está em adicionar uma nova ferramenta, mas em transformar a observabilidade de uma tarefa adiada em parte do ciclo de desenvolvimento do código. O guia define um ponto de partida de baixo atrito e, em seguida, estabelece limites claros para o que a automação não consegue conhecer. No entanto, a fonte não apresenta uma comparação quantitativa de desempenho entre as ferramentas nem comprova que um único caminho seja adequado a todas as linguagens ou ambientes; por isso, as recomendações devem ser tratadas como uma estrutura inicial, com testes das configurações e revisão do volume e do custo dos dados e de sua adequação à aplicação real.