TL;DR — A semana foi de observabilidade com calculadora na mão. Na ObservabilityCON 2026, o Grafana Labs apostou em amostragem adaptativa, arquivo de logs no seu próprio object storage e agentes que vigiam baselines. No blog da CNCF, um tutorial cortou pela metade logs e traces de um agente de IA e levou métricas de 300 para 12 séries só com o OpenTelemetry Collector. O recado: telemetria que nenhum dashboard lê é storage pago — e, às vezes, dado pessoal exposto.
A semana passada foi sobre conformidade virando artefato. Esta foi sobre uma conta que cresce em silêncio em quase toda empresa que opera em cloud: a fatura de observabilidade.
O gatilho foi a ObservabilityCON 2026, em São Francisco, mas o que tornou a semana interessante foi a convergência. Fornecedor, comunidade e praticantes chegaram, por caminhos diferentes, à mesma conclusão: o modelo "coletar tudo e decidir depois" não fecha mais — e os agentes de IA, que geram telemetria em volume de torneira aberta, aceleraram o problema.
Por que a conta de observabilidade cresce mais rápido que o sistema?
Porque o custo escala com o volume ingerido, não com o valor que se tira dele. E volume é justamente o que agentes produzem.
O Grafana Labs abriu o evento com esse diagnóstico e com um pacote de "economia de dados" no Grafana Cloud. A tese: em vez de fazer "dieta de dados" no chute (cortar retenção, tirar ambientes da coleta, amostrar a 10% e rezar), decidir o que merece ficar. Segundo a empresa, clientes que usam a Adaptive Telemetry reduziram o gasto com telemetria entre 30% e 50% em média — número do fornecedor, então trate como teto de expectativa, não como meta.
| Sinal | O que foi anunciado | Status |
|---|---|---|
| Traces | Amostragem volumétrica (orçamento distribuído entre serviços e tipos de requisição) e por diversidade (ao menos um trace por combinação de serviço, rota e status a cada 15 min) | GA |
| Traces | Traces descartados continuam consultáveis por ID por 24 horas | GA |
| Logs | Archive: em vez de descartar, rotear logs de baixo valor para o seu próprio object storage; replay sob demanda | Archive em public preview; replay em private preview |
| Logs | Regras de descarte aplicadas direto nos coletores, antes de sair do ambiente (economia de egress) | Public preview |
| Métricas | Auto-apply de recomendações de agregação, com modo cost-first que nunca aumenta o total de séries | GA |
Duas ideias aqui valem para qualquer stack, não só para quem é cliente do Grafana Cloud. A primeira é cortar na borda: filtrar no coletor, antes do egress, é economia dupla — rede e ingestão. A segunda é arquivar em vez de apagar: object storage barato com caminho de volta tira o medo que trava a decisão de descartar.
A outra frente do evento foi velocidade de consulta. A busca full-text do Grafana Cloud Logs, baseada na tecnologia da Logline (adquirida em abril), chegou a GA; um cliente relatou ter saído de quase 1 TB de logs varridos em três minutos para cerca de 100 GB em menos de três segundos.
Quanto da telemetria de um agente de IA é realmente necessária?
Bem menos da metade. Um tutorial publicado no blog da CNCF fez o experimento que muito time de plataforma deveria fazer antes de ligar a telemetria de agentes de codificação para a empresa inteira.
Uma tarefa pequena (corrigir dois testes e adicionar casos de borda) gerou 181 registros e 289 KB de JSON numa única execução. O volume mora em lugares previsíveis: o conteúdo devolvido pelas ferramentas vai como evento do span — um arquivo de 40 KB lido pelo agente vira um evento de 40 KB — e aparece de novo nos logs, como parâmetro da ferramenta. Nas métricas, o problema é cardinalidade: cada datapoint carrega session.id, user.id e user.email, então cada sessão nova cria séries que nunca somem. Vinte e cinco sessões geraram 300 séries para oito métricas.
O autor partiu de seis perguntas que alguém realmente faz (custo por modelo, tokens e cache, falhas de ferramenta, edits rejeitados, latência, erros) e moldou tudo no OpenTelemetry Collector, com um pipeline bruto e outro otimizado lado a lado para comparar com honestidade. Resultado: logs e traces pela metade e métricas de 300 para 12 séries, sem amostragem.
A frase que resume a semana veio desse texto, em paráfrase: se nenhum dashboard, alerta ou query lê um campo, aquilo não é observabilidade — é storage que você paga para indexar.
O que isso muda para quem opera no Brasil?
Três coisas, e a terceira costuma passar despercebida.
Câmbio. Observabilidade SaaS é cobrada em dólar por GB ingerido ou série ativa. Cada campo inútil é custo indexado à moeda — e é dos poucos itens da fatura cloud que se reduz só com configuração, sem renegociar contrato.
Self-hosted não escapa. Quem roda a própria stack troca a fatura por disco, memória e tempo de consulta. A disciplina é a mesma: tail sampling e filtragem no Collector, retenção curta para o que é quente, object storage para o resto. Nosso guia de observabilidade self-hosted com a stack LGTM no Kubernetes mostra onde cada sinal fica e como dimensionar.
LGPD. O detalhe do user.email nas métricas e do conteúdo de arquivos nos eventos de ferramenta não é só custo. É dado pessoal — e potencialmente código e segredos — indo para um backend com retenção longa e acesso amplo. Redigir no Collector, antes de sair do ambiente, é a medida mais barata de privacidade que existe. Se você está levando agentes para produção, isso entra na mesma conversa de governança que tratamos em como avaliar, medir custo e governar agentes.
Contexto ou ferramenta nova: o que acelera mais o diagnóstico?
Contexto. Outro texto da CNCF testou o mesmo agente, com o mesmo modelo, em 50 falhas do benchmark open source SREGym, num cluster EKS real: uma vez só com shell e kubectl, outra com ferramentas MCP somente leitura que entregam falhas atuais, timeline de mudanças, relacionamentos entre recursos e logs filtrados para erros.
A precisão quase não mudou (46 contra 45 acertos). O tempo, sim: diagnóstico correto em até 2 minutos em 86% das falhas com contexto, contra 60% só com shell; tempo médio para responder de 64 s contra 191 s; e o percentil 90 caiu de 632 s para 94 s. Um detalhe técnico do texto merece nota: eventos do Kubernetes expiram em uma hora por padrão (--event-ttl), então "o que mudou antes de quebrar" muitas vezes simplesmente não existe mais quando alguém vai olhar.
Os autores mantêm a ferramenta testada, e eles mesmos pedem para ler o resultado com esse viés. Mas a lição é a mesma do resto da semana: o gargalo não é o agente nem a ferramenta, é o sinal certo chegando na hora certa. O Grafana foi na mesma direção ao colocar seu Knowledge Graph como contexto de execução para agentes e lançar Assistant Watchers (GA), agentes sempre ativos que vigiam desvios de baseline.
Outros destaques da semana
- Duas CVEs críticas no core do PHP. CVE-2026-109618 e CVE-2026-109619, com CVSS 9.2, afetam da 5.4 à 8.5.11 e permitem execução remota de código e vazamento de memória sem autenticação. Correção: 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, mais rebuild das imagens de container. Contamos como fizemos essa remediação em escala em PHP2Shell: duas CVEs críticas corrigidas em mais de 70 ambientes em menos de 24h.
- llm-d 1.0. O stack open source de inferência distribuída nativo do Kubernetes chegou à versão estável, com roteamento ciente de cache, offloading hierárquico de KV cache e controle de fluxo por prioridade. Na mesma semana, a CNCF discutiu como GPUs estão forçando o autoscaler a considerar tipo e topologia de acelerador, não só quantidade de nós.
- Amazon ECS Gateway. Ingress gerenciado para serviços ECS, separando responsabilidades entre plataforma e aplicação e compartilhando até 25 serviços por ALB — menos ALB por serviço é menos custo fixo.
- RHEL direto no OCI. A Oracle passou a oferecer imagens oficiais do Red Hat Enterprise Linux pagas com créditos da própria OCI, além do BYOS. Simplifica licenciamento para quem já roda RHEL em regiões como São Paulo.
- Logs dentro de UDFs Python no BigQuery. Funções Python agora mandam logs estruturados para o Cloud Logging, o que facilita isolar registros inválidos num pipeline sem pará-lo — observabilidade chegando também ao dado.
Perguntas Frequentes
Amostrar traces não significa perder justamente o trace do incidente?
Com amostragem probabilística fixa, sim, esse risco é real: um health check e um checkout lento valem o mesmo. As abordagens apresentadas na semana atacam isso de outro jeito — distribuir o orçamento de amostragem entre serviços e tipos de requisição, garantir ao menos um trace de cada combinação de serviço, rota e status, e manter os traces descartados consultáveis por ID por um período curto. O princípio vale também em stack self-hosted com tail sampling no OpenTelemetry Collector.
Preciso do Grafana Cloud para aplicar essas ideias de redução de telemetria?
Não. Os recursos 'adaptive' são do Grafana Cloud, mas o tutorial da CNCF usa só o OpenTelemetry Collector (filtros, transformações e consolidação de atributos) antes de qualquer backend. Em stack self-hosted LGTM, o mesmo vale: descartar ou rotear para object storage o que ninguém consulta, tirar identificadores de alta cardinalidade das métricas e fazer tail sampling no Collector.
A telemetria de agentes de codificação pode ser um problema de LGPD?
Pode. Na instrumentação padrão descrita pela CNCF, métricas carregam identificadores como user.email, e eventos de ferramenta podem levar o conteúdo inteiro de arquivos lidos ou escritos pelo agente. Se isso vai para um backend de observabilidade com retenção longa e acesso amplo, você está guardando dado pessoal e possivelmente código ou segredos fora do controle previsto. Filtrar e redigir no Collector, antes de sair do ambiente, é a medida mais barata.
Vale contratar um produto de AI SRE agora?
Antes, meça o agente que você já tem com contexto adequado. No benchmark publicado na CNCF (50 falhas do SREGym num cluster EKS), o mesmo agente com ferramentas MCP somente leitura — falhas atuais, timeline de mudanças, relacionamentos e logs filtrados — chegou ao diagnóstico correto em até 2 minutos em 86% dos casos, contra 60% só com shell e kubectl. Os autores mantêm a ferramenta testada, então leia com esse viés, mas o ponto metodológico é reproduzível.
Quem roda PHP precisa agir sobre as CVEs divulgadas esta semana?
Sim, com prioridade. As CVE-2026-109618 e CVE-2026-109619 têm CVSS 9.2 e afetam o core do PHP da 5.4 até a 8.5.11. A correção é atualizar para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 e reconstruir imagens de container que embutem o runtime. Plataformas gerenciadas com auto-update tendem a ser corrigidas pelo provedor; ambientes próprios exigem ação manual.