Observabilidade de apps LLM em produção com OpenTelemetry

Quando um app com LLM entra em produção, o problema deixa de ser “o modelo respondeu?” e passa a ser “onde a experiência degrada, quanto isso custa e como provar o que aconteceu?”. Em 2026, a resposta mais consistente nas fontes primárias é usar OpenTelemetry como espinha dorsal da observabilidade, aproveitando as semantic conventions gen_ai.* para padronizar traces, métricas e eventos sem prender o time a um vendor.

Isso muda o jogo porque apps LLM raramente falham em um único ponto. A latência pode nascer no retrieval, no prompt assembly, na chamada ao modelo, no parsing de saída ou no uso de ferramentas. Se você só mede a requisição HTTP final, perde a história inteira.

Por que OpenTelemetry virou o eixo da observabilidade GenAI

A documentação oficial do OpenTelemetry já trata sistemas generativos como uma superfície de telemetria própria. O namespace gen_ai.* cobre atributos, spans, eventos e métricas para request, response, uso de tokens e outros sinais relevantes. Na prática, isso cria uma linguagem comum entre app, collector e backend de observabilidade.

O ponto mais valioso aqui é o desacoplamento. Você instrumenta uma vez, exporta em OTLP e decide depois se vai usar Grafana Tempo, Prometheus, Loki ou um vendor compatível. Para times que precisam trocar stack por custo ou compliance, essa separação é ouro.

A convenção oficial também menciona o controle de estabilidade via OTEL_SEMCONV_STABILITY_OPT_IN, o que mostra que a migração para GenAI semântica está sendo tratada de forma séria e gradual.

O cuidado com estabilidade importa porque observabilidade ruim cria o pior tipo de dívida: a equipe passa a desconfiar dos próprios dados. Em apps LLM, isso costuma aparecer como “custou mais do que o esperado”, “respondeu mais lento ontem” ou “o agente começou a errar sem ninguém perceber”.

O que medir além da chamada ao modelo

A tentação inicial é tratar observabilidade de LLM como um problema de API externa. Só que a narrativa dominante em 2026 é outra: observar o fluxo completo. Isso inclui ingestão do input, recuperação de contexto, construção do prompt, chamada ao modelo, tool use, parsing da resposta e qualquer pós-processamento.

Esse desenho ajuda a responder perguntas operacionais que interessam de verdade:

• qual etapa adiciona mais latência;
• quanto de token está sendo gasto por request;
• onde uma ferramenta externa está quebrando o encadeamento;
• qual versão de prompt piorou a qualidade;
• quais casos exigem fallback humano.

Na prática, o melhor sinal costuma ser a combinação de trace para causalidade, métrica para tendência e evento para contexto. Traces mostram o caminho. Métricas mostram a tendência. Eventos guardam detalhes que você não quer perder no ruído agregado.

Para um agente com retrieval, por exemplo, o ideal é separar spans para cada etapa crítica:

undefined

O valor do código não está na sintaxe exata, mas na granularidade. Se o span da chamada ao modelo está rápido e o sistema segue lento, você já sabe que o gargalo está antes ou depois dela.

Como instrumentar sem prender sua aplicação em um fornecedor

Uma boa estratégia em 2026 é começar pelo OTLP e só depois escolher o backend. Isso evita o padrão comum de operação: cada biblioteca cria uma métrica proprietária, cada integração inventa seus próprios atributos e, no fim, ninguém consegue comparar serviços diferentes.

As convenções gen_ai.* ajudam justamente a normalizar nomes e tipos. A vantagem prática é que você consegue correlacionar chamadas de modelo com serviço, versão, ambiente, tipo de operação e consumo de tokens de forma consistente. Também fica mais fácil comparar modelos diferentes em A/B tests ou em rollouts graduais.

Algumas boas práticas valem desde o primeiro dia:

• Propague trace_id e span_id por toda a cadeia;
• capture tokens de entrada e saída como métrica;
• registre latência por etapa, não só no request total;
• adicione atributos de versão do prompt, modelo e ferramenta;
• trate erros de parsing e timeout como sinais observáveis, não como exceção “sem contexto”.

Se você usa auto-instrumentation com bibliotecas comuns do ecossistema LLM, ganhe velocidade sem sacrificar a lógica de negócio. O importante é manter a telemetria consistente entre times de produto, plataforma e SRE. Senão, cada squad cria sua própria versão de “observabilidade” e a comparação vira um caos.

Custos, qualidade e segurança: os três sinais que mais importam

Em produção, observabilidade de LLM não é só sobre disponibilidade. Os três sinais que mais pesam são custo, qualidade e segurança. A ordem pode variar, mas quase todo incidente relevante toca em pelo menos um deles.

Custo aparece rápido quando você mede tokens por rota, por tenant ou por versão de prompt. Qualidade exige capturar contexto suficiente para entender por que uma resposta ficou ruim, incluindo retrieval efetivo e mudança de instruções. Segurança pede atenção a dados sensíveis, principalmente quando prompts carregam informações pessoais, contratos, logs internos ou conteúdo regulado.

No caso de segurança, vale lembrar que prompts e respostas podem conter dados pessoais. No Brasil, isso conversa diretamente com a LGPD, então mascaramento, retenção limitada e controle de acesso à telemetria deixam de ser capricho técnico e viram requisito de governança. Se o seu observability stack copia conteúdo bruto de prompt para dashboards sem revisão, você pode estar ampliando risco regulatório em vez de reduzí-lo.

Também faz sentido separar telemetria estrutural de payload sensível. Em vez de salvar prompt inteiro por padrão, prefira metadados, hashes, amostragens controladas e eventos contextualizados. Quando precisar auditar, tenha um caminho seguro e restrito para reconstituir o caso.

Boas práticas para 2026: da instrumentação ao runtime

OpenTelemetry resolve a base, mas o runtime continua sendo sua responsabilidade. O caminho mais maduro hoje combina observabilidade padronizada com disciplina operacional. O objetivo não é colecionar spans bonitos; é reduzir o tempo entre incidente, diagnóstico e correção.

Algumas práticas já deveriam ser padrão:

1. Versione prompts, ferramentas e modelos como parte do release.
2. Meça por rota e por caso de uso, não só por serviço.
3. Crie alertas para anomalias de token e latência, não apenas para erro 5xx.
4. Faça sampling consciente, porque armazenar tudo pode ficar caro rápido.
5. Correlacione logs com trace para sair do “achei um erro” e chegar no “esse fluxo causou o erro”.

Para apps com agentes, uma dica adicional é observar decisões intermediárias. Se o sistema escolheu uma ferramenta errada, ou se um retrieval trouxe contexto ruim, o problema pode não estar no modelo em si. Sem visibilidade nas etapas auxiliares, a equipe acaba corrigindo o lugar errado.

Uma arquitetura prática costuma ficar assim: aplicação emite spans e métricas OTEL, o Collector recebe e exporta OTLP, e o backend centraliza busca, alertas e correlação. Esse desenho funciona tanto para times pequenos quanto para operações maiores, porque preserva a capacidade de evoluir a stack de observabilidade sem reescrever instrumentação.

Por que isso importa pro dev brasileiro

No Brasil, custo e latência batem mais cedo em muitos produtos digitais. É comum a infraestrutura principal estar em us-east-1 ou em outra região fora do país, o que aumenta sensibilidade a RTT, janelas de erro e tempo de resposta em fluxos síncronos. Quando você adiciona chamadas a LLMs, esse efeito soma ao custo em dólar e pode estourar o orçamento de times que operam com BRL apertado.

Além disso, a LGPD torna especialmente importante saber quais dados estão indo para o modelo, onde esses dados ficam registrados e por quanto tempo. Para muita equipe brasileira, isso não é só uma pauta de segurança; é uma pauta de viabilidade do produto. Se a observabilidade capturar conteúdo sensível sem controle, o risco jurídico cresce junto com a complexidade técnica.

Na prática, isso favorece uma abordagem mais disciplinada: telemetria padronizada, mascaramento de conteúdo, retenção mínima e foco em sinais úteis para negócio. Em um cenário de orçamento enxuto, a observabilidade precisa provar retorno rápido. O que não ajuda a reduzir incidente ou custo só infla a fatura.

Conclusão

Em 2026, a melhor forma de observar apps LLM em produção é tratar OpenTelemetry como base, não como detalhe de implementação. As semantic conventions gen_ai.* dão vocabulario comum para instrumentar o fluxo inteiro, do retrieval ao tool use, e ajudam a responder as três perguntas que mais importam: onde está a latência, quanto está custando e por que a qualidade mudou.

Se você ainda está no estágio de medir apenas a chamada ao modelo, o próximo passo é simples e de alto impacto: escolha uma rota crítica do seu app, adicione tracing por etapa e exporte via OTLP com atributos de versão, tokens e erro. Em menos de 1 hora, você já consegue enxergar o fluxo real do sistema e descobrir onde vale otimizar primeiro. Abra a especificação oficial do OpenTelemetry para GenAI e implemente a primeira instrumentação hoje.