JavaScriptを有効にしてください

Azure Monitor アラートを自動化して生成 AI を使い隊

 ·   6 分で読めます  ·   Kento

Azure の監視をしていますか？
Azure Monitor ではデータ収集、データの格納、データの利用の機能を提供しています

今回はデータの利用方法の1つである、「アラート」に生成 AI を組み合わせてみます

アラートで行うこと

アラートと聞くと何をイメージしますか？

メール通知を想像した方は多いのではないでしょうか？
しかし、本当にすべて通知する必要がありますか？

flowchart TD
    A[アラートのトリガー] --> B{自動修正できるか？}
    B -- はい --> C[自動修正]
    B -- いいえ --> D[ユーザーに通知]

こんなことができれば、もっと嬉しいですよね？
通知されたユーザーは対応マニュアルや製品の公式情報を見て対応を行うのであれば、その情報も通知にあると嬉しいですよね？
図にするとこんなイメージでしょうか

flowchart TD
    A[アラートのトリガー] --> B{自動修正できるか？}
    B -- はい --> C[自動修正]
    B -- いいえ --> D["対応マニュアル/公式情報を
                      RAG を使って収集"]
    D --> E[ユーザーに通知]

これが実現できるかどうかを試してみたいと思います

ざっくり手順

  1. 監視対象の作成
  2. 自動修正を構築
  3. 自動修正の場合の監視設定
  4. 検証①
  5. RAG を構成
  6. RAG を使用する場合の監視設定
  7. 検証②

1. 監視対象の作成

1台の Windows VM を作成します
VM は IIS を有効化しておきます

監視用に VM Insights も有効化しておきます
VM insights の概要 - Azure Monitor | Microsoft Learn

architecture-beta

group vnet(azure:virtual-networks)[Vnet]
    group subnet(azure:subnet)[Subnet] in vnet
        service vm(azure:virtual-machine)[VM] in subnet

2. 自動修正を構築

自動修正のための仕込みをします
IIS が停止した場合に自動で再起動する仕組みを作ります
Azure VM にはゲスト OS 内にコマンドを実行する方法がいくつかありますが、今回はマネージド実行コマンドを使用します

実際に OS 内で実行する IIS の再起動コマンドはこちらです

1

Start-Service -Name W3SVC

これをマネージド実行コマンドで VM に実行するにはこのようなコマンドになります
初めにマネージド ID での Azure への接続を行い、その後にマネージド実行コマンドを実行します

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Ensures you do not inherit an AzContext in your runbook
Disable-AzContextAutosave -Scope Process

# Connect to Azure with system-assigned managed identity
$AzureContext = (Connect-AzAccount -Identity).context

# Set and store context
$AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription -DefaultProfile $AzureContext

Set-AzVMRunCommand -ResourceGroupName "myRG" -VMName "myVM" -SubscriptionId "xxxx" -Location "EastUS" -RunCommandName "StartIIS" –SourceScript "Start-Service -Name W3SVC"

Remove-AzVMRunCommand -ResourceGroupName "myRG" -VMName "myVM" -RunCommandName "StartIIS"

アラート発報時にこのコマンドを自動実行する仕組みとしては Azure Automation を使用します
専用の Automation Rubook を用意し、マネージド ID に権限を与えておきます

image08
Automation:

アラート発生時の流れとしてはこちらです

flowchart TD
    A["アラートのトリガー"] --> B{自動修正できるか？}
    B -- はい --> C["Azure Automation Runbook 
                     を実行"]
    C --> F["マネージド実行コマンドで
             IIS をスタート"]
    B -- いいえ --> D["対応マニュアル/公式情報を
                      RAG を使って収集"]
    D --> E[ユーザーに通知]

3. 自動修正の場合の監視設定

IIS の稼働を監視するために、インベントリ監視を有効化しておきます

image01
インベントリの有効化:

Windows サービスで [W3SVC] を検索すると、IIS の稼働状況を確認できます

image05
Windows サービス:

これは Log Analytics ワークスペースにデータが蓄えられているのものが可視化されています
下記の KQL を実行すると IIS の稼働状況が収集できていることがわかります

ConfigurationData 
| where ConfigDataType == "WindowsServices" and SvcName contains "w3svc" 
| project TimeGenerated, Computer, ConfigDataType, SvcName, SvcDisplayName, SvcState

image06
Log Analytics:

IIS が停止したかどうかは Log Analytics ワークスペース内の別のテーブルを確認する必要があります
IIS の停止を検知する KQL はこちらです
これにより IIS の現在の状態が停止 (SvcState == “Stopped”) になってしまったことを検知することができます

ConfigurationChange
| where ConfigChangeType == "WindowsServices" and SvcName contains "w3svc" and SvcState == "Stopped"
| project TimeGenerated, Computer, ConfigChangeType, SvcName, SvcDisplayName, SvcChangeType, SvcPreviousState, SvcState
image07
Log Analytics:

この検知の速度を上げておくように変更しておきます
[変更とインベントリ センターを開く] > [設定] > [Windows サービス] で収集頻度を 10分にしておきます

image21
インベントリの設定:

image22
インベントリの設定:

image23
インベントリの設定:

この内容でログアラートを設定し、アクション グループには Automation Account を指定します

image10
アラートの作成:

image11
作成したアラート:

4. 検証①

IIS が停止したときに自動で復旧するかをテストしてみます
実行コマンドで IIS を停止させます

1

Stop-Service -Name W3SVC
image18
IIS 停止:

IIS を停止させたので、web ページは表示されていません

image19
IIS 停止:

しばらくしてインベントリ管理からも IIS が停止したことが確認できます

image20
IIS 停止:

アラートがトリガーされ、Automation が無事に実行されました

image24
アラート:

image25
Automation ジョブ:

Web ページにアクセスしてみると、無事に表示されるようになりました

image26
IIS の確認:

5. RAG を構成

続いて、自動対応できない場合のアラートを RAG で情報収集し、ユーザーへ通知を行ってみます
今回使用する RAG は Logic Apps を使って用意してみます
こちらのサンプルを使って用意しました
https://github.com/Azure/logicapps/tree/master/ai-sample

サンプルを実行すると２種類の Logic Apps ワークフローが作成されます

  • ingest-data : データ取り込み用
  • chat-workflow : ingest された内容にチャットで検索する用
image02
Logic Apps ワークフロー:

今回は RAG で検索する PDF としては Azure の公開情報にあるトラシューページの一部を PDF にしたものを利用します
Microsoft Azure のトラブルシューティング に関するドキュメント | Microsoft Learn

Storage Account の Blob などに PDF にしたものを置いて ingest-data ワークフローを実行します

image03
ingest-workflow:

PDF の内容が検索できるか確認するために chat-workflow を実行します

image04
chat-workflow:

無事に期待通りの結果が返ってきました

image09
chat-workflow:

6. RAG を使用するアクションの設定

作成した Logic Apps をアラートのアクショングループで利用できるように修正していきます
Azure Monitor アラートをカスタマイズする方法はこちらを参考にします
Logic Apps を使用してアラート通知をカスタマイズする - Azure Monitor | Microsoft Learn

chat-workflow を編集していきます

  1. トリガーを削除し、[When a HTTP request is received] を選びなおします

  2. Request Body JSON Schema に公開情報に記載のあるアラートスキーマを貼り付けます

    image12
    chat-workflow:

  3. トリガーの直後に公開情報にの記載のある [変数の初期化] を入力します
    ※リソースの読み取りは今回は使わないので割愛

    image13
    chat-workflow:

続いて Azure Open AI に関する部分を今回用にカスタマイズしていきます

  1. [generate search query] の3行目を var original_user_query = workflowContext.trigger.outputs.body.data.essentials.description に書き換えます

    image14
    chat-workflow:

  2. Get chat completions の ユーザーメッセージをアラートの詳細を参照するように変更します

    image16
    chat-workflow:

最後に通知設定を行います。今回は Teams に通知するように設定します

image15
chat-workflow:

7. RAG を使用する場合の監視設定

簡単にするために、VM の死活監視をしてみます
死活監視はいろいろな方法があります
Azure VM における死活監視の考え方 | Japan Azure Monitoring Support Blog

今回は Heartbeat の死活監視を行います
設定方法はこちらにならいます
死活監視のクエリについて | Japan Azure Monitoring Support Blog

アクションでは作成した Logic Apps を使用します

image17
アクショングループ:

7. 検証②

監視対象 VM を停止してしばらく放置します
Heatbeat が途絶えたアラートが発報されました

image27
アラート:

Logic Apps の実行履歴を見るとちゃんと実行されています

image28
Logic Apps:

通知先の Teams を確認してみると、無事に通知されていました

image29
Teams:

まとめ

Azure Monitor のアラートを自動化して生成 AI を使ってみました
自動化：対応があらかじめ決まっているアラートであれば、自動化することで人手を削減できそうです
生成 AI：対応が決まっていないアラートであれば、生成 AI を使って情報収集を行うことで対応をスムーズにできそうです
アプリケーション部分で注目が集まりがちですが、監視の文脈でも生成 AI は使えそうです！

参考

共有
Kento
著者
Kento
2020年に新卒で IT 企業に入社. インフラエンジニア（主にクラウド）として活動中

関連記事