Design de Observabilidade para a Era da IA — Aplicação / Infraestrutura / CI / LLM, Cada Um em Sua Própria Forma (Parte 1)

Divulgação de assistência de IA: Este artigo foi elaborado com a ajuda de Claude. Todo o conteúdo técnico, decisões de design, referências de código e capturas de tela refletem sistemas de produção que projetei e opero na airCloset; a prosa foi revisada por mim antes da publicação.

Oi, eu sou Ryan, CTO da airCloset.

Na série anterior, análise profunda do gráfico de código (Parte 2), escrevi sobre como tornar um código-base de 46 repositórios semanticamente pesquisável para IA. A questão final que deixei em aberto naquele artigo foi a ausência de análise dinâmica:

O que vive no gráfico é o fato de que "esta aresta existe estaticamente." Com que frequência essa aresta é realmente usada em produção não é registrado.

Um gráfico que te dá fatos estáticos é uma coisa. Dizer à IA o que está realmente acontecendo na produção agora é um problema separado. Portanto, a mesma disciplina de modelagem que apliquei ao gráfico estático precisa se aplicar à pilha de observabilidade também.

Este post é a primeira metade dessa história. Eu dividi em duas: Parte 1 (este post) cobre como eu modelagem quatro superfícies de monitoramento diferentes (aplicação / infraestrutura / CI / LLM). A Parte 2 cobre o tratamento de PII, a superfície de integração e Auto-Cura — que virá uma semana depois.

O Que Significa "Observável para IA"?

A maior lição da série do gráfico de código foi: os dados precisam ser modelados antes que a IA possa consumi-los. Jogar 46 repositórios de código em um modelo ultrapassa a janela de contexto e convida à alucinação. Então nós modelamos — análise estática em um gráfico, nós de limite com significado, junções SAME_ENTITY entre gráficos — e só então entregamos.

A pilha de observabilidade tem o mesmo problema exato. Jogar logs de produção brutos na IA e você obtém:

• Um volume de logs que afoga a janela de contexto
• Sem maneira para o modelo distinguir erros de ruído
• Métricas, logs e rastros que não se conectam entre si
• Perguntas como "quanto estamos gastando agora" que logs brutos não respondem de forma alguma

Em outras palavras, os logs precisam ser remodelados antes que a IA possa usá-los. Mesmo problema, domínio diferente.

A pegadinha é que a forma certa depende de o que você quer que a IA responda. Na cortex (a plataforma interna de IA), eu dividi a superfície de monitoramento em quatro eixos e deixei cada um se estabelecer em sua própria forma:

Nota: "cortex" aqui se refere ao codinome da plataforma interna de IA da airCloset. Não relacionado ao Snowflake Cortex, Palo Alto Networks Cortex, etc.

"Apenas empurre tudo através do OTel e despeje tudo no Loki" é uma opção. Mas no momento em que você faz isso, você está pedindo a um backend para responder a tipos de perguntas extremamente diferentes — em tempo real "qual é o gasto agora" ao lado de "custo mensal detalhado por equipe via SQL" — e um deles vai sofrer. Dividir por propósito é a escolha que eu fiz.

Deixe-me passar por cada um dos quatro eixos. Aplicação e infraestrutura são a base, então vou mantê-los breves. CI e LLM são onde os julgamentos de design da era da IA realmente surgem, então vou me aprofundar neles.

Aplicação — OTel + Loki + Tempo, a Pilha Padrão

A fundação é sem novidades. Cada aplicação cortex é instrumentada com OpenTelemetry, com rastros indo para Tempo, logs para Loki e métricas para Mimir — a configuração padrão do Grafana Cloud.

Não há truque especial aqui. O que importa é a disciplina: cada app emite logs e rastros na mesma forma. Essa uniformidade é o que permite que a IA execute algo como {service_name="<service>"} |~ "error" através do MCP e investigue entre serviços.

Eu cobri a instrumentação real em Série AI Harness Parte 4 (Auto-Cura), então vou deixar os detalhes lá. O ponto que vale a pena repetir é: uma pilha OTel padrão, devidamente estabelecida, é a condição prévia para tudo que é impulsionado por IA que vem depois.

Infraestrutura — Cloud Run / BigQuery / Métricas do Pub/Sub, Tudo Para o Mimir

cortex roda no GCP e conecta Cloud Run, Cloud Run Jobs, BigQuery, Pub/Sub, Cloud Tasks e os suspeitos habituais. As métricas de cada recurso do GCP (CPU, memória, contagem de execuções, latência, tempo de permanência na fila, etc.) fluem através do Cloud Monitoring para o Mimir.

Nada especial aqui também — apenas métricas padrão do GCP, todas reunidas em uma única instância do Mimir. Mas essa propriedade de "um lugar" compensa mais tarde: a IA pode responder "qual serviço usou mais CPU na semana passada?" ou "existe um trabalhador com uma fila entupida?" naturalmente, porque tudo é consultável a partir de um único armazenamento. O MCP pega a partir daí.

É isso para a fundação. Pilhas de observabilidade padrão estão bem documentadas em outros lugares; vá ler a documentação do Grafana e do OpenTelemetry se você quiser os detalhes.

Os julgamentos de design interessantes da era da IA estão nos próximos dois eixos — CI e LLM.

CI — Enviar Logs para Loki via Pull Pós-Hoc, Não Push via Webhook

cortex executa CI no GitHub Actions, e eu envio todos os logs de CI para o Grafana Loki.

"Por quê? O GitHub Actions tem uma interface de usuário perfeitamente boa para isso" é uma pergunta razoável. As razões são concretas:

• Fazer a IA acessar a API do GitHub Actions em cada investigação é lento e pesado em autenticação. Ingerir para o Loki uma vez significa que a IA pode consultá-lo ad-hoc
• Uma instância do Loki mantém logs de CI e logs de aplicação juntos, então você pode consultá-los em conjunto
• Alertas LogQL transformam falhas de CI em um sinal estruturado
• A IA pode perguntar "quais testes falharam desde a semana passada?" em linguagem natural

Mas o mecanismo de envio é incomum. A escolha que a cortex fez:

Não envie logs de dentro da execução do CI. Após a execução terminar, puxe-os da API do GitHub.