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またはNOT計算)。
時間ルール: 即時実行 (アラーム受信直後に障害インスタンスを生成)、固定時間ウィンドウの待機 (最初のアラームの開始後の一定期間内にアラームの障害インスタンスを強制的に集約)、待機を含むスライド時間ウィンドウ(最後のアラームが開始されてから一定期間内のアラーム強制集約障害インスタンス);
• ロケーション ルール: 同じマシン、同じデプロイメント ユニット、同じ物理サブシステム、および範囲内の条件を満たすアラームが含まれます。指定された範囲が 1 つの障害インスタンスに集約されます。

#3) 指定された分析デシジョン ツリーを関連付けて、分析計画を決定します。

2. 障害分析

障害分析は、関連データの表示、トポロジ データの表示、分析デシジョン ツリーに基づいています。障害は知識ベースの検索などのさまざまな側面で分析および表示され、運用および保守の専門家が障害の根本原因を迅速に特定して障害に対処できるようにデータ サポートを提供します。分析決定木は性質と関連付けることができます。

関連情報の表示:

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

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

3) 変更分析: 過去 48 時間のアラームオブジェクトに対応するシステムの作業指示記録を変更し、変更分析を実施します;

4) ログ分析: 指定されたパスの適用アラームオブジェクトとその周囲のオブジェクトのログやシステムログを解析して表示します。

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

トポロジ構造の表示:

# 物理サブシステムを次元として、システム全体に関わる運用および保守の対象を考慮します。ツリー トポロジ構造で整理されて表示されると同時に、アラームが発生したノードは赤色でマークされ、運用および保守の専門家に警告します。

# 具体的な例は次のとおりです。

写真

分析デシジョン ツリー:

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

運用保守の専門家は、データ分析の順序や判断基準をあらかじめ設定し、運用保守の経験を​​デジタルモデルの形で分析デシジョンツリーに落とし込むことができます。 、プラットフォームは、事前に設定された分析決定ツリーに従って関連データを分析および判断し、最終的に結果を提供します。

分析デシジョン ツリーの最後のリーフ ノードは廃棄に関連付けることができ、障害の「特定、分析、廃棄」というライフ サイクル全体の自動操作を保証します。

#具体的な例は次のとおりです。

#画像

#ナレッジ ベース検索:

データセンターは、運用保守ビッグデータプラットフォーム上のデータを基にナレッジベースシステムを構築し、主に緊急計画、インシデントチケット処理記録、運用保守専門家の経験概要などのテキストデータを収集します。 。

障害が発生すると、障害キーワードを使用してナレッジ ベースを検索 (文字列照合) し、対応するテキストの知識が専門家の経験として返されます。 AI のエンパワーメントに関する章では、単純な文字列マッチングだけでなく、関連検索にテキスト分析を使用することについて説明します。

#3. 障害処理

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

1) 廃棄オーケストレーション: 廃棄オーケストレーションは、一連の廃棄操作を有機的に組み合わせたものです。一部の廃棄では、操作オブジェクトとメンテナンス オブジェクトを分離して再起動する必要があるため、スクリプトを編集します。プロセス内の破棄操作。これにより、いくつかの操作スクリプトが所定の順序で特定のインスタンス マシンに配信され、実行されます。

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

障害処理は主に運用および保守の専門家に基づいており、経験や緊急計画の文書がデジタル的にモデルに組み込まれます。

障害処理が完了すると、その後の検討と分析のために、処理の関連記録がプロセスに従って記録されます。

4. AI のエンパワーメント

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

#1. 自動モデリング

第 3-1 章の障害モデルの定義を確認すると、次のことがわかりました。アラーム ルール、時間ルール、スペース ルールを決定する限り、分析デシジョン ツリーを同時に決定して障害モデルを構築できます。時間ルールとスペース ルールは、最も一般的な即時実行と同じマシンをデフォルトにすることができます。また、分析デシジョン ツリーでは最も従来のヘルス チェックを使用できます。

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

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

図

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

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

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

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

2) モデリングは運用および保守の専門家の経験に依存せず、アラームの内容を通じて直接モデル化できます;

3) 過去のすべてのアラームを網羅し、新たな種類のアラームにもリアルタイムに対応可能;

4) 運用保守の専門家による膨大なモデル設定作業が不要となり、省力化; 運用および保守の専門家は、最終的な手動確認のみを行う必要があるため、結果を確実にしながら効率が向上します。

一般的に、計算対象の文書に頻繁に出現するが、計算の対象となる単語は、大量の文書に出現する確率が高く、キーワードとなる確率が高いため、アラーム メモリの一部が処理に使用されます。結果は次のとおりです。画像

##上記のアルゴリズムを使用し、アラーム内容の一部を計算に使用すると、データの効果は次のようになります。

##図

#図

2. 自動クラスタリングの失敗

#Google が BERT (Bidirectional Encoder Representations from Transformers) をリリースして以来、さまざまなテキスト タスクでランキングのトップに立っており、非常に良い結果が得られているため、主にテキストの類似性を計算するために使用されています。アラームの内容と障害の説明の間の類似性を計算します。

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

#図

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

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

2) アラーム情報を削除し、不要な文字を削除します。3) BERT モデルを使用して、アラームのテキスト コンテンツを分析します。サマリーと全障害 クラスタリングした情報をテキスト類似度計算し、同様の結果を得る（閾値を超えているか否かで類似判定）;

4) 類似していればアラームを割り当てるこの障害クラスタ。;

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

6) ステップ 4 と 5 の結果は次のように更新されます。リスト内の障害クラスタ情報;

7) ステップ 2 の次のアラーム データを処理します。

このアルゴリズムでは、アラームをさまざまなタイプの障害に関連付けることができます。既製のタイプの障害がない場合は、独自のタイプを作成できます。さまざまなタイプの障害に対して異なる分類が可能です。故障の種類、分析方法。

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

1) 履歴およびリアルタイムのアラーム データを通じて、監視なしで障害分類が自動的に実行されるため、障害分類を確立する必要がありません。障害モデル、人的資源の節約;

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

##3) アラームは自動的に生成されるか、障害に関連付けられます。これらは、対応する緊急計画とさらに関連付けられ、障害分析計画と治療方法を取得できます。

#3. 分析計画を自動的に生成する

第 3-2 章の障害分析、障害の分析を確認してください。主に、障害ノードとその周囲のノードの情報を表示することに重点が置かれており、分析デシジョン ツリーの設定では、より手動での設定も必要になります。

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

民営化された展開の問題を考慮すると、大規模言語モデルとして ChatGLM2、llama2 などを検討できます。特定の実装段階では、ニーズとハードウェア レベルに応じてさまざまな大規模言語モデルを選択できます。この記事の計画説明では、大規模な言語モデルを表すために一律に LLM を使用します。その違いに注意してください。

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

写真

##障害が特定された後、対応するリアルタイム アラームと表示関連データが取得され、緊急計画データと組み合わされて、プロンプトの組み合わせが形成されます。 LLM の大規模言語モデルは質問をします。

同時に、緊急計画と過去のアラーム データがバッチでフェス ベクター データベースに保存されます。各バッチのテキストの量は、LLM トークンの制限を超えません。プロンプトの組み合わせのプロンプト単語が超過 LLM ラージ言語モデルを使用する場合、最も類似したベクトルを持つテキストを取得するために、プロンプトの組み合わせのプロンプト単語が faiss ベクトル データベースにクエリされます。トークンの長さの制限を超えないこれらのテキストは、次のようにクエリされます。 LLM であり、返される結果は障害分析計画 (テキスト形式) です。

#具体的な効果については、以下の写真を参照してください:

写真

4. 緊急時計画の検索

業界で必要なマニュアルとして、緊急時計画は、すべての障害の該当する分析を包括的に記録します。システム、すべての運用および保守対象、および廃棄手順は非常に優れたテキスト データであり、緊急時計画の内容はこのシステムのさまざまな場所で使用されます。したがって、緊急計画の検索機能を提供する必要があり、ナレッジベースシステムは緊急計画の検索基盤として利用することができる。

文字列マッチングによるテキスト検索、テキスト解析後のキーワード検索、意味レベルのベクトル類似性検索が可能で、システムが必要とする対応する緊急計画テキストを取得します。

上記の検索方法はすべて、上記の技術的手段を使用して処理できるため、ここでは再度説明しません。

5. 結論

イベントインテリジェント分析システムは、運用保守の専門家による各システムの運用保守を支援するためのシリーズを提供しています。モデリング手法により、運用保守の専門家は運用保守の経験を​​デジタルモデルに集約でき、データ量（障害サンプルデータや運用保守関連データ）が増大する場合、一部のAIアルゴリズムを使用することで作業負荷を軽減できます。運用・保守専門家の作業負荷を軽減し、運用・保守専門家の分析的意思決定を支援し、最終的には運用・保守専門家の介入なしに運用・保守を自動化できる状態、すなわち「自己発見・自動化」を実現したいと考えています。故障に対しては「メンテナンスフリー」。

以上がAIを活用したイベント知的分析システムの実践的構築と応用の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。