NetEase Games AIOps実践：異常検知の最適化戦略とプラットフォーム構築

この共有では主に以下の点が紹介されます。

• AIOps ロードマップ
• 異常検出
• プラットフォーム構築
• インテリジェントな障害管理

AIOps（インテリジェントな運用と保守）は、2​​016 年にガートナーが提案した概念です。当初の定義は「アルゴリズムIT運用」であり、機械学習、データウェアハウス、ビッグデータなどの技術的手段を通じて人工知能を運用保守分野に適用し、運用保守によって生成されたデータ（ログ、監視、アプリケーションなど）に基づいて分析と意思決定を行い、最適な運用保守戦略を導き出すことを指します。技術が成熟するにつれて、最終的には無人運用保守へと移行します。

1. AIOps ロードマップ

1. AIOps機能ステージ

ローマは一日にして成らず。以前公開されたエンタープライズレベルの AIOps 実装に関するホワイトペーパーによると、AIOps の開発には主に次の 5 つの段階があり、これは現在の実践で実際に検証されています。

• AI 機能の適用を試み始めましたが、比較的成熟した単一ポイントのアプリケーションはまだありません。
• 単一シナリオ向けのAI運用・保守機能を備えており、社内利用のための学習教材を初期段階で形成できます。
• 複数の単一シナリオ AI 運用保守モジュールが直列に接続されたプロセスベースの AI 運用保守機能を備えており、外部に信頼性の高い運用保守 AI 学習教材を提供できます。
• 主な運用・保守シナリオでは、プロセスベースの介入不要の AI 運用・保守機能を実現し、外部に信頼性の高い AIOps サービスを提供できます。
• コア AI により、コスト、品質、効率を簡単に調整して、さまざまなビジネス ライフサイクルにおける 3 つの側面のさまざまな指標要件を満たすことができ、複数の目標またはオンデマンドの最適化の下での最適化を実現できます。

NetEase Gamesのインテリジェント運用保守チームは、2018年にアルゴリズムの研究と具体的な実装シナリオの選択を開始しました。その後、オンラインユーザー数、異常検出、ログ異常検出の観点からシングルポイントアプリケーションでのブレークスルーを試み、顕著な成果を達成しました。現在、村に入った後の障害発見と自己修復の目的は、さまざまな次元の運用保守情報とアラーム情報を直列に接続することで達成され、複数の単一シーンAI運用保守モジュールを直列に接続するプロセスベースのAI運用保守機能を実現しています。

ここでの学習教材は、南京大学の周志華教授が独自に作成したAI運用保守コンポーネントを指し、モデル+仕様を参照し、再利用性、進化性、理解性に優れています。

AIOpsフェーズ

2. 人員構成

Devops と比較すると、AIOps の人員構成は確実に変化しています。最も大きな変化は、アルゴリズム エンジニアの役割が追加されたことです。チームによっては、アルゴリズム開発エンジニア、つまりアルゴリズムとプラットフォーム開発の両方の能力を持つエンジニアと呼ぶことを好みます。もちろん、アルゴリズム エンジニアが優れたエンジニアリング能力を持っている場合、これはチーム全体の開発に間違いなくプラスの影響を与えます。しかし、残念ながら、チーム内のすべてのアルゴリズム エンジニアに優れたエンジニアリング能力を要求するのは、実際にはかなり困難です。特に人材を採用する場合、アルゴリズムとエンジニアリングの間にはまだ一定のギャップがあることに気付くでしょう。

そのため、私たちのチームは、ユーザーとも言える運用・保守エンジニアが、アルゴリズムエンジニアに具体的なビジネスシナリオや要件を提供し、潜在的なインテリジェントシナリオを探索し、プラットフォームR＆Dプロジェクトにプラットフォーム開発のシナリオ要件を提供するという3つの役割で構成されています。プラットフォーム研究開発エンジニアとアルゴリズムエンジニアもいます。1 人は主にエンジニアリングとプラットフォーム構築を担当し、アルゴリズムについても少し知っていますが、主な責任はエンジニアリング開発に傾いています。アルゴリズムエンジニアは、業務に応じたアルゴリズムの研究、開発、最適化に注力し、専門性を高める体制を整えています。

実際の協力においては、この協力形態により事業展開の効率が大幅に向上しましたが、一定の技術的盲点も存在します。

3. 事業分野

1) 時系列異常検出

時系列データとは、時系列順に並べられ、時間の経過とともに変化し、相互に関連する一連のデータです。運用および保守シナリオの特殊性により、運用および保守データは本質的に時系列と密接に関連しています。 AIOps が提供する時系列インテリジェント分析の機能は、履歴データの変化する傾向と固有の特性を研究することで、人間の介入なしに時系列予測、異常データ監視、その他のインテリジェント分析機能を実現することです。

2) 障害箇所の特定と根本原因の分析

マイクロサービスの発展により、ビジネスネットワーキングはより複雑になり、問題の境界設定や場所の分析が特に困難になりました。障害の特定と診断は、運用および保守シナリオにおけるインテリジェント分析の中核部分です。 AIOps が提供する障害識別および根本原因特定機能は、障害データと手動の経験を組み合わせてデータ マイニングを行うことで、障害の特徴を自動的に抽出し、障害を特定します。

3) テキスト処理と分析

テキスト処理の余地はたっぷりあります。 AIOps は、情報抽出、意味解析、インテリジェント検索、対話システムなどの領域をカバーする幅広いテキスト処理および分析機能を提供し、製品戦略に直接適用できる NLP 技術機能を提供します。

4) クラスタリングと類似性分析

物理的または抽象的なオブジェクトのコレクションを類似したオブジェクトのクラスターに分割するプロセスをクラスタリングと呼びます。クラスタリングは、特定の類似性に基づいた抽象化のプロセスです。 AIOps が提供するクラスタリングおよび類似性分析サービスでは、統計機能と組み合わせた教師ありまたは教師なしアルゴリズムを使用して、特定の形式のデータに対して類似性クラスタリングを実行し、データの識別と処理のコストを大幅に削減できます。

2. 異常検出

1. 問題

従来の静的しきい値は、現在、変化するビジネス シナリオに適応することが困難です。しきい値が高すぎるとアラームが見逃され、しきい値が低すぎるとアラーム ストームがトリガーされます。時系列指標の異常検出は従来の静的しきい値とは異なり、ユーザーが手動で設定する必要はありません。 AIOps は、機械学習アルゴリズムと手動のラベル付け結果を組み合わせて、しきい値を自動的に学習し、パラメータを自動的に調整し、アラームの精度とリコール率を向上させます。異常検出は、企業の多様なニーズに適応し、より多くの異常タイプをカバーできるようになります。

2. 適用可能なシナリオ

1) 異常閾値を定義することは難しい

• 正常データと異常データを明確に定義することは難しく、明らかな閾値境界は存在しません。
• 期間によってしきい値は異なります。
• 事前に定義されたしきい値に達しない異常な変異を含むデータがいくつかあります。
• 識別する必要がある異常は、履歴データの特定のパフォーマンス パターンとは異なり、しきい値を設定することによって検出できない異常です。

2) 手動設定コストが高い

• 異なる曲線は異なるしきい値で構成されており、曲線の数が多い場合は手動での構成コストが非常に高くなります。
• ビジネスが変化すると、事前定義されたしきい値もそれに応じて変更する必要があり、その結果、運用および保守コストが高くなります。
• データ自体にノイズが含まれており、ノイズと異常データの区別が難しく、検出に多くの人手が必要となります。

異常検出に関しては、実際にインターネット上の多くのドキュメントや書籍で、一般的に使用されているアルゴリズムやツールが提供されています。私たちもこの点でこれらのアルゴリズムやツールを適用しています。もちろん、対応するアルゴリズムの最適化や調整も数多く行っています。ここでは、この点に関する私たちのチームの考えや戦略をいくつか紹介します。

モデルがオンラインの場合、統計 + ルールの教師なしソリューションを選択します。主な利点は次のとおりです。

• 教師なし、データラベル付けコストなし
• 統計+ルールアプローチは解釈可能性が非常に高い
• モデル予測のレイテンシが低い
• 曲線の時間粒度による影響が少ない

3) 異常なバリ

グリッチ異常は、ある瞬間に KPI 曲線に突然現れる、周期性のない局所最大グリッチとして現れます。 KPI の振幅のみを閾値判定に用いると、KPI 値自体にも一定の傾向がある場合があり、外れ値を正確に見つけられない場合が多くあります。一次差分を使用すると、トレンド項を効果的に除去できるため、異常を明らかにすることができます。さらに、SR アルゴリズムは、このタイプの異常に対しても優れた検出効果を発揮します。

4) 異常な上昇と下降

急激な上昇と下降の異常は、KPI 曲線が異常な上昇または下降を示し、すぐに回復せず、KPI 値が異常値付近に留まり続ける場合に発生します。これは永続的な異常です。オンライン ユーザー数や CPU 使用率など、多くの企業がこの種の異常を非常に懸念しています。このような異常は、異常点の両端のウィンドウの平均シフトによって識別できます。

ただし、KPI 自体には傾向とサイクルがあるため、通常ポイントの両端のウィンドウにも平均シフトがあります。このとき、STL を使用して時系列を分解し、残差部分の平均シフトを計算することで、トレンド項や季節項によって発生する誤検知を減らすことができます。さらに、大きなグリッチによって平均値のシフトが発生し、誤報につながる可能性も高くなります。したがって、2 つのエンド ウィンドウの平均を計算する前に、ESD テストを使用して外れ値を除去し、大きなバリが平均に与える影響を除去し、モデルの誤検出を減らすことができます。

5) 異常な周波数変化

周波数異常は連続バー異常として現れます。このとき、曲線の振動が増加しますが、これも連続異常です。このタイプの曲線は比較的まれですが、ビジネスがより懸念する異常なタイプでもあります。

ウィンドウ内の一次差分異常カウント値を使用して判断できます。

3. 異常判定方法

各種検知モデルを設計した後、モデルの出力に基づいて異常判定を行い、現在のポイントが異常であるかどうかを判断する必要があります。一時的な異常と持続的な異常を判断するには、異なる方法が必要です。

1) 配布方法

データ分布の想定に基づいて、瞬間的な異常を判定するのに適した閾値を設定します。瞬間的な異常を判断するために、3 シグマとボックス プロットを使用します。テストの結果、ほとんどの曲線で結果が比較的堅牢であることがわかりました。

2) 事業所数閾値方式

ビジネスニーズに応じて、継続的な異常を判断するためのカウントしきい値を設定します。連続した異常に対してカウント閾値を設定し、異常数が閾値を超えるとアラームが発せられます。たとえば、ロバスト回帰では、実際の曲線と予測曲線の差の異常数をカウントできます。たとえば、ウィンドウ内の 1 次差の異常数は、カウントしきい値によって直接判断できます。

さらに、異なるモデルの出力を融合し、より堅牢な判定結果を得るために、分布法と業務カウント閾値法を線形変換により0～1のスコアに変換することができます。このとき、スコアの重み付けによってモデルの融合を得ることができます。融合スコアが0.5を超えると異常となり、異なる曲線でより優れた異常判定効果を維持でき、堅牢性が強くなります。

3. プラットフォームの構築

AIOps 自体も反復的な開発モデルであり、プラットフォーム化のプロセス中にいくつかの問題も発生しました。まず、アルゴリズムとエンジニアリングの境界は比較的曖昧です。アルゴリズム エンジニアはアルゴリズムの開発とチューニングに集中したいと考えており、エンジニアリングにあまり多くの時間を費やしたくありません。もう 1 つの問題は、アルゴリズム パッケージがエンジニアリング プロジェクトと密接に結びついていることです。アルゴリズムの最適化とパラメーターの変更を行うには、バージョンをリリースする際にエンジニアリング プロジェクトの協力が必要です。

アルゴリズムとエンジニアリングをより適切に分離して、迅速なアルゴリズム反復のニーズとエンジニアリング プラットフォーム開発の安定性の要件の両方を満たすことができることを願っています。

また、AIOps で使われるデータは多岐にわたる可能性があることもわかりました。異常検知の場合、基本指標データ、ログデータ、テンプレートデータはすべて異なります。

障害箇所まで拡張するには、ビジネス トポロジやネットワーク トポロジの CMDB データなどの構成関連データも必要になる場合があります。さらに、異常イベントや変更イベントなどのイベント情報データと組み合わせる必要もあります。

1. システムアーキテクチャ設計

上記の問題と目標に基づいて、図に示すように 5 層のシステム アーキテクチャを設計しました。その主な目標は、さまざまなアルゴリズムをオンデマンドでロードし、さまざまな検出プロセスを調整することです。高可用性を確保しながら、統一された方法で管理されながら複数のサービス タイプを提供します。各ビジネスとプロセスは、統合されたプラットフォームを通じて分離され、スケジュールされます。リソースを節約するために、コンピューティング パワーは動的に調整され、サービス全体の運用効率が確保されます。

1) データアクセス層

最下層のデータ アクセス層は、さまざまな監視インジケーター、システム ログ、ビジネス ログ、ビジネス インジケーターのリアルタイム収集を担当します。システムおよびビジネス指標については、当社の監視チームが独自に開発したエージェントを通じてデータを収集できます。このエージェントは通常、各サーバーの初期化時に自動的にインストールおよび構成されます。

2) データレイヤー

上記のデータ アクセス レイヤーによって収集されたデータは、永続化のために HDFS に書き込まれます。同時に、このレイヤーは収集されたデータの前処理、ETL、集計なども担当します。パフォーマンスと可用性を向上させるために、インジケーター データはコールド データとホット データの違いに応じてそれぞれ TSDB と Redis に保存され、検出に使用される履歴データはここから取得されます。

3) サービス層

ここでは、モデルは主にオフラインでトレーニングされ、トレーニングされたモデルは S3 にアップロードされて保存されます。モデルが反復されたり、アルゴリズム戦略が変更されたりすると、アルゴリズム エンジニアはプラットフォーム エンジニアの介入を必要とせずに、フルリンクの開発とテストを独自に完了できます。モデルはプラットフォーム フレームワークから抽出されるため、独立して構成および管理でき、アルゴリズムとエンジニアリング間の結合がさらに低減されます。さらに、新しいビジネス シナリオが導入されると、アルゴリズムとエンジニアは独自にコードを開発し、合意されたインターフェイスを通じてオンラインで起動できます。

4) アプリケーション層

ネットワークサービスのアプリケーション層とは異なり、これはさまざまな SaaS プラットフォームの機能アプリケーションを指します。基本的な運用と保守は、データ層を通じて指標の実際の変動を反映し、データを集約する役割を担っています。現在、当社の監視チームは第 2 レベルのデータ表示を実現しています。 AIOps プラットフォームもこの層に組み込まれています。その主な機能は、リアルタイム ストリーミング、タスク スケジューリングなどを通じて対応するモデルを呼び出すことで、データに対してさまざまなアルゴリズム テストを実行することです。

5) プレゼンテーション層

テスト結果を単一のイベントまたはデータ グラフとして表示するために使用されます。

2. テストプロセスの設計

ここでは主にアプリケーション層検出プラットフォームの内部実装のアイデアを紹介します。全体的なデータフローはこの図に示されています。ユーザーは、当社の運用保守ポータル Web サイトで対応する検出タスクを作成し、その構成を flink ルール データベースに同期して保存します。このとき、エージェントは対応するインジケーター データを収集し、前処理のために flink に送信します。flink は、ルール データベースの構成に従ってデータを事前フィルタリングおよび前処理します。

処理されたデータは、アルゴリズム オーケストレーション モジュールも通過します。このモジュールは主に、以前のユーザー構成と事前に設定されたマッチング ルールに基づいて、検出されたデータにオーケストレーション、タスク、および戦略関連の情報を追加します。このタイプの情報によって、アルゴリズムが使用するモデル、履歴データ、機能、およびその他の情報が決定されます。そして、この情報に基づいてモデルが動的に読み込まれ、呼び出され、結果が出力されます。

アルゴリズムの抽象化として、アルゴリズム モデルは登録によって S3 にアップロードして保存できます。登録後、アルゴリズム モデルは対応するオーケストレーションおよびトレーニング コンポーネントを生成します。プラットフォームとコンポーネントは、アルゴリズムの一意の識別子、インターフェース、および入力クラスと出力クラスを定義することによって相互作用します。プラットフォーム スケジューリング エンジンは、上記の構成に基づいて、検出スケジューリング用の対応するアルゴリズム モデルを動的に読み込みます。

具体的な検出アーキテクチャの実装アイデアを図に示します。まず、アルゴリズム モデルは、サービス内にプラグイン可能なアルゴリズム パッケージとして存在します。各アルゴリズム パッケージには独立したスレッド リソースがあります。Python のクラス ローディング メソッドを使用して、必要に応じてダウンロードおよび更新し、アルゴリズム モデルのホット デプロイメントを実現できます。

フレームワーク自体は、さまざまなバージョンのアルゴリズムの読み込み、アルゴリズムのルーティングと戦略の計算の実行を担当するスケジューリング管理ツールに相当します。同時に、関連するオーケストレーションおよびスケジューリング プロトコルのセットを設計し、エンジニアが独自に定義できる特定のパラメーター構成とオーケストレーション モードを公開して、アルゴリズムとエンジニアリング、ビジネスとプラットフォームの関係をさらに分離しました。

たとえば、一部のビジネス シナリオでは、履歴データの使用が必要になることがよくあります。実際、アルゴリズム エンジニアは履歴データの取得と前処理には関心がありません。このような操作は、通常、プラットフォーム エンジニアに任されています。

プラットフォーム内で履歴データ取得のロジックを抽象化しました。特定のビジネス データの取得と保存は、ビジネス ニーズに基づいてプラットフォーム エンジニアによって記述されます。アルゴリズム呼び出しモジュールは、プロトコルを通じていくつかの重要なパラメーターと構成を取得し、これらの特定のクラスとメソッドを内部で自動的に呼び出してデータを取得し、データを検出のためにモデルに渡します。

実際、履歴データを取得して処理するプロセスでは、履歴データの抽出がボトルネックになることがよくあります。たとえば、アルゴリズムには 7 ～ 8 日分の履歴データが入力として必要になる場合があります。検出数が増えると、TSDB に多大な負担がかかります。さらに、履歴機能を計算するために必要な入力量は変わる可能性があります。ホット データとコールド データ、読み取りと書き込みの分離はすべて解決できます。また、プラットフォーム内に履歴データ メモリ ストレージのセットを保持し、パイプラインとデータ圧縮を通じて履歴データをキャッシュします。同時に、一部の計算機能はメモリに保存され、リアルタイム計算モジュールへの負荷を軽減します。

抽象クラス図の実装方法は次のとおりです。基本クラスは、ストレージ、オーケストレーション、更新などの基本的な操作を提供します。プラットフォーム開発エンジニアは、ビジネス シナリオに基づいてデータを定義し、これらの独立した機能を組み合わせてさまざまなビジネス ニーズに対応します。

ユーザーエクスペリエンスにもいくつか変更を加えました。1つ目は、異常のマーク方法です。多くのプラットフォームでは、イベントと前年比の形式で異常を表示しているのを見てきました。私たちはすでにアラームプラットフォームシステムを持っており、実際に使用してみると、この単一イベントの前年比比較形式はユーザーに誤解を招きやすいことがわかったので、grafnaのような大きな画像形式を使用して異常を表示し、マークしています。

さらに、ユーザーからのフィードバックとラベル付けは非常に重要です。これらはモデルのチューニングを大きく左右し、アルゴリズムの精度を向上させます。ユーザーが怠惰なため、ラベル付けを怠ることがよくあります。当社では、社内メッセージングツールの popo を使用して、検出結果とラベル付けリンクをユーザーに直接送信し、ユーザーの間で良好なラベル付け習慣を育んでいます。

4. インテリジェントな障害管理

ゲームやシステム アーキテクチャがますます複雑になるにつれて、運用保守担当者が受け取るアラーム情報も多様化しています。障害が発生した場合、複雑なアラーム情報により、運用保守担当者はロジックを整理することが困難になり、全体像を見失って、そもそも最も根本的な問題を解決できない場合もあります。プログラマーや SRE とコミュニケーションをとる過程で、障害に直面したときに彼らが主に抱えている問題点が次のとおりであることがわかりました。

• ゲームのアーキテクチャはますます複雑になり、障害が発生した場合のトラブルシューティング プロセスは比較的長くなります。
• 障害が発生すると、多くの場合、複数のアラームがトリガーされますが、これらのアラームは分散しており、特定のルールに従って分類および視覚化されていません。その結果、トラブルシューティング プロセス中に、アラームを手動で並べ替えてフィルタリングする必要があります。
• 現在、障害箇所の特定は手作業による経験に依存しており、再利用が困難です。

ご存知のとおり、ビジネス指標は障害状況を反映する最も直感的な手段であり、ログ記録はアプリケーションの実行状態を記録するための重要なツールです。上記の一般化されたアラーム情報を、詳細を保持しながらクラスタリングによって要約し、アラームが発行された後に、インジケーター、ログ、トレース、変更イベントなどの情報を組み合わせ、障害伝播チェーンを通じてそれらを関連付け、障害の最も可能性の高い原因を見つけることができるようにしたいと考えています。

ビジネス指標は、障害箇所全体のトリガーソースです。ゲーム SLO で重要な指標を選択し、グループディメンションに従って分類しました。 SLO ビジネス指標には多くの不具合があるため、通常の不具合のある教師なしモデルを直接使用すると、多くの誤報が発生します。異常が一定期間上昇または下降し続ける場合にのみ、異常と見なすことができます。したがって、SLO 異常検出モデルでは上昇異常検出を使用します。

リフト異常検出は主に 2 つのモデルで構成されます。1 つは平均シフト モデル、もう 1 つは予測平均シフト モデルです。最終結果は、2 つのモデルの入力と出力を統合します。

1) 平均シフトモデル

• 左側と右側の指定された量の平均の差を計算します。
• 差が一定の閾値より大きいか小さい場合、隆起異常が発生していると考えられます。

2) 平均予測シフトモデル

• まず、左側と右側にそれぞれ指定された数の点を持つ線形回帰を実行し、右側と左側の指定された数の点の値を予測します。
• 次に、右側と左側の真の値からそれを減算します。
• これらの差を平均します。
• 平均値が一定の閾値より大きいか小さい場合、上昇異常が発生していると考えられます。

ビジネス指標が異常になると、障害箇所の特定が開始され、機械指標の異常検出と分類が開始されます。異常スコアを並べ替えることで、異常の最も可能性の高い根本原因が得られます。

• ビジネス指標が異常な場合、現時点から20分以内の全指標に対してグリッチ異常検出を実行し、異常検出スコアを算出します。
• 異常検出スコアに時間減衰係数を掛けて根本原因スコアを算出します。つまり、異常の発生が早いほど、それが根本原因である可能性が高くなります。
• 20 分以内の根本原因スコアの最大値を指標の根本原因スコアとして出力し、マシン名の範囲内でソートします。単一の根本原因のみを考慮するという前提で、最も異常が多いマシンを根本原因マシンとします。指標の異常は根本原因スコアに従ってソートされ、指標の根本原因リストが出力されます。

機械インジケーターの根本原因を分類すると同時に、関連 SaaS の機械インジケーターとアラーム情報もスキャンし、最終的にログの異常検出と分類を組み合わせて根本原因の結果をユーザーに表示します。

質疑応答

Q1: インテリジェントな運用と保守を早期に計画するための適切な方向性と計画の提案は何ですか?

A1: まず、インテリジェントな運用と保守は一夜にして実現できるプロセスではありません。これは長期にわたって進化するシステムとして存在します。その基盤となるのは、依然として運用と保守の自動化、データ収集、分析、監視などの基本的な運用と保守のツールです。計画の初期段階で対処する必要がある問題には、膨大な量のデータの保存、分析、処理、データ ウェアハウスの構築、基本的な監視の実践経験などがあります。多くの場合、優れたデータはモデルよりも価値があります。上記のインフラストラクチャを完了したら、特定のビジネス担当者と協力して、最も懸念される SLO を理解し、この側面に基づいて異常検出を構築できます。モデル選択に関しては、教師ありラベル付けのコストは非常に高いものの、教師ありモデルは教師なしモデルよりもビジネスニーズを満たしやすく、その後の更新や反復において絶対的な利点があります。

Q2: AIOps の基盤となるのは、大量の履歴監視データです。データ収集とモデリングのルールはどのように設計するのでしょうか?

A2: 現在は基本的にPrometheusのアクセス方式を全面的に採用し、これをベースにデータ収集センターを構築しています。主な収集ルールは、コレクターとアダプターのモデルに基づいています。ユーザーはコレクターを介してデータをアップロードし、アダプターはデータを再構成して、対応するメッセージ キューに直接送信し、保存します。データモデルはJSONで統一的に識別され、データ形式はPrometheusのデータ形式を採用しています。

Q3: ログ収集ルールについて説明していただけますか?ログ検出の現在の考え方は何ですか?

A3: ユーザーは、カスタム クライアントを通じて関連するログ インジケーターを定義し、自分でデータを収集します。SDK は別のプロセスを開始して、メモリ内のデータを定期的に読み取り、ログ形式に組み立てます。当社のログ チームがデータを収集します。具体的なデータ形式は前の質問と同じです。コンテナ ログを収集する方法は、一般的に次のとおりです。

• コンテナ内のログを収集します。コンテナ プロセスはログを自身で書き込み、エージェントがログを収集します。
• コンテナ外の収集: docker logs api および docker log-dr、ログ収集エージェント、ボリュームのマウント、独自開発エージェント。

当社の現在の日常的な異常検出アルゴリズムは、主にログインテリジェント分類アルゴリズムに依存しています。リアルタイムのログ分類テンプレートを取得した後、3シグマとボックスプロットを使用して、各テンプレートのログ量の履歴データに基づいて異常判定を行い、異常なパターンを発見し、対応する異常をアラームを通じてユーザーに送信する必要があります。

Q4: アラームの収束にはどのようなアイデアがあり、どれがより効果的ですか?

A4: アラームを収束させるには、主にいくつかの方法があります。

• 収束は事前に設定されたルールに基づいて実行されます。たとえば、アラーム A と B が同じマシン/モジュールから発生した場合、AB は収束され、マージされます。
• アラーム時間/アラーム数に基づく収束。たとえば、アラームを組み合わせて 5 分以内に送信します。

上記の 2 つの方法は戦略的なものであり、一部のアラームを収束できますが、アラーム間の相関関係を取得することはできません。

• トポロジの収束に基づきます。アラームはトポロジに基づいて相関され、収束が達成されます。 アラーム間の相関関係を取得できるため、トラブルシューティングに役立ちます。しかし、一般的にトポロジーを取得するのは困難です。
• 関連ルールマイニングに基づく収束。過去のアラーム情報に基づいて、頻繁に発生する同期アラーム ルールがマイニングされ、マージされます。 アラーム間の相関関係は取得できますが、障害箇所はまだ形成されていません。一定のトラブルシューティング効果があり、トポロジに依存しません。
• アラーム知識グラフを構築し、収束を実行します。理想的なアプローチ、最良の結果。しかし、トポロジーや履歴データの蓄積、専門知識が必要であり、実装が困難です。

Q5: インターネット電子商取引アプリケーションの監視に動的しきい値アルゴリズムを選択するにはどうすればよいですか?

A5: 主に教師あり選択と教師なし選択に分けられます。

• 教師あり異常検出ソリューションでは、まず CNN + AutoEncoder モデルを使用して曲線を分類し、次に教師なしモデルを確立してサンプルを採取し、異常なサンプルを検出して、サンプル ライブラリを確立します。そして、経験に基づいて選択された一連の特徴を教師ありモデルのデータ入力として使用します。最後に、統合モデルを使用してデータをトレーニングし、モデルの安定性を確保します。
• 教師なし異常検出ソリューションは、3 シグマ、パーセンタイル分布、ボックス プロットを含む統合モデルを使用して、履歴データ内の複数の特徴分布を計算し、特徴の現在の異常可能性を判断します。次に、さまざまな特徴から計算された異常スコアを比例して組み合わせ、経験に基づいて設定された異常しきい値と比較して、異常を検出します。