PromCopilot: Simplifying Prometheus Metric Querying in Cloud Native Online Service Systems via Large Language Models

この論文は、大規模言語モデルと知識グラフを連携させることで、クラウドネイティブ環境におけるPrometheusのメトリクスを自然言語からPromQLに変換するフレームワーク「PromCopilot」を提案し、初のテキスト対PromQLベンチマークを用いてその有効性を検証した研究です。

要約

この論文は、**「PromCopilot（プロムコパイロット）」**という新しいツールの紹介です。

一言で言うと、**「エンジニアが複雑なシステムの状態を、難しい専門用語（PromQL）を使わずに、普通の日本語（自然言語）で質問するだけで、自動的に正しいデータ検索コマンドを作ってくれる助手」**のようなものです。

これを、日常の生活に例えてわかりやすく解説します。

1. 背景：巨大な都市の「交通渋滞」と「案内所」

現代のオンラインサービス（Amazon や淘宝網のような巨大なネットショップなど）は、**「巨大で複雑な都市」**に例えられます。

• 都市の構成： 何千もの建物（サーバー）、何百万もの住民（データ）、そして複雑な道路網（通信経路）があります。
• 監視システム（Prometheus）： この都市の交通状況や建物の状態を 24 時間 365 日監視する「巨大な交通管制センター」です。

エンジニアは、この都市で何か問題が起きた時（例えば「なぜ注文サービスが遅いのか？」）を調べる必要があります。

2. 問題点：難解な「暗号」を解く必要がある

通常、この交通管制センターに問い合わせるには、**「PromQL」という非常に難解な「暗号（専門言語）」**を使わなければなりません。

• 従来の方法：
  • エンジニアは、「注文サービスが動いているサーバーの中で、メモリが最も空いているのはどれか？」という質問を、以下のような暗号に変換して入力する必要があります。
  • topk(1, node_memory_MemAvailable_bytes{service="order", instance=~".*"})
  • 大変な点：
    1. 暗号のルールを覚える必要がある： 文法が複雑で、間違えるとエラーになります。
    2. 都市の地図を全部覚えている必要がある： 「注文サービス」がどの建物（サーバー）に配置されているか、その建物の名前（ID）は何か、などをすべて頭の中で把握していないと、正しい暗号が作れません。
    3. 時間がかかる： 地図（システム情報）を探し回りながら暗号を作るのは、とても時間がかかります。

3. 解決策：PromCopilot（賢い通訳と案内係）

そこで登場するのが、この論文で提案された**「PromCopilot」です。これは、「LLM（大規模言語モデル）」と「知識グラフ（都市の完全な地図）」を組み合わせた「超優秀な通訳兼案内係」**です。

仕組みのイメージ：

1. 普通の言葉で質問する：
   エンジニアは、暗号を使わずに、ただ「注文サービスが入っているサーバーで、メモリが最も空いているのはどれ？」と普通の言葉で聞きます。

2. 「知識グラフ」で地図を探す：
   PromCopilot は、まず**「知識グラフ」という「都市の完全なデジタル地図」**を参照します。

   • 「注文サービス」がどの「Pod（小さな部屋）」に入っているか。
   • その「Pod」がどの「Node（大きなビル）」にあるか。
   • 「メモリ」に関するデータはどの「メトリック（センサー）」で測られているか。
     これらを自動的に探します。

3. LLM が「暗号」を生成する：
   見つかった地図情報（コンテキスト）を、**「LLM（天才的な通訳）」**に渡します。LLM は「あ、この質問なら、この暗号（PromQL）を使えばいいんだな」と理解し、正しい暗号を自動生成します。

4. 結果の提示：
   エンジニアには、完成した「暗号（PromQL）」が表示され、すぐにデータが取得できます。

4. 実験結果：どれくらい効果的？

研究者たちは、このツールが本当に使えるかテストしました。

• テスト： 280 種類の質問を用意し、PromCopilot に答えさせました。
• 結果：
  • 従来の方法（暗号を自分で書く、または過去の例を参考にするだけ）では、正解率は 30〜40% 程度でした。
  • PromCopilot は、約 69% の確率で完璧な答えを出しました。
  • さらに、エンジニアが実際に使ってみたところ、作業時間が「約 6 分」から「約 1 分 40 秒」に短縮されました。

5. まとめ：なぜこれがすごいのか？

この論文の核心は、**「AI 単体では、その会社固有の『地図（システム情報）』を知らないため、間違った答えを出してしまう」という問題を見抜き、「AI に『地図（知識グラフ）』を持たせて、一緒に考えさせた」**点にあります。

• 従来の AI： 「一般的な知識はあるけど、あなたの会社のシステムは知らないよ」と言って、適当な暗号を作ってしまう。
• PromCopilot： 「あなたの会社の完全な地図を持っているから、その情報と AI の頭脳を合わせて、完璧な答えを作るよ」というスタイル。

結論：
PromCopilot は、複雑なシステム監視を、**「専門用語がわからない新人でも、あるいは疲れたベテランでも、普通の言葉で質問するだけで、プロ並みのデータ分析ができるようにする」**画期的なツールです。これにより、エンジニアは「暗号を解く」作業から解放され、本当に重要な「問題解決」に集中できるようになります。

技術概要

PromCopilot: 大規模言語モデルを用いたクラウドネイティブオンラインサービスシステムにおける Prometheus メトリクスクエリの簡素化

本論文「PromCopilot」は、現代の複雑化するクラウドネイティブオンラインサービスシステムにおいて、エンジニアが Prometheus のメトリクスデータを自然言語で問い合わせ、PromQL（Prometheus Query Language）クエリを自動生成するフレームワークを提案するものです。以下に、問題定義、手法、主要な貢献、実験結果、および意義について詳細にまとめます。

1. 背景と問題定義

背景

現代のオンラインサービス（検索エンジン、EC サイト、SNS など）は、マイクロサービスやコンテナ技術の発展により、非常に複雑かつ大規模化しています。これらのシステムの信頼性と安定性を確保するため、Prometheus に代表されるメトリクス監視システムは不可欠なインフラとなっています。エンジニアは通常、システムの状態や挙動を分析するために、PromQL というドメイン固有言語（DSL）を手動で記述してクエリを実行します。

課題

PromQL クエリの作成には以下の大きな課題があります。

1. 高い学習コストと専門性: PromQL の構文だけでなく、システムコンポーネント（ノード、サービス、Pod など）の配置や依存関係といった「システムコンテキスト」を深く理解する必要があります。
2. コンテキストの欠如: 大規模システムでは、特定のサービスがどのノードにデプロイされているか、どのメトリクス名が使用されているかなどを把握するために、エンジニアは多くの時間を検索に費やさなければなりません。
3. 既存技術の限界:
   • 汎用 LLM: 公開データで訓練されているため、特定のプライベートシステム（メトリクス名、ラベル、ノード ID など）の知識を持っていないため、文法は正しくても文脈に合わないクエリを生成する。
   • ファインチューニング/Few-shot Learning: システムコンポーネントは動的に変化するため、過去のデータに基づく学習は現在のシステム状態と一致しにくい。また、高品質な Q&A ペアの構築自体にコストがかかる。
   • 単純な RAG: 単なるキーワード検索では、サービス名から「そのサービスのデプロイ先ノード」を特定するといった多段推論（Multi-hop reasoning）が困難である。

2. 提案手法：PromCopilot

PromCopilot は、**知識グラフ（Knowledge Graph）と大規模言語モデル（LLM）**の協調推論（Synergistic Reasoning）を活用したテキストから PromQL への生成フレームワークです。

全体アーキテクチャ

システムは「システムコンテキスト知識グラフの構築」と「自然言語質問からの PromQL 生成」の 2 つのフェーズで構成されます。

A. システムコンテキスト知識グラフの構築

Kubernetes ベースのクラウドネイティブシステムを対象に、以下の 4 つのデータソースから自動的に知識グラフを構築します。

1. Prometheus: メトリクス名、説明、ラベル、値などのメタデータ。
2. Kubernetes: ノード、Pod、Service、Deployment などのリソースとその関係性。
3. Traces: 分散トレーシングデータから、サービス間の呼び出し関係や API の依存関係を抽出。
4. ドキュメント: サービスや API の機能説明。

このグラフには「システムコンポーネント（Node, Pod, Service など）」と「メトリクスデータ（Metric, Label-Value Pair）」の 2 種類のエンティティと、それらの間の依存関係や階層関係が定義されます。

B. クエリ生成プロセス

1. 質問解析（Question Parsing）:
   • LLM を用いて、ユーザーの自然言語質問から「コンポーネント関係パス（例：Service → Pod → Node）」と「メトリクス - コンポーネント対（例：(available_memory, node)）」を抽出します。
   • 抽出されたパスにはプレースホルダー（例：?）が含まれる場合があり、これは後続の検索で埋められます。
2. システムコンポーネント知識の検索:
   • 抽出された関係パスに基づき、知識グラフ内で Breadth-First Search (BFS) を実行し、実際のデプロイ構成（例：order-service がどの Pod と Node に存在するか）を特定する「推論パス（Reasoning Paths）」を抽出します。
3. メトリクス知識の検索:
   • 抽出されたメトリクス記述とコンポーネントタイプに基づき、候補メトリクスを BM25 などで検索・ランキングします。
   • 推論パスで特定されたコンポーネントに関連するラベル値ペアも検索し、メトリクスとコンポーネントを結びつけます。
4. クエリ生成（Query Generation）:
   • 抽出された自然言語質問、検索されたメトリクス情報、推論パス（システムコンテキスト）を LLM のプロンプトに入力し、正確な PromQL クエリを生成させます。

3. 主要な貢献

1. PromCopilot の提案: 知識グラフと LLM の協調推論に基づく、初のテキストから PromQL への生成フレームワーク。
2. ベンチマークデータセットの構築: 既存の公開データセットが存在しないため、オープンソースのマイクロサービスシステム（TrainTicket）に基づき、280 件の自然言語質問と PromQL クエリのペアからなる初のベンチマークデータセットを人手で構築し、公開しました。
3. 実証実験: 大規模な実験を通じて、PromCopilot の有効性を検証し、既存のベースライン手法（単純なプロンプトや Few-shot Learning）を大幅に上回る性能を示しました。

4. 実験結果

GPT-4-Turbo および DeepSeek-Coder-V2-236B をバックボーン LLM として使用し評価を行いました。

• クエリ生成精度（QueryAcc）:
  • PromCopilot: 69.1% (GPT-4-Turbo 使用時)
  • ベースライン（Basic Prompt）: 2.6%
  • ベースライン（Few-shot Learning, 10-shot）: 37.4%
  • PromCopilot は、従来の手法と比較して大幅な精度向上を実現しました。
• 知識検索精度:
  • メトリクス検索の Recall: 90.3%
  • 推論パス検索の Recall: 90.8%
  • 必要な知識を高い確率で取得できていることが確認されました。
• アブレーション研究:
  • メトリクス知識やシステムコンポーネント知識のいずれかを欠くと、精度が著しく低下することから、両方の知識が不可欠であることが示されました。
• パイロットユーザースタディ:
  • 8 名の経験豊富なエンジニアによる評価において、PromCopilot を使用した場合のタスク完了時間は、他のツールを使用した場合の約 26%（101 秒 vs 382 秒）に短縮されました。
  • ユーザーからは「有用性」および「正確性」について高い評価（平均スコア 3.75/4.0, 3.5/4.0）を得ました。

5. 意義と将来展望

• 実用性: 複雑なクラウドネイティブシステムにおいて、エンジニアがメトリクス分析を行う際の負担を大幅に軽減し、運用効率を向上させます。
• 技術的革新: 単なる LLM によるコード生成ではなく、ドメイン固有の知識グラフと LLM を組み合わせることで、動的で文脈依存性の高いタスクを解決する新しいアプローチを示しました。
• 将来の展開: 現在は Kubernetes と Prometheus に限定されていますが、他の監視プラットフォームやシステムアーキテクチャへの拡張、LLM のファインチューニングによる生成精度のさらなる向上が期待されます。

本論文は、AIOps（人工知能による運用）分野において、自然言語と監視データの橋渡しを行う重要な一歩であり、PromCopilot はその実現に向けた実用的かつ効果的なソリューションとして位置づけられます。