Posted inAI

実践AIOps：LLMを活用したPrometheusアラート分析と根本原因分析（RCA）

AI tutorial - IT technology blog
AI tutorial - IT technology blog

午前3時の呼び出しを超えて：なぜ手動の監視は限界を迎えるのか

オンコールのシフトが当て推量のゲームであってはなりません。多くのDevOpsエンジニアは、インシデントの最初の20分を単なるコンテキスト収集に費やしています。通常、問題が発生している特定のPodを探したり、ログからスタックトレースをスキャンしたり、最近のデプロイがレイテンシの15%スパイクの原因かどうかを確認したりすることに追われます。これは生産性を著しく低下させる、骨の折れる手作業です。

Prometheusは「何が」壊れているかを特定することには優れていますが、「なぜ」壊れたのかを説明するロジックに欠けています。このギャップがアラート疲れを引き起こし、チームは人間の目によるフィルタリングが必要な数百もの通知に埋もれてしまいます。大規模言語モデル（LLM）を「ファーストレスポンダー（初期対応者）」として統合することで、この初期調査フェーズを自動化できます。

これを本番環境に導入すると、通常、目覚ましい成果が得られます。私の最近のプロジェクトでは、エンジニアがターミナルにログインする前に分析済みのレポートを提供することで、平均修復時間（MTTR）を40%短縮できました。

Prometheusと大規模言語モデルの連携

目標は、監視データとGPT-4oやローカルのLlama 3のようなLLMとの間に架け橋を築くことです。単にAIにアラートの要約を依頼するだけではありません。メタデータ、過去のパターン、ランブック（運用手順書）の指示を評価させることで、深い根本原因分析（RCA）を実行させます。

ワークフローのアーキテクチャ

自動化されたパイプラインは、以下の5つの明確なステージで構成されます。

  1. 検知（Detection）： Prometheusがメモリリークなどのしきい値超過を特定します。
  2. グルーピング（Grouping）： Alertmanagerが関連するアラートをまとめ、カスタムWebhookにJSONペイロードを送信します。
  3. エンリッチメント（Enrichment）： PythonベースのWebhookが、最新のログやPodのステータスなどの追加コンテキストを取得します。
  4. 分析（Analysis）： LLMがデータを処理し、構造化されたRCAレポートを生成します。
  5. 配信（Delivery）： 最終的な分析結果が、推奨される修正案と実行ボタンと共にSlackに表示されます。

実装ガイド

重い処理を担当する機能的な Python レシーバーを構築してみましょう。このサービスは、監視スタックの知能レイヤーとして機能します。

ステップ1：Prometheusアラートの定義

プロセスをトリガーするには、高品質なアラートが必要です。以下のルールはメモリ使用率を監視します。消費量が5分以上にわたって85%を超えると、アラートを発報します。これを alert_rules.yml に保存してください。

groups:
- name: host_alerts
  rules:
  - alert: HighMemoryUsage
    expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 85
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "{{ $labels.instance }} でホストのメモリ使用率が高騰しています"
      description: "メモリ使用率が5分以上にわたり85%を超えています。"

ステップ2：LLM Webhookレシーバーの構築

FastAPIは、軽量で非同期のJSONリクエストを効率的に処理できるため、この用途に最適なツールです。このスクリプトはPrometheusのアラートをキャプチャし、OpenAI APIに転送します。

まず、必要な依存関係をインストールします。

pip install fastapi uvicorn openai

以下がレシーバーのコアロジックです。

from fastapi import FastAPI, Request
from openai import OpenAI
import os

app = FastAPI()
client = OpenAI(api_key="your_api_key_here")

@app.post("/webhook")
async def prometheus_webhook(request: Request):
    data = await request.json()
    
    for alert in data.get('alerts', []):
        alert_name = alert['labels'].get('alertname')
        instance = alert['labels'].get('instance')
        description = alert['annotations'].get('description')
        
        # LLMにSREとして振る舞うよう指示
        prompt = f"""
        以下のKubernetesアラートを分析してください：
        - アラート名: {alert_name}
        - インスタンス: {instance}
        - 説明: {description}
        
        以下の内容を含む簡潔なレポートを提供してください：
        1. 考えられる根本原因。
        2. 診断のためのコマンド（例: kubectl top pods）。
        3. 即時の解決策。
        """
        
        response = client.chat.completions.create(
            model="gpt-4o",
            messages=[{"role": "user", "content": prompt}]
        )
        
        analysis = response.choices[0].message.content
        print(f"--- {alert_name} の根本原因分析（RCA） ---\n{analysis}")
        
    return {"status": "processed"}

ステップ3：本番環境向けRCAのためのプロンプトエンジニアリング

AIOpsシステムの品質は、完全にコンテキスト（文脈）に依存します。アラート名だけを提供しても、AIは一般的なアドバイスしか返せません。具体的な回答を得るには、プロンプトテンプレートに社内のランブックを含める必要があります。

ドキュメントの断片をLLMに読み込ませることで、LLMを一般的なアシスタントから、特定のインフラに精通したエキスパートへと変貌させることができます。例えば、メモリ圧迫を検知した場合、dmesg ログから特にOOM killerのパターンを確認するようモデルに指示します。

# 精度向上のための拡張コンテキスト
system_context = """
あなたは熟練したSREです。以下の内部ルールに従ってください：
- メモリの問題については、'top -o %MEM' を使用して上位3つのプロセスを特定すること。
- Javaヒープがコンテナ制限の80%を超えていないか確認すること。
- ログの直近100行から 'Out of memory' のパターンを検索すること。
"""

ステップ4：Alertmanager Webhookの有効化

最後に、Prometheus Alertmanagerを設定して、通知をPythonサービスにルーティングするようにします。alertmanager.yml の設定を更新してください。

receivers:
- name: 'aiops-bridge'
  webhook_configs:
  - url: 'http://your-webhook-server:8000/webhook'

route:
  receiver: 'aiops-bridge'

自己修復システムへの道

分析は戦いの半分に過ぎません。論理的な次のステップは「ヒューマン・イン・ザ・ループ（人間が介在する）」自動化です。LLMに本番サーバー上で自律的にコマンドを実行させることは推奨しませんが、橋渡しをさせることは可能です。

一般的なパターンとしては、Slackのアラートに対話型のボタンを追加する方法があります。LLMが容量95%に達している /tmp ディレクトリのクリーンアップを提案した場合、Slackメッセージに [クリーンアップを実行] ボタンを含めることができます。これをクリックすると、定義済みのAnsibleプレイブックが実行されます。

このアプローチにより、手動でのCLI操作を排除しつつセキュリティを維持できます。このセットアップはインフラと共に進化します。プロンプトを洗練させていけば、朝の最初のコーヒーを飲み終える前に、解決策が手元に用意されているようになるでしょう。

Share:
Tags: