LLMは、テラバイト規模のCIログを数秒で分析するためのSQLクエリを生成します。

MendralのAIエージェントは、独自のSQLクエリを作成し、数億行のログをスキャンし、ジョブメタデータから生ログ出力へのトレースを追跡することで、不安定なテストの原因を3週間前の依存関係の更新に特定しました。調査全体は数秒で完了しました。

毎週、約15億行のCIログと70万件のジョブが彼らのシステムを通過します。すべてのデータはClickHouseに格納され、35:1に圧縮されます。すべてのデータはミリ秒単位でクエリ可能です。

エージェント向けSQLインターフェース

彼らは、調査対象の組織にスコープされたSQLインターフェースをエージェントに提供しています。エージェントは質問に基づいて独自のクエリを構築します。事前定義されたクエリライブラリや厳格なツールAPIはありません。get_failure_rate(workflow, days)のような制約のあるツールAPIでは、エージェントは予想される質問に限定されてしまいます。SQLインターフェースでは、想定されていなかった質問も可能になり、新しい障害のデバッグ時に重要となります。

エージェントは主に2つのターゲットをクエリします：

• ジョブメタデータ：CIジョブ実行ごとに1行を持つマテリアライズドビュー。エージェントは63%の時間で、「この失敗はどのくらいの頻度で起こるか？」「成功率は？」「最も遅いジョブは？」「いつから失敗し始めたか？」などの質問に使用します。
• 生ログ行：ログ行ごとに1行。エージェントは37%の時間で、「このジョブのエラー出力を表示」「このログパターンが最初に現れたのはいつ？」「このエラーメッセージは実行全体でどのくらいの頻度で発生するか？」などの質問に使用します。

クエリパターンとスケール

彼らはオブザーバビリティパイプラインから8,534のエージェントセッションと52,312のクエリを分析しました。エージェントは1つのクエリで止まりません。調査を開始し、広範囲から絞り込みます。

1つの質問に答えるための全クエリでスキャンされた総行数：

• 典型的な質問：約3クエリで33.5万行
• P75：520万行
• P95：9.4億行
• 最も重い生ログセッションは43億行をスキャン

エージェントはセッションごとに平均4.4クエリを実行します。典型的な調査は、ジョブメタデータ（安価なクエリ、中央値4.7万行）に対してコンパクトで事前集計されたマテリアライズドビューを使用して開始します。興味深いものを見つけると、生ログ（高価なクエリ、中央値110万行）に掘り下げます。

データアーキテクチャ

エージェントが高速にクエリするためには、データがそのために構造化されている必要があります。忙しい日には最大3億行のログが流れます。彼らはClickHouseを使用しています。

すべてのログ行には48列のメタデータが含まれています：それが属するCI実行の完全なコンテキスト。コミットSHA、作成者、ブランチ、PRタイトル、ワークフロー名、ジョブ名、ステップ名、ランナー情報、タイムスタンプなど。

ClickHouseのカラムナ形式では、48列をすべてのログ行に非正規化することは実質的にコストがかかりません。commit_messageのような列は、CI実行内のすべてのログ行で同じ値を持ち、1回の実行で数千行のログが生成されることがあります。ClickHouseはそれらの数千の同一値を連続して格納します。圧縮アルゴリズムは繰り返しを認識し、ほとんど無に近く圧縮します。

圧縮率：

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

非正規化がなければ、すべてのクエリで結合が必要になります。これにより、すべてが単純なフィルタになります。