A IA mudou a forma como construímos software, mas não mudou uma verdade básica sobre as máquinas. Elas se afogam no ruído, assim como nós. Quando engenheiros experimentam pela primeira vez o debugging assistido por IA, o instinto é simples: alimentar o modelo com tudo. Logs brutos, traces e métricas são todos despejados na janela de contexto. O resultado não é insight, mas falha. O volume é muito alto. O sinal colapsa. As métricas ficam em uma ferramenta, os traces em outra, e o modelo não consegue conectá-los em uma história coerente. Antes que a IA possa ajudá-lo a observar seus sistemas, você precisa observá-los por conta própria. Você deve moldar os dados primeiro.

Por que Logs Brutos Quebram Pipelines de IA

Sistemas modernos geram telemetria em uma taxa que nenhum humano consegue ler. Isso deveria torná-los perfeitos para a inteligência artificial. Não torna. A janela de contexto de um grande modelo de linguagem, embora esteja crescendo, ainda é um cano finito. Se você a encher com logs de produção não filtrados, desperdiçará tokens com heartbeats de cron jobs e ruído de health-checks, enquanto enterra a interrupção real. Pior ainda, logs brutos carecem de relacionamentos. Um pico de latência às 14:00 e um erro de conexão de banco de dados em um log no mesmo timestamp estão claramente relacionados, mas a menos que alguém tenha estruturado esse relacionamento previamente, a IA terá que adivinhar. Adivinhar é caro, lento e, muitas vezes, errado.

A solução é arquitetural, não algorítmica. Você precisa decidir o que será coletado, como será moldado e qual backend responde a qual pergunta antes mesmo de enviar um prompt para o modelo.

Quatro Eixos de Monitoramento

Na airCloset, a equipe de engenharia parou de tratar a observabilidade como um único fluxo massivo (firehose). Eles dividiram o monitoramento em quatro eixos distintos. Cada um possui um formato específico e responde a uma pergunta específica.

  • Application: Logs e traces respondem "O que está acontecendo agora?"
  • Infrastructure: Métricas respondem "Temos recursos suficientes?"
  • CI: Logs e alertas respondem "O que quebrou e quando?"
  • LLM: Métricas e registros estruturados respondem "Quanto estamos gastando?"

Essa separação é importante porque o formato ideal para um gráfico de latência em tempo real é inútil para uma análise de custo post-hoc. Forçar um único esquema em todos os quatro domínios cria exatamente o tipo de ruído que torna a assistência de IA inútil.

Observabilidade de CI: Pull, Não Push

A integração contínua é onde o código encontra a realidade. Quando um build falha, os desenvolvedores precisam da história rapidamente. A abordagem ingênua é fazer com que o runner de CI envie (push) os logs diretamente para o seu backend de observabilidade enquanto ele executa. Parece eficiente. Na verdade, é perigoso.

Na airCloset, eles inverteram o modelo. O runner de CI não toca na stack de observabilidade. Após o término do workflow do GitHub Actions, eles puxam (pull) os logs da API do GitHub e os ingerem no Loki.

Essa arquitetura de pull entrega três vitórias concretas.

Desacoplamento. Se o pipeline de ingestão falhar ou o Grafana estiver inacessível, a execução do teste em si não é afetada. O build passa ou falha por seus próprios méritos. Enviar uma falha de observabilidade nunca deve matar um deployment.

Segurança. O workflow de CI nunca precisa de uma chave de API do Grafana. O código de teste é notório por tocar em segredos que não deveria, e remover essa exposição reduz o raio de alcance (blast radius) caso uma dependência seja comprometida.

Consultas cruzadas. Assim que o CI