SRGについて技術記事採用情報
SRGについて技術記事採用情報
HOME/技術記事/アラートの Description を動的な Runbook として活用する自動復旧ワークフロー

アラートの Description を動的な Runbook として活用する自動復旧ワークフロー

メディア統括本部 サービスリライアビリティグループ（SRG）の長谷川（@rarirureluis）です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
CyberAgent Group SRE Advent Calendar 2025の17日目の記事になります。
本記事は、Grafana のアラート説明文を AI に解釈させて復旧コマンドを自動生成する仕組みを検証し、スクリプト保守の手間を省きつつ柔軟な障害対応を実現する手法を紹介したものです。
💡
本記事に出てくるホスト名やアラートは所属する企業とは関係ない、個人のものとなります。
今回は、Grafana のアラート機能、ワークフロー自動化ツールの n8n、そして AI を組み合わせることで、アラートに含まれる説明文（Description）を読み解き、自動で復旧コマンドを生成・実行する仕組みを検証しました。

背景と目的

通常、障害復旧の自動化（Auto-Remediation）を行う場合、アラートごとに特定のスクリプトや Ansible Playbook などを紐付ける実装が一般的です。
しかし、この方法ではアラートの種類が増えるたびにスクリプトを開発・保守する必要があります。
そこで今回は、「Grafana のアラート設定にある Description （説明文） をそのまま Runbook （手順書） として扱う」というアプローチを試みました。
自然言語で書かれた復旧手順を AI が解釈し、適切な Linux コマンドをその場で生成して実行することで、柔軟な自動復旧フローが実現できるかを検証します。
💡
Grafana アラートは runbook(URL) を指定することもでき、n8n でこれをフェッチすることも可能ですが今回は description を採用します。

アーキテクチャと仕組み

今回の検証環境の構成は以下の通りです。
  1. Grafana: 監視およびアラートの発報。
Description フィールドに復旧手順を自然言語で記述します。
  1. n8n: Webhook でアラートを受信し、ワークフローを制御します。
  1. AI (LLM): n8n 上の AI ツール（LangChain ノード等）を利用し、Description の内容から実行すべき Linux コマンドを生成します。
  1. 対象サーバー: 生成されたコマンドが実行される環境です。

処理の流れ

  1. Grafana が異常を検知し、アラートを発報する。
  1. アラート通知（Webhook）が n8n に送信される。
このペイロードには Description が含まれる。
  1. n8n が Webhook を受信し、Description のテキストを抽出する。
  1. n8n 上の AI エージェントが Description を読み込み、「この手順を実行するための Linux コマンド」を生成する。
  1. 生成されたコマンドを n8n が対象サーバー（または SSH 経由）で実行する。
  1. 実行結果を確認し、復旧完了とする。

実装と検証

1. n8n Webhook を Grafana のアラート先に登録

 

2. アラートのルーティングポリシーを追加

アラートにラベル の場合に、n8n の Contact Point を呼び出すようにポリシーを追加します。
 

3. Grafana アラートの設定

まず、Grafana でアラート・ルールを作成します。
ここでのポイントは、Summary や Description に、AI への指示となる具体的な復旧手順を記述することです。
例えば、Web サーバーのプロセス監視アラートの場合、以下のように記述します。
  • Alert Name: Nginx Down
  • Description:
このように、「何を確認し、どう対処するか」を英語（または日本語）で記述しておきます。
これがそのまま動的な Runbook となります。
また先ほどのルーティングポリシーに合致するようにラベルを追加します。
 
を実行することでどのルーティングポリシーに合致するか確認し、n8n になれば OK です。
 

2. n8n ワークフローの構築

n8n 側では、以下のようなノード構成でワークフローを作成しました。
  1. Webhook Node: Grafana からの POST リクエストを受け取ります。
  1. AI Agent Node: 受け取った (Description) をプロンプトとして入力します。
    1. プロンプト全文
  1. Execute Command Node: AI が出力したコマンドを受け取り、実際にサーバー上で実行します（SSH ノードを使用する場合もあります）。
 

Webhook の内容

 

AI Agent Node の動作確認

左ペインが入力で、真ん中が AI Agent Node の設定画面、右側が AI Agent Node のアウトプットです。
出力は となっており、プロンプト通りに Linux コマンドのみが出力されています。
変数展開後のプロンプトの内容
 

Execute command

SSH する先のマシンも動的に利用することができます。
これは Webhook で受け取ったラベルの中にある instance を指定しています。
 
あとは AI Agent Node で出力されたコマンドを変数で呼び出せば完成です。
 

3. 動作検証

実際に Grafana にアラートを発報させてみました。
  1. アラート発報: Grafana がダウンを検知し、n8n へ Webhook を送信。
  1. AI 解析: n8n 上の AI が Description を読み取り、コマンドを生成。
  1. 自動復旧: n8n が上記コマンドを実行。
その後、Nginx が再起動していることを確認しました。
検証の結果、事前に固定のスクリプトを用意することなく、Grafana の Description を書き換えるだけで復旧動作をコントロールできることが確認できました。
 

考察と今後の課題

今回の検証により、「Description = Runbook」 という構成が技術的に可能であることが分かりました。
このアプローチには以下のメリットがあります。
  • メンテナンス性の向上: 復旧ロジックを変更したい場合、コードを修正するのではなく、Grafana のアラート説明文を修正するだけで済む。
  • 属人化の解消: 手順が明文化され、かつそれが自動実行されるため、ドキュメントと実態の乖離がなくなる。
一方で、実運用に向けてはいくつかの課題も浮き彫りになりました。
  • 安全性（ハルシネーションのリスク）: AI が誤って破壊的なコマンド（例: データの削除など）を生成するリスクがあります。
本番環境で適用するには、「読み取り専用コマンドのみ許可する」「実行前に Slack で人間の承認（Approval）を挟む」といったガードレールが必要です。
  • 権限管理: n8n からコマンドを実行するためのユーザー権限を適切に絞る必要があります。

まとめ

Grafana、n8n、そして AI を組み合わせることで、アラートの Description を動的な Runbook として活用する自動復旧ワークフローを構築できました。
AI にコマンドを生成させるというアプローチは、定型的な運用作業を劇的に効率化する可能性を秘めています。
今後は、より安全な実行フローの設計や、複雑な障害対応シナリオへの適用について検証を進めていく予定です。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。