Observabilidade autogerenciada para agentes de IA: um framework de decisão para CTOs

Seus agentes de IA estão afogando você em telemetria. Fluxos de tokens de longa duração, chamadas de ferramentas, retries, prompts, SSE em streaming — tudo soma. Se você continuar canalizando cada span e linha de log para um APM SaaS, vai pagar caro e vazar prompts que você nunca pretendeu armazenar fora do seu VPC. Nesta semana, o Hacker News destacou o Traceway — uma stack de observabilidade autogerenciada, com licença MIT, que você implanta em minutos. Isso não é uma curiosidade. É um sinal. Em 2026, stacks pesados em IA precisam de uma estratégia de observabilidade consciente de custos, consciente de PII e portável.

O que mudou: a telemetria de agentes de IA não é como a de microserviços web

Os fornecedores de observabilidade otimizaram para microserviços: requisições curtas, spans uniformes, logs de baixa entropia. Agentes viram essas premissas de cabeça para baixo.

• Sessões são de longa duração. Um usuário inicia um workflow agente que transmite 30–180 segundos de tokens, faz uma dúzia de chamadas de ferramentas e escreve de volta na UI o tempo todo.
• Payloads são sensíveis. Prompts, anexos e resultados de ferramentas frequentemente carregam PII, PHI, código ou contratos. Se você não consegue provar onde esse dado vive, o jurídico eventualmente vai provar que você está errado.
• O sinal é pesado na cauda. As falhas interessantes são raras: timeouts no percentil 99,5, uma chamada de ferramenta mal especificada em cem. Amostragem baseada na cabeça descarta o que você precisa. Decisões na cauda importam.
• Clientes viram cidadãos de primeira classe. Apps mobile e desktop agora rodam inferência e ferramentas localmente ou na LAN. Você precisa de traces de sessão entre dispositivos, não apenas spans de servidor.

Falando sem rodeios: a observabilidade de agentes se parece mais com analytics e eDiscovery do que com logs de servidor. Trate-a assim.

O modelo de custos que você deveria realmente rodar

Ignore os preços de tabela dos vendors; eles mudam mensalmente e são propositalmente opacos. Modele a sua própria gravidade de dados. Aqui vai uma linha de base defensável para um produto com IA:

• Sessões diárias de agentes: 250.000
• Por sessão: 10 spans de chamadas de ferramenta (~1 KB de metadados cada), 1 span de modelo de longa duração com prompt + resposta (~10–50 KB comprimidos), 200–500 eventos de tokens/telemetria (~5–15 KB comprimidos no total), 5–10 entradas de log (~2–5 KB comprimidos)

Pegada conservadora bruta por sessão: 30–70 KB. Em 250k sessões, isso dá 7.5–17.5 GB/dia antes de enriquecimento. Com atributos adicionais, headers HTTP e baggage de contexto, 2× é comum. Chame isso de 15–35 GB/dia de dados de observabilidade.

Agora, o dinheiro:

• Computação de armazenamento quente (ClickHouse ou Tempo/ClickHouse para traces; Loki para logs; VictoriaMetrics para métricas) em instâncias modestas pode comprimir 8–12× para payloads de trace/log. 20–35 GB/dia brutos normalmente viram 2–4 GB/dia em disco para traces/logs e 0.5–1 GB/dia para métricas após rollups.
• Armazenamento de objetos (S3/GCS) para retenção fria custa ~$0.021–0.026/GB-mês em 2026. 1 TB de traces/logs frios mensais sai por <$30/mês, mais a recuperação quando você precisar investigar.
• Computação: um cluster de 3 nós de ClickHouse em instâncias de uso geral costuma lidar com 10–50k spans/s agregados com latência de consulta subsegundo. Espere $600–$2,000/mês dependendo da região e classe de instância. Loki + VictoriaMetrics adicionam centenas, não milhares.

Compare isso a enviar 15–35 GB/dia para um APM SaaS e manter 7–14 dias quentes. As cobranças de ingest e retenção comumente escalam para a casa de cinco dígitos baixos por mês nesse volume, e você ainda tem externalidades de privacidade. Autogerenciar não é “de graça”, mas o ponto de cruzamento é menor do que a maioria dos times imagina.

Arquitetura: uma stack que não vai brigar com você

Você não precisa de um projeto de ciência. Você precisa de quatro coisas que rodem no seu VPC e falem OpenTelemetry de ponta a ponta.

1) Instrumentação e contratos de dados

• Padronize em OpenTelemetry para traces, logs e métricas. Adote as convenções semânticas emergentes do OpenTelemetry para spans de AI/LLM: nome do modelo, tokens in/out, chamadas de ferramentas, contagem de retries.
• Defina um contrato de dados para prompts e payloads de ferramentas. Por padrão, armazene hashes, não texto bruto. Armazene prompts/respostas completos apenas quando um flag “debug” por sessão estiver ativado. Anexe um atributo pii=true quando qualquer detector disparar.
• Instrumente apps cliente (Android, iOS, desktop) para emitir spans e logs com os mesmos IDs de trace e de usuário/sessão. Em Android, prefira OTLP a gRPC para reduzir head-of-line blocking em redes ruins.

2) Ingest e plano de controle

• OpenTelemetry Collector em todo lugar. Use processors para mascaramento de atributos, amostragem baseada em cauda e roteamento. Tail sampling é o mínimo para agentes; você precisa manter outliers mesmo quando o QPS geral está alto.
• Orçamentos de eventos: imponha máximos de spans/logs por sessão no collector, com limites rígidos e métricas de backpressure. Um agente malcomportado não deve dar DDoS no seu tier de observabilidade.
• Guardrails de PII: use processors para descartar atributos que correspondam a detectores e para bifurcar payloads não mascarados para um bucket S3 selado com TTL de 7 dias, sem acesso por UI, recuperação apenas via IAM para incidentes.

3) Armazenamento e consulta

• Traces: tracing com ClickHouse por trás (por exemplo, via SigNoz, HyperDX ou um roteador leve) ou Grafana Tempo pareado com ClickHouse para índices de busca. ClickHouse dá SQL sobre spans e pode também ser seu warehouse de analytics de prompts.
• Logs: Loki para logs econômicos, com pouco índice; chunks apoiados em storage de objetos mantêm a infra simples. Se você precisar consultar logs estruturados em escala, faça streaming para tabelas no ClickHouse com particionamento por dia e serviço.
• Métricas: VictoriaMetrics por ser um único binário e amigo de alta cardinalidade. Ele comprime séries numéricas agressivamente; espere 2–5× melhor armazenamento vs TSDB do Prometheus bruto. Se você emitir streams de ponto flutuante em alta resolução, considere um compressor lossless feito para telemetria de floats; pesquisas como “fc, a lossless compressor for floating-point streams” mostram ganhos adicionais de 2–4× em alguns sinais.

4) UI e fluxos de trabalho

• Dashboards no Grafana sobre métricas e logs, explorador de traces em cima de ClickHouse/Tempo. Mantenha as UIs simples e focadas nos seus SLOs, não em um catálogo do vendor com 200 widgets.
• Session replay se você precisar: faça self-host de rrweb, vincule replays a IDs de trace. Mantenha replays com TTL curto e nunca armazene PII no DOM sem mascaramento.

Privacidade e conformidade: pare de fingir que prompts são “só logs”

Se seus agentes tocam PII, PHI ou código-fonte, sua camada de observabilidade é um repositório de dados regulado. Aja de acordo.

• Mascarar por padrão. Hasheie prompts e respostas. Mantenha apenas contagens de tokens, durações e metadados do modelo a menos que um flag de debug esteja presente. Para sessões sinalizadas, bifurque payloads completos para um bucket selado com TTL de 7 dias.
• Residência regional. Mantenha dados na região. Se você opera no Brazil e nos US, atenda à LGPD e às leis estaduais de privacidade fixando tiers quentes e frios nas regiões e contas corretas.
• Controle de acesso. Sem logins compartilhados. Use SSO + SCIM + RBAC por projeto. Masque atributos na UI. Todo acesso a dados não mascarados deve deixar um span de auditoria próprio.
• Retenção de dados. 7 dias quentes para traces/logs, 30–90 dias frios em armazenamento de objetos, 15 meses para métricas agregadas. Você consegue justificar isso para o jurídico e ainda conduzir incidentes de forma eficiente.

Performance: orçamentos de latência para a própria observabilidade

Collectors e exporters rodam in-process ou como sidecar; eles não podem comprometer seus p99s.

• Exporters OTLP não bloqueantes com backpressure e filas limitadas. Descarte além dos orçamentos de eventos; nunca deixe travamentos de observabilidade impactarem requisições de usuário.
• Janelas de amostragem baseada em cauda de 1–3 segundos capturam traces lentos de forma determinística sem adicionar latência para o usuário. Isso é crucial para fluxos QUIC/WebRTC e SSE; uma otimização recente de rede no Linux causou um bug em QUIC que teria sido invisível com head sampling.
• Faça sharding por session ID no seu store de tracing para melhorar a localidade de cache e manter consultas rápidas para depuração ao vivo.

Framework de decisão: quando autogerenciar vs. comprar

Use gatilhos, não intuição.

Você deve autogerenciar se qualquer uma destas for verdadeira:

• Volume de telemetria excede ~15 GB/dia em traces/logs/métricas, ou você espera dobrar em dois trimestres.
• Prompts com PII/sensíveis não podem sair do seu VPC ou região, ou o jurídico exige trilhas de auditoria de quem viu prompts brutos.
• Depuração de agentes precisa de correlação em nível de sessão entre mobile/desktop + backend + ferramentas, e você não consegue expressar isso facilmente no seu vendor SaaS.
• Volatilidade de custos do SaaS já forçou você a reduzir retenção ou amostragem a ponto de os engenheiros evitarem a ferramenta.

Fique com SaaS (por enquanto) se todas estas forem verdadeiras:

• Abaixo de 5 GB/dia de telemetria sem payloads sensíveis, e
• Baixa cardinalidade em métricas/logs, e
• Sem capacidade dedicada de SRE/DevEx pelos próximos dois trimestres.

Há um caminho do meio: faça dual-write para o SaaS e para o autogerenciado enquanto você amadurece seus pipelines e, depois, inverta a rota padrão.

Implementação: um plano de execução de 0–90 dias

Dias 0–30: baseline e dual-write

• Adote SDKs do OpenTelemetry no seu API gateway, orquestrador de agentes e nas duas principais ferramentas. Emita spans de modelo com atributos padronizados.
• Implemente uma stack de referência no seu VPC de staging: OpenTelemetry Collector → Loki + VictoriaMetrics + ClickHouse. Ferramentas como o Traceway mostram que dá para subir isso em minutos; endurecer para produção leva mais tempo, mas o básico é rápido.
• Faça exportação dupla para seu SaaS atual e para sua stack autogerenciada. Valide paridade em três sinais dourados e um incidente conhecido.
• Escreva o contrato de dados para mascaramento e bifurcações de debug. Transforme isso em um check de CI: novos spans sem um atributo de classificação reprovam builds.

Dias 31–60: cutover em produção para os caminhos críticos

• Habilite tail sampling por serviço e taxa de erro. Mantenha 100% dos traces para sessões com erros ou p99 > SLO; caso contrário, amostre 1–5%.
• Faça cumprir orçamentos de eventos por sessão no collector. Alerts disparam quando descartes excedem os limiares.
• Guardrails de PII no ar: mascaramento nos SDKs, mascaramento nos collectors, bifurcação para bucket selado com TTL de 7 dias. Spans de auditoria em cada acesso a dados brutos.
• Dashboards e runbooks para seus 3 principais SLOs: latência de prompt, sucesso de chamadas de ferramentas, tempo de sessão end-to-end. Treine com dois incidentes simulados e um game day ao vivo.

Dias 61–90: otimize e reduza riscos

• Ajuste partições de storage e tiers de retenção. Empurre tudo que tiver mais de 7 dias para armazenamento de objetos. Agregue métricas para resolução de 1–5 minutos após 7 dias.
• Guardrails de custo: alerts de orçamento mensal sobre crescimento do storage de objetos e CPU do ClickHouse. Bloqueie merges e compactions de famintos por CPU para não estrangularem consultas.
• Recuperação de desastres: faça snapshot dos catálogos diariamente, teste restore para um VPC de teste. Documente seu RTO/RPO e prove.
• Reduza a ingestão no SaaS para logs/traces em uma janela controlada. Mantenha métricas espelhadas por mais um sprint antes do corte final.

Táticas que se pagam rápido

• Mascarar na origem: não dependa de processors downstream para limpar segredos em prompts. Hash + contagem de tokens resolvem 90% das dúvidas de debug.
• Amostragem no escopo de sessão: mantenha sessões que falham inteiras; traces parciais são desperdício de disco.
• Apenas logs estruturados: JSON com um trace_id e session_id. Logs não estruturados são descartados em 90 dias; logs estruturados alimentam analytics no ClickHouse.
• Comprima as coisas certas: storage de objetos com zstd ou parquet; métricas com delta-of-delta; streams pesados de ponto flutuante se beneficiam de compressão lossless especializada pesquisada para dados científicos.
• Ergonomia de on-call: uma visão única de sessão que liga prompts → chamadas de ferramentas → eventos de UI resolve incidentes mais rápido do que três abas de vendors jamais farão.

Trade-offs e riscos reais

• Você será responsável por SRE. Alguém precisa assumir patching, scaling e backups. CVEs de kernel e dnsmasq continuam aparecendo; empacote seus collectors e stores em imagens padrão com auto-updates em janelas de manutenção.
• Você vai coletar demais sem orçamentos implacáveis. Times de IA gostam de visibilidade. Dê a eles botões de amostragem e custos claros; do contrário, sua stack “barata” fica cara.
• ClickHouse é poderoso e afiado. Schemas ruins e merges vão devorar CPU. Comece com layouts conhecidos para spans e logs; não improvise em prod.

Execução nearshore: como vemos os times fazerem isso acontecer

O trabalho mais pesado não é software; é política e encanamento. Times que têm sucesso normalmente combinam um núcleo pequeno de plataforma com força nearshore. Na prática, um time de plataforma de duas pessoas nos US mais um pod nearshore (Brazil é forte aqui) consegue subir a stack, IaC e contratos de dados em dois sprints com 6–8 horas de sobreposição. Depois disso, é ajuste incremental e uma revisão trimestral de custo/retenção.

Como é o “excelente” até o fim do Q1

• Custos: tier quente em $1–2k/mês, tier frio abaixo de $100/mês por TB. Sem faturas surpresa de SaaS atreladas a picos de tráfego.
• Privacidade: prompts hasheados por padrão, acesso a bucket selado auditado, residência regional aplicada por política.
• Confiabilidade: consultas de trace abaixo de 1 segundo nas últimas 24 horas. Tail sampling mantém todas as sessões lentas/com erro. Game days provam RTO < 2 horas, RPO < 24 horas.
• Velocidade de dev: engenheiros usam uma visão única de sessão para resolver incidentes. Times de produto e dados consultam o ClickHouse sobre performance de modelo sem pedir CSVs para SREs.

Em resumo

Agentes de IA tornam a observabilidade ao mesmo tempo mais valiosa e mais perigosa. Se você está enviando dezenas de gigabytes por dia e parte disso é sensível, o padrão de “mandar para um vendor e torcer” não se sustenta mais. Autogerenciar com OpenTelemetry, ClickHouse/Loki/Tempo e contratos de dados rígidos não é contrarian — é engenharia responsável. Comece o dual-write neste mês. Você vai dormir melhor no próximo trimestre — e seu jurídico também.

Principais pontos

• A telemetria de agentes é pesada na cauda, de longa duração e frequentemente contém PII; trate-a como analytics, não apenas como logs.
• O ponto de cruzamento de custo para autogerenciar chega perto de 15+ GB/dia de traces/logs/métricas ou qualquer restrição de PII.
• Adote OpenTelemetry com tail sampling, orçamentos de eventos e contratos de dados com mascaramento por padrão.
• Use ClickHouse/Tempo para traces, Loki para logs e VictoriaMetrics para métricas; armazene o restante a frio em storage de objetos.
• Execute um plano de 0–90 dias: dual-write, cutover dos caminhos críticos, imponha guardrails, teste DR e depois reduza o SaaS.
• Espere trade-offs: você assume SRE e disciplina de custos; o retorno é menor gasto, menor risco e melhor resposta a incidentes.