AIをベースとしたイベントインテリジェント分析システム構築の実践

1. 背景

現在、仮想化やクラウドコンピューティングなどの新技術の普及により、企業のデータセンター内のITインフラストラクチャの規模は飛躍的に拡大し、コンピュータのハードウェアとソフトウェアの規模も拡大し続け、それに伴うコンピュータの障害も頻繁に発生しています。最前線の運用保守担当者は、より専門的で強力な運用保守ツールを緊急に必要としています。

データセンターの日常的な運用・保守においては、一般的に、基本監視システムとアプリケーション監視システムを通じて、データセンター内のソフトウェアやハードウェアの障害を発見する仕組みが構築されます。このプロセス中に、さまざまなソフトウェアおよびハードウェアの例外が発生すると、インジケーター項目が事前に設定されたしきい値を超え、アラームがトリガーされ、運用および保守の専門家にトラブルシューティングを通知します。

イベントインテリジェント分析システムは、アラームを障害に変換し、分析して対処するという問題を解決するために設計されたシステムです。

2. 全体的なアーキテクチャ

1. イベントインテリジェント分析システムアーキテクチャ

イベントインテリジェント分析システムは、「障害の特定-障害の分析-障害の処理」という全プロセスの障害処理システムを構築し、運用と保守の専門家の経験をデジタルモデルに沈殿させます。障害が発生すると、障害を自動的に「特定-分析-処理」できるため、MTTR（平均修復時間）が短縮されます。

イベントインテリジェント分析システムは、システムの各モジュールを強化するために AI テクノロジを導入します。運用および保守の専門家が手動で障害モデルを確立しない場合、AI はアラームの障害を自動的に確立し、自動的に分析してから、運用および保守の専門家が障害を分析するのを支援する分析プランを提供します。 AI の活用により、モデリングにおける運用・保守の専門家の作業負荷が軽減され、運用・保守の専門家の経験上の盲点も埋められます。

以下は、イベント インテリジェント分析システムの全体的なアーキテクチャ図です。

写真

青い部分はイベントインテリジェント分析システムの機能モジュールであり、オレンジ色の部分は対応するデータやインターフェースを提供する周辺システムです。

2. 周辺システムとの関係

統合イベント プラットフォーム: アラート システムは、さまざまな監視システム (基本監視、アプリケーション監視、ログ監視) からアラームを収集し、それらを集約して、統一された形式に変換し、Kafka に送信します。イベント インテリジェント分析システムは、Kafka システムからすべてのアラーム データを読み取ります。

自動化プラットフォーム: 運用および保守の専門家は、障害を処理する方法として、自動化プラットフォーム上にいくつかの新しいオーケストレーションとスクリプトを事前に作成します。障害分析によって障害の根本原因が見つかった場合、自動化プラットフォーム インターフェイスを呼び出して処理タスクをオーケストレーションして発行することができ、最終的に自動処理の目的を達成します。

CMDB: 障害分析中に、CMDB に保存されているオブジェクト インスタンスの属性と関係を使用して、アラーム インスタンスと廃棄インスタンスを論理的に関連付けることができます。同時に、アラーム オブジェクトを取り巻くオブジェクトに関する情報を表示する場合は、対応する CMDB オブジェクト インスタンス データも関連付ける必要があります。

ITSM: 障害発生時の分析に必要な変更指示書やインシデント指示書などの作業指示書データを提供します。

ビッグデータ プラットフォームの運用と保守: ビッグデータ プラットフォームは、イベント インテリジェント分析プラットフォームが必要なデータをクリーンアップするのに役立つデータ クリーニング ツールを提供し、大量のデータ ストレージの技術サポートを提供します。ビッグデータ プラットフォームは、イベント インテリジェント分析に必要なデータの強固な基盤であり、CMDB オブジェクト データ、ITSM 作業指示データ、監視システム インジケータ データ、アラーム データなど、後続の AI 分析のための分析データも提供します。

3. 機能の詳細説明

1. 障害の特定

障害識別の主な機能は、障害モデルを確立することです。これにより、アラームを障害に変換するためのルールを定義できます。同時に、障害モデルの定義は、障害の簡単な分類でもあります。たとえば、CPU 使用率が高い障害、メモリ使用率が高い障害、ディスク使用率が高い障害、ネットワーク遅延障害などがあります。簡単に言えば、どのアラームを障害に変換できますか? アラームと障害の量的な関係は、1:1 または n:1 のいずれかです。特定の障害が形成されて初めて、その後の分析と処理が便利になります。

アラームのフォーマット:

統合イベント プラットフォームから受信したアラームは標準化され、イベント インテリジェント処理システムに必要な形式に処理されます。一部のフィールドは、構成管理のオブジェクト インスタンス データを検索して補足する必要があります。

障害モデルの定義:

障害シナリオ モデルの定義には、主に基本情報、障害ルール、分析、意思決定機能が含まれ、次のように説明されます。

1) 基本情報には、障害名、対象、障害の種類、障害の説明が含まれます。

2) 障害ルールは次のカテゴリに分類できます。

• アラームマッチングのキーワードルール設定：アラームの JSON フィールドの概要やレベルなどのフィールドを条件として設定したり、論理演算（ルールの AND、OR、NOT 計算）のために複数のルールを設定したりできます。
• 時間ルール: 即時実行 (アラームを受信した直後に障害インスタンスを生成する)、固定時間ウィンドウの待機 (最初のアラームの開始後、一定期間内にアラーム集約障害インスタンスを強制する)、およびスライディング タイム ウィンドウの待機 (最後のアラームの開始後、一定期間内にアラーム集約障害インスタンスを強制する) が含まれます。
• 場所ルール: 指定された範囲内の同じマシン、展開ユニット、または物理サブシステム上の条件を満たすアラームが、障害インスタンスに集約されます。

3) 指定された分析決定ツリーを関連付け、分析計画を決定します。

2. 障害分析

障害分析は、関連データの表示、トポロジカルなデータの表示、分析の決定ツリー、知識ベースの検索など、複数の側面から障害を分析および表示し、運用および保守の専門家にデータ サポートを提供して、障害の根本原因を迅速に特定し、障害に対処できるようにします。決定木の分析は治療に関連付けることができます。

関連情報表示:

1) アラーム分析: 過去 48 時間以内のアラーム オブジェクトに対応する物理サブシステムおよび展開ユニットに関連付けられたその他のソフトウェアおよびハードウェア オブジェクトのアラーム データ。

2) インデックス分析: 障害発生前 2 時間以内のアラーム オブジェクトに対応する物理サブシステムおよび展開ユニットに関連付けられたその他のソフトウェアおよびハードウェア オブジェクトのインデックス データ。

3) 変更分析: 過去 48 時間以内のアラーム オブジェクトに対応するシステムの変更作業指示レコードが変更分析に使用されます。

4) ログ分析：アラームオブジェクトと周辺オブジェクトの指定されたパスのアプリケーションログとシステムログを分析して表示します。

5) リンク解析：トランザクションコードを核として、アラームオブジェクトに関係するトランザクションコードの上流および下流のリンクデータを分析し、表示します。

トポロジ表示:

物理サブシステムを次元として、システム全体に関わる運用保守オブジェクトがツリー状のトポロジ構造で表示され、アラームのあるノードは赤でマークされ、運用保守の専門家に警告を発します。

具体的な例は以下のとおりです。

写真

決定木の分析:

CMDB オブジェクトと関係、アラーム、インジケーター、変更、ログ、リンク、その他のデータに基づいて、カスタマイズ可能な分析決定ツリーに統合されます。

運用保守の専門家は、データ分析の順序と判断基準を事前に設定し、運用保守の経験を​​デジタルモデルの形で分析決定ツリーに蓄積することができます。障害が発生すると、プラットフォームは事前に設定された分析決定ツリーに従って関連データを分析および判断し、最終的に結果を提供します。

分析決定ツリーの最後のリーフ ノードを処分に関連付けることで、障害の「特定 - 分析 - 処分」のライフ サイクル全体の自動操作を確実に実行できます。

具体的な例は以下のとおりです。

写真

ナレッジベース検索:

データセンターは、運用保守ビッグデータプラットフォーム上のデータに基づいて知識ベースシステムを構築し、主に緊急時対応計画、インシデント対応の全プロセス記録、運用保守専門家の経験概要などのテキストデータを収集します。

障害が発生すると、障害のキーワードを使用して知識ベースを検索（文字列マッチング）し、対応するテキスト知識を専門家の経験として返します。 AI エンパワーメントの章では、単純な文字列一致ではなく、テキスト分析を使用して連想検索を実行する方法について説明します。

3. トラブルシューティング

障害処理は主に、事前に定義された処理モデルに従って実行されます。この処理モデルには主に、処理決定のオーケストレーションと処理操作が含まれており、処理タスクのオーケストレーションと実行を実現するには自動化プラットフォームに依存する必要があります。

1) 廃棄オーケストレーション: 廃棄オーケストレーションは、一連の廃棄操作を有機的に組み合わせたものです。廃棄操作によっては、操作と保守の対象を分離してから再起動する必要があるためです。廃棄操作のスクリプトは、プロセス内で編集され、複数の操作スクリプトが所定の順序で特定のインスタンスのマシンに送信され、実行されます。

2) 廃棄操作: スクリプト (シェル、Python) をカプセル化して、インスタンス マシン上で実行できるようにし、廃棄オーケストレーションによって呼び出すこともできるようにします。廃棄操作は、Tomcat の再起動、分離、サーキット ブレーカー、その他のスクリプトなどの廃棄の最小アクションです。

障害処理のほとんどは、運用および保守の専門家の経験、またはデジタル化されてモデルに保存された緊急時計画文書に基づいています。

障害が処理された後、関連する記録はプロセス記録に従って処理され、その後のレビューと分析が行われます。

4. AIエンパワーメント

AIエンパワーメントの目的は、手動設定の作業負荷を最小限に抑え、障害の「識別-分析-処理」の全プロセスにおける運用保守専門家の作業負荷を軽減することです。また、運用保守専門家の経験ではカバーできない部分を補うことができ、初期化段階で過去に発生したアラームの種類を100％カバーできます。全体的な原則は、AI計算を使用して、障害の識別と分析の分野で、自動モデリング、自動集約、自動分析などを通じて、障害モデルと分析計画を構築し、運用保守専門家に参照を提供しますが、最終的な処理は運用保守専門家によって行われることを保証します。アルゴリズムが作業の99％を実行し、手動レビューが作業の最後の1％を確実に実行するようにします。

1. 自動モデリング

第3-1章の障害モデルの定義を振り返ると、アラームルール、時間ルール、空間ルールが決定され、分析決定ツリーが決定されれば、障害モデルを確立できることがわかります。時間ルールと空間ルールは、最も一般的な即時実行と同じマシンにデフォルト設定でき、分析決定ツリーは最も一般的なヘルスチェックを使用できます。

したがって、障害モデルを確立する場合、同じ種類の障害のモデルを確立する際の中心的な問題は、アラームの内容に応じて障害を分類することです。アラームの内容のキーワードを使用して分類を決定し、特定の種類の障害モデルを確立します。すると、自動モデリングの問題は、アラーム キーワードを見つけてそれを使用して障害モデルを構築することになってしまいます。

全体的なロジック図は次のとおりです。

写真

履歴アラームとリアルタイムアラームを 1 つずつ障害モデルに入力します。既存の障害モデルと一致する場合、このアラームの処理は終了します。一致する障害モデルがない場合は、このアラーム内容のキーワードがアルゴリズムによって計算され、このキーワードを使用して障害モデルが構築され、新しく構築された障害モデルが障害モデル リストに追加されます。

運用および保守の専門家は、障害モデルを一般化し、手動確認を通じてオンラインにすることができます。

この自動モデリング方法には、次の利点があります。

1) アラームを処理し、障害モデリングをリアルタイムで実行し、モデルを非常に迅速に更新できます。

2) モデリングは運用・保守の専門家の経験に依存せず、アラーム内容に基づいて直接モデリングできます。

3) 過去のすべてのアラームをカバーし、新しいアラームにリアルタイムで対応できます。

4) 運用保守の専門家は大量のモデル設定作業を行う必要がないため、人手を節約できます。運用保守の専門家は最終的な手動確認のみを行う必要があるため、結果を確実にしながら効率が向上します。

一般的に、計算対象文書に頻繁に出現するが、大量文書に出現する確率が低い単語ほど、キーワードとなる確率が高くなります。アラームメモリの一部を処理した結果は以下のようになります。

写真

上記のアルゴリズムといくつかのアラーム内容を使用して計算すると、取得されるデータは次のようになります。

写真

写真

2. 障害の自動クラスタリング

Google が BERT (Bidirectional Encoder Representations from Transformers) をリリースして以来、さまざまなテキストタスクで 1 位にランクされ、非常に優れた結果を達成しています。そのため、テキストの類似度の計算に使用され、主にアラームの内容と障害の説明の類似度を計算します。

それでは、クラスタリング アルゴリズムを構築しましょう。具体的なプロセス図は次のとおりです。

写真

具体的な手順は次のとおりです。

1) 必要に応じて、障害クラスタリングのアンカー方向として障害の説明を手動で設定できます。この手順は必須ではないため、ない場合はスキップしてください。

2) 警告情報を消去し、不要な文字を削除します。

3) BERTモデルを使用して、アラームサマリーテキストコンテンツとすべての障害クラスター情報間のテキスト類似度を計算し、類似度結果を取得します（類似しているかどうかを判断するためにしきい値を超えるかどうかを判断します）。

4) 類似している場合、アラームはこの障害クラスターに割り当てられます。

5) 距離値が閾値を超えない場合、このアラームを新しい障害クラスターとして設定します。

6) 手順 4 と 5 の結果が障害クラスタリング情報リストに更新されます。

7) 手順 2 からの次のアラーム データを処理します。

このアルゴリズムは、アラームをさまざまなタイプの障害に分類できます。 既成の障害タイプがない場合は、タイプが作成されます。 さまざまな障害タイプの分類には、さまざまな分析方法を使用できます。

このアルゴリズムの利点は次のとおりです。

1) 履歴データとリアルタイムのアラームデータにより、監視なしで障害分類が自動的に実行され、障害モデルを確立する必要がないため、人手を節約できます。

2) リアルタイムアラームの場合、障害クラスタリングプロセスにより、定期的にモデルを計算して更新する必要なく、リアルタイムのオンライン更新が保証されます。

3) アラームは自動的に生成されるか、障害に関連付けられ、対応する緊急計画にさらに関連付けられ、障害分析計画と処理方法が得られます。

3. 分析計画を自動生成

第3章2 障害分析を振り返ると、障害分析は障害ノードと周辺ノードの情報の表示が中心であり、分析決定木の設定にも多くの手動設定が必要であることがわかります。

AI エンパワーメント後は、緊急計画、アラームの詳細、障害分析の表示情報をプロンプトとして使用することを検討し、優れた結果を持つ既存の大規模言語モデルを使用して、障害分析ソリューションを自動的に提供します。

プライベート展開の問題を考慮すると、ChatGLM2 や llama2 などの大規模言語モデルを検討できます。具体的な実装段階では、ニーズやハードウェア レベルに応じて、さまざまな大規模言語モデルを選択できます。この記事のソリューションの説明では、大規模言語モデルを表すために LLM を一律に使用しています。読者は、この区別に注意することをお勧めします。

主なプロセス図は次のとおりです。

写真

障害識別後、対応するリアルタイムアラームと関連表示データを取得し、緊急計画データと組み合わせてプロンプトの組み合わせを形成します。プロンプトワードは、LLM大規模言語モデルが質問するときに、より良い出力効果を得るために使用されます。

同時に、緊急計画と履歴アラームデータは、faiss ベクトル データベースにバッチで保存され、各バッチのテキスト量は LLM のトークン制限を超えません。プロンプトの組み合わせプロンプト語が LLM 大規模言語モデルを超える場合、プロンプトの組み合わせプロンプト語は faiss ベクトル データベースで照会され、最も類似したベクトルを持つテキストが取得されます。トークンの長さ制限を超えないこれらのテキストは LLM で照会され、返されるのは障害分析計画 (テキスト形式) です。

具体的な効果については以下の図を参照してください。

写真

4. 緊急計画の検索

緊急時対応計画書は、業界で必要なマニュアルとして、すべてのシステムとすべての運用保守対象に対応する障害の分析と対処手順を包括的に記録しており、非常に信頼できるテキストデータです。緊急時対応計画書の内容は、このシステムのさまざまな場所で使用されます。そのため、緊急時計画の検索機能を備える必要があり、知識ベースシステムは緊急時計画の検索ベースとして使用することができます。

文字列マッチングに基づくテキスト検索、テキスト分析後のキーワード検索、意味レベルのベクトル類似性検索を提供できます。いずれの方法も、システムに必要な緊急計画テキストを取得するように設計されています。

上記の検索方法は、前回の記事で説明した技術的手段を使用して処理できますが、ここでは詳しく説明しません。

V. 結論

イベントインテリジェント分析システムは、運用保守の専門家がさまざまなシステムを運用および保守するのを支援するために設計されています。そのため、運用保守の専門家が運用保守の経験を​​デジタルモデルに蓄積できるように、一連のモデリング方法を提供しています。データ量（障害サンプルデータと運用保守関連データ）がますます大きくなると、いくつかのAIアルゴリズムを使用することで、運用保守の専門家の作業負荷を軽減し、分析の決定を支援することができます。最終的には、運用保守の専門家が介入することなく、障害の「自己発見とメンテナンスフリー」という自動運用と保守の状態を実現したいと考えています。