近年ITインフラの複雑化や運用負荷の増加によってAIによる自動化の重要性が高まっており、その中でも当社が注目しているのがAI Opsプラットフォームである「Selector AI」です。
現在当社ではSelector AIによる監視自動化の検証を進めています。検証方法や現段階で得られている結果についてご紹介します！Selector AIについての詳細は以下の記事もご覧ください。
検証項目(検証目的)
Selector AI活用による運用負荷の軽減・自動化に向けて、Selector AI ＋ Zabbixで以下が実現可能か検証することにしました。
- 発生アラート(障害)の状況把握ができるか
- 発生したアラートについてエスカレーションの要・不要を判断できるか
- 上記を行った上で必要な場合は他サービス(SlackやSquadcast)に通知できるか
- 発生アラートについて原因を特定したうえでエスカレーションできるか
- チャットでの質問に対して正確に回答できるか
検証ステップ１：収集するデータ選別
AIは最初から万能なわけではありません。
たくさんのデータを収集し、収集したデータから要・不要(今回の場合エスカレーションの要・不要)の判断ができるように学習させる必要があります。そのためにはまず必要・不要の両方のデータをすべてAIへ収集する必要があり、今回の検証では以下のデータをZabbixからSelector AIへ送ることにしました。
- SNMP Polling
- SNMP Trap
- Syslog
ただ、この情報だけでは「どんなネットワーク構成なのか」をSelector AIが理解できず原因の究明やエスカレーション要・不要の学習にも支障をきたすため、以下の情報も与える必要がありました。
- ホスト名、IPアドレス
- 構成図(論理、物理構成など)
- それぞれの機器の役割
- 通信フロー(または処理のフロー)
上記のデータをSelector AIで収集し、正常な状態、異常な状態をAIに教えていくことにより、どんな状態の時に「異常あり」と判断するか学習し、問題のある状況を自動判別できるようになります。
検証ステップ２：情報の取込・Zabbixとの連携
前章で記載したZabbix、Syslog、SNMP Trapなど複数の情報源のデータをZabbixからSelector AIへ送る必要があります。
Selector AIには複数のコネクターが用意されており、様々なサービスとAPI連携ができるようになっています。これにより運用者の様々なシステム環境に対応できるようになります。
ZabbixからSelector AIにデータを送る方法について、今回はSelector AI社が提供するRemote Engineを利用することにしました。
Selector AIにデータを送る際に、送る方法がない場合(ローカル環境でのみ送られているデータなど)に専用の転送エンジン(Remote Engine)を構築(構築はSelector AI社にて実施)することにより、Remote Engine経由でデータをSelector AIに送ることができるようになります。
Remote Engineを利用する場合は以下のデータを送ることができます。
この中でSyslogとSNMP Polling、SNMP Trapの機能を利用し、Selector AIに送る構成としました。
- Syslog
- SNMP Polling/SNMP Trap/Streaming Telemetry
- Connections to local Rest API endpoints
- Webhooks
- NetFlow
- Kafka
- Synthetics Testing
- SSH
Remote Engineから直接SNMP Pollingを行ったり、Syslogを直接受信することができれば特に問題になりません。
しかし今回の検証では稼働中のシステムに対して途中からSelector AIを追加することを想定し、「Zabbixのみ監視通信が許可されている状態」を前提として検証を行ったため、以下図のようにデータの再転送等を考慮する必要がありました。
設定が終わり、データ収集が開始されると自動的に対象ホスト、ログの種類が選別され格納されていました。
検証ステップ３：学習フェーズ
紹介した構成でSelector AIに１か月ほどシステムの稼働ログを学習させました。人為的に障害を発生させることはせず、自然な運用状態を学習させていましたが、運よく(?)一部機器に障害が発生し、障害時のデータも取得することができました。
検証ステップ4：エスカレーション判断の学習
エスカレーション判断を行うには、収集したログと、どの情報が重要度の高いアラート(エスカレーションが必要なアラート)であるか、ということを学習させる必要があります。
ログの流れからAIが自動的に判断する場合もありますが、「このログが出た場合は異常である」など、最初は人間の介入が必要になります。Selector AI社協力の元、判断基準(例：プライオリティ1~5)を設定して学習させることで、アラートがSlackへ通知されるようになりました。
中間状況
まだまだ学習途中ですが、Selector AIが判断したプライオリティに従い出力されており、通知動作が行えている事が確認できました。 以下Slackに届いたSNMP通信に異常を検知した際に出力されたアラートです。
上記アラートをみると3台のNetwork機器からSNMP通信が一時的にDownしていたことが分かります。
またSelector AIのUIではその３台の状況が可視化されており、CPU、Memory等はグリーン表示＝問題ない、SNMPのみレッド＝問題あり、ということも分かります。
今後の検証予定
今後は、障害ポイントのさらなる学習・精度向上を目指していきます。正しい構成情報を学習させないとアラート内容を誤認する場合があるため、学習させるデータの正確性向上とAIの継続的教育が課題と考えています。
また、Slackとの連携は実現済みですが、オンコール(アラートエスカレーション)管理ができるSquadcastとの連携はこれから着手予定です。これが実現できると、Tier1 (アラート検知・アラート受付)をAI化し、AIから電話にてエスカレーションを行うことができるようになり、保守・運用業務のさらなる効率化につながります。
Selector AIはIT運用の現場に新たな可能性をもたらすAI Opsプラットフォームとして、今後ますます注目されていくと予想できます。引き続きアップデートや検証結果を発信していく予定ですので、ご期待ください！
