Les LLM génèrent des requêtes SQL pour analyser des téraoctets de logs d'intégration continue en quelques secondes.

L'agent IA de Mendral a retracé un test instable jusqu'à une mise à jour de dépendance trois semaines plus tôt en écrivant ses propres requêtes SQL, parcourant des centaines de millions de lignes de logs à travers une douzaine de requêtes, et en suivant une piste des métadonnées des jobs jusqu'aux logs bruts. L'ensemble de l'enquête a pris quelques secondes.

Chaque semaine, environ 1,5 milliard de lignes de logs CI et 700 000 jobs transitent par leur système. Tout cela atterrit dans ClickHouse, compressé à 35:1. Tout cela est interrogeable en millisecondes.

Interface SQL pour l'agent

Ils exposent une interface SQL à l'agent, limitée à l'organisation qu'il examine. L'agent construit ses propres requêtes en fonction de la question. Pas de bibliothèque de requêtes prédéfinie, pas d'API d'outil rigide. Une API d'outil contrainte comme get_failure_rate(workflow, days) limiterait l'agent aux questions anticipées. Une interface SQL lui permet de poser des questions jamais imaginées, ce qui compte lors du débogage de pannes inédites.

L'agent interroge deux cibles principales :

• Métadonnées des jobs : une vue matérialisée avec une ligne par exécution de job CI. L'agent l'utilise 63 % du temps pour des questions comme « à quelle fréquence cela échoue-t-il ? », « quel est le taux de réussite ? », « quels jobs sont les plus lents ? », « quand cela a-t-il commencé à échouer ? »
• Lignes de logs brutes : une ligne par ligne de log. L'agent l'utilise 37 % du temps pour des questions comme « montre-moi la sortie d'erreur pour ce job », « quand ce motif de log est-il apparu pour la première fois ? », « à quelle fréquence ce message d'erreur se produit-il à travers les exécutions ? »

Modèles de requêtes et échelle

Ils ont analysé 8 534 sessions d'agent et 52 312 requêtes de leur pipeline d'observabilité. L'agent ne s'arrête pas à une requête. Il enquête – commence large, puis creuse.

Nombre total de lignes parcourues à travers toutes les requêtes pour répondre à une question :

• Question typique : 335 000 lignes sur environ 3 requêtes
• P75 : 5,2 millions de lignes
• P95 : 940 millions de lignes
• Les sessions les plus lourdes sur les logs bruts parcourent 4,3 milliards de lignes

L'agent effectue en moyenne 4,4 requêtes par session. Une enquête typique commence par les métadonnées des jobs (requêtes peu coûteuses, médiane de 47 000 lignes) contre une vue matérialisée compacte et pré-agrégée. Quand il trouve quelque chose d'intéressant, il creuse dans les logs bruts (requêtes coûteuses, médiane de 1,1 million de lignes).

Architecture des données

Pour que l'agent interroge aussi vite, les données doivent être structurées pour lui. Jusqu'à 300 millions de lignes de logs transitent par jour lors des périodes chargées. Ils utilisent ClickHouse.

Chaque ligne de log porte 48 colonnes de métadonnées : le contexte complet de l'exécution CI à laquelle elle appartient. SHA du commit, auteur, branche, titre de la PR, nom du workflow, nom du job, nom de l'étape, informations du runner, horodatages, et plus encore.

Dans le format columnar de ClickHouse, dénormaliser 48 colonnes sur chaque ligne de log est essentiellement gratuit. Une colonne comme commit_message a la même valeur pour chaque ligne de log dans une exécution CI, et une seule exécution peut produire des milliers de lignes de log. ClickHouse stocke ces milliers de valeurs identiques en séquence. L'algorithme de compression voit la répétition et la compresse à presque rien.

Taux de compression :

• commit_message : 301:1
• display_title : 160:1
• workflow_path : 79:1
• step_name : 52:1
• job_name : 48:1

Sans dénormalisation, chaque requête nécessiterait une jointure. Avec elle, ce sont tous des filtres simples.