AIを活用した監視アラーム自動切り分けシステムをDifyでノーコード開発してみる

AIChatGPT＆AIDevOpsLLMs-sato

はじめに

対象読者のレベル感

本記事は、日々大量の監視アラームに悩まされているIT運用担当者の方や、プログラミング知識はあまり無くてもAIを活用したシステム開発に興味がある方を主な対象としています。
Difyを使ったノーコード開発に興味がある方にも役立つ内容です。

前提知識として、監視アラームの運用に関する基本的な理解があれば、本記事の内容をより深く理解できると思います。

記事のゴール

本記事を読めば、Difyを使って監視アラームの自動切り分けシステムを構築する具体的な手順と、そのメリット・注意点が理解できます。

完成後のイメージとしては、監視アラームメッセージを投入するだけで、そのアラームが「静観OK」か「既知のアラーム」なのか、それとも典型的な「SQL文法エラー」なのか、あるいは「未知のアラーム」の場合は原因として考えられるものまで示してくれるシステムを目標とします。

必要な前提知識

生成AIに関する基本的な知識は必要となりますが、Difyに関する特別な前提知識は不要です。

Difyとは

Difyは、生成AIアプリをノーコードで簡単に開発できるプラットフォームです。プログラミング知識がなくても、大規模言語モデル (LLM) を活用したアプリケーションを、直感的なUI操作で作成することができます。これにより、AIの力を借りて業務課題を解決する敷居が大幅に下がります。

Difyで監視アラームを切り分け - 処理フローの概要

日々発生する大量の監視アラームは、運用チームにとって大きな負担となり、「オオカミ少年状態」に陥りがちです。その結果、本当に重要な不具合に関わるアラームを見落としてしまう恐れも出てきます。この課題を解決するため、Difyを使って監視アラームを自動で切り分けるシステムを構築する構想が生まれました。

今回目指す処理フローは、ざっくりと以下の通りです:

  1. 監視アラームのメッセージ内容をDifyに流し込む
  2. メッセージ内に「システム影響無し」と分かっている既知の文字列があった場合、静観OKアラームとして処理する
  3. そうでない場合、SQL文法エラーによるものかをLLMに判断させる (開発者が調査のためにデータベースにアクセスする際に、作業用SQLの文法エラーでアラームが発生することが多く、これがノイズとなっているため、LLMの活用が期待される場面です)
  4. それでもない場合、既知のアラーム一覧をDifyにナレッジとして学習させておき、該当するアラームがあるかを判断してもらう。 該当する場合はナレッジに記載されている説明も返してもらう
  5. ここまですべてに該当しない「未知のアラーム」の場合、LLMにそのアラームのメッセージ内容を丸投げし、原因として考えられるものを調査してもらう

各判断ステップの詳細

全体図としてはこのようになります。画像が小さいですが、まずは処理全体の雰囲気を伝えるためです。後ほど細かく説明していきます。

静観OKアラームか判断

最初のステップとして、メッセージ内容が特定の既知の文字列を含む場合を「静観OKアラーム」と判断します。今回はサンプルとして、「atlas_schema_revisions」または「unaffected changes were applied」のいずれかが含まれていれば静観OKと設定しました。条件は複数追加可能ですが、管理上の問題を考慮すると、多くなりすぎる場合はナレッジとして別出しした方が良いと思います。

SQL文法エラーか判断

このステップはDifyを活用した監視アラーム切り分けの最初の「見せ場」です！ SQL文法エラーはメッセージ内容が一定ではないため、文字列ベースのマッチングでは判断が困難です。まさにLLMが活躍できる場面と言えるでしょう。

ここでは、アラームメッセージをLLMに丸投げしてSQL文法エラーか調査を指示し、判断結果を「YES」/「No」で返してもらい、その後の分岐に繋げます。

既知アラームをナレッジ検索

次に、過去に発生した既知のアラームとその対処法や説明をDifyの「ナレッジ」機能に学習させ、検索できるようにします。

ナレッジは、フロー作成画面とは別の「ナレッジ」画面でテキストファイルを読み込ませて作成します。今回はサンプルとして2つの既知アラームを読み込ませました。

---
## LOG:  FATAL:  pg_hba.conf rejects connection for host \"xxx.xxx.xxx.xxx\", user \"xxxxxxxxxx\", database \"rdsadmin\", SSL encryption
- 説明:  
該当ユーザーが、RDSのシステム用DB rdsadmin にアクセスしようとして失敗した際のログ。
恐らく操作ミスのため、頻発しなければ静観してOK。  

---
## We currently do not have sufficient capacity in the region you requested. Our system will be working on provisioning additional capacity. You can avoid getting this error by temporarily reducing your request rate. (Service: AWSLambda; Status Code: 500; Error Code: ServiceException
- 説明:  
AWS Lambdaサービスの一時的な問題、もしくはAWSインフラ側の問題でまれにLambdaの起動に失敗することがある。リトライしてLambdaの起動/処理が成功しているなら特に対応は不要。  
ただし、頻発するような場合は、AWSサポートに問合せてみる。  
参考:  
https://repost.aws/questions/QUnqsxSXqxSN6My2Nvbokh-w/lambda%E9%96%A2%E6%95%B0%E5%91%BC%E3%81%B3%E5%87%BA%E3%81%97%E6%99%82%E3%81%AB-500-%E3%82%A8%E3%83%A9%E3%83%BC%EF%BC%88-service-exception%EF%BC%89%E7%99%BA%E7%94%9F

ナレッジ作成時の重要なポイントは以下の通りです:

  • ベクトル検索ではなくハイブリッド検索を用いる：より高い精度で関連情報を検索できます。
  • トップKは1にする：今回ように監視アラームが既知のものかの切り分けをしたい場合は、上位2件以上をヒットさせても2件目以降は使いようが無いためです。
  • スコア閾値を設定する：これを設定しないと、マッチ度が非常に低いものでも結果として返ってきてしまう可能性があるため、適切な情報を絞り込むためには重要な設定項目です。

ナレッジを作成したら、フロー作成画面で知識検索ブロックを作成し、ナレッジベースとして先ほど設定したものを指定します。

既知アラームか判断＋未知の場合は原因調査

ナレッジ検索が終わったら、その結果を元に再度LLMに指示を出します。具体的には、ナレッジ検索に該当結果があったかどうか、そして結果が無かった場合は原因を調査するような指示をLLMに与えます。

これにより、既知のアラームであれば、ナレッジに記載されている説明を返してもらい、未知のアラームであればLLMがメッセージ内容から考えられる原因を推測し、その結果を返してくれるようになります。

変数集約など

途中でいくつかの分岐が発生するため、フローの最後では、これらの分岐先のいずれかのブロックの出力結果を一つにまとめ、フローを終了させます。これにより、最終的な出力が一箇所に集約されます。

動作確認

以上のステップでフローが完成したので、実際に動作を確認してみましょう。

静観OKアラーム

「atlas_schema_revisions」を含むアラームメッセージを投入すると、フローの上段部分が流れ、「静観OK」と結果が返ってきました。

SQL文法エラーのアラーム

SQL文法エラーに関連するアラームを試すと、フローの中段部分が流れ、「SQL文法エラー」と結果が返ってきました。

既知アラーム

既知のアラームを投入すると、フローの下段部分が流れ、「既知アラームに類似のものがある旨」と、ナレッジに記載されている説明内容が少し校正されたものが返ってきました。

未知アラーム

最後に未知のアラームを試すと、またフローの下段部分が流れましたが、既知アラームに類似のものがなかったため、LLMによる原因調査が行われ、その結果が返ってきました。

Difyを運用に組み込むために

構築したDifyフローを実際の運用に組み込むには、いくつか考慮すべき点があります。

Difyは他サービスとの連携ツールも提供されており、送信機能にはSlackへのWebhook送信ツールがあります。また、標準でHTTPリクエストを行うブロックも提供されています。受信機能という面では、Difyのフロー実行はAPIとしてHTTPリクエストから行うことも可能です。送信受信の両方の連携が可能であるため、これらの機能を活用すれば、アラーム監視システム→このDifyフローを実行→Slackへ送信という形で連携することで、現状のアラーム監視運用に組み込むことが可能になります。

加えて、ナレッジの追加や更新に関しても、アラーム通知画面からワンアクションで取り込めるようにするなど、運用負荷がかからないような仕組みを考案すると、さらに使いやすいシステムになると思います。

コスト面での注意

DifyでLLMの処理を行う部分にはAPI利用料金が発生します。そのため、アラーム監視に組み込む際は、特に大量のアラームが発生した場合に備えて、以下の点に注意が必要です:

  • 文字列マッチングやナレッジ検索だけで判断可能なものは、極力そこで分岐させるようにして、LLMブロックはなるべく通らないように配慮する。今回の例では、ナレッジ検索の結果も含めてLLMに判断させていますが、可能であればナレッジ検索の結果有無で分岐させてからLLMに流し込むなどの工夫が有効です。
  • 全ての監視アラームを流し込むという運用ではなく、アラームを調べたい時だけ実行できるようにする。(例: Slackで特定スタンプを押した場合にだけDifyフローが実行されるなど)。

また、SaaSとして提供されているDifyを利用する場合は、複雑な機能は有料プランが必要になるケースもあります。さらに、ナレッジに機密情報が含まれる場合にはSaaS上に読み込ませるリスクもあるため、Community Edition をオンプレミスに構築するなどの配慮も必要になってきます。

まとめ

学んだことの整理

本記事では、Difyを使って監視アラームを自動で切り分けるシステムをノーコードで構築するプロセスを学びました。重要なポイントを整理しましょう。

  • Difyは、プログラミング知識なしでLLMを活用したアプリを開発できるノーコードプラットフォームです。
  • 監視アラームの自動切り分けにDifyを導入することで、「オオカミ少年状態」の解消や、重要なアラームの見落としリスクの軽減が期待できます。
  • Difyのフローでは、文字列マッチング、LLMによる高度な判断（SQLエラー判定、未知アラーム原因調査）、そしてナレッジ検索を組み合わせることで、多段階的かつ柔軟なアラーム切り分けを実現できます。
  • 特にナレッジ検索では、ハイブリッド検索の利用、トップKを1に設定すること、そしてスコア閾値を適切に設定することが、精度の高い検索結果を得るために重要です。
  • 構築したシステムを運用に組み込むためには、Difyが提供するAPI連携機能やWebhook送信ツールを活用し、既存の運用フローとの連携を図ることが鍵となります。また、運用負荷を考慮したナレッジ管理の仕組み化も重要です。
  • コスト面ではLLMのAPI利用料金に注意が必要であり、LLMの利用を最小限にするようなフロー設計や、必要な時にのみ実行するような運用方法の工夫が求められます。
  • 機密情報を扱う場合は、SaaS版Difyの利用リスクを考慮し、Community Editionをオンプレミスに構築するなどのセキュリティ対策も検討すべきです。

次の応用ステップ

今回構築した監視アラームの自動切り分けシステムは、DifyとLLM、ナレッジ検索の強力な組み合わせを示す一例に過ぎません。ここからさらに発展させるなら、以下のような応用ステップが考えられます:

  • 他のIT運用業務への応用: インシデントチケットの自動分類、障害発生時の初動対応ガイダンス、ログ分析の補助など、LLMとナレッジ検索が有効な様々な分野に応用できるでしょう。
  • カスタマーサポートや社内FAQ応答への応用: 顧客からの問い合わせや社内ヘルプデスクへの質問に対し、自動で適切な回答を生成したり、ナレッジベースから関連情報を提示するシステムに発展させることが可能です。
  • より高度な自動化: Slackなどのコミュニケーションツールと連携を強化し、アラーム発生時にシステムが自動で回答を生成し、チャットで通知するだけでなく、さらには特定の条件に基づいて自動でチケットを起票したり、簡単な対処コマンドを実行するような高度な自動化を目指すこともできます。
  • ナレッジの自動生成・更新: アラームの履歴や解決策から、LLMを活用して自動でナレッジを生成したり、既存のナレッジを最新の情報に更新する仕組みを導入することで、運用負荷をさらに低減できる可能性があります。

Difyを使えば、プログラミングの専門知識がなくても、AIの力を活用した革新的なアプリケーションを迅速に開発し、日々の運用業務を効率化することが可能です。ぜひ、皆様の現場の課題解決にDifyを活用してみてください。

新規CTA