Simple Log Service のインテリジェント異常分析アプリケーションは、モデルのトレーニングとリアルタイム検査の機能を提供します。これらの機能は、ログやメトリックなどのデータの自動化された、インテリジェントで適応性のあるモデル トレーニングと異常検出をサポートします。このトピックでは、インテリジェント検査機能の背景情報、ワークフロー、機能、用語、スケジューリング、および使用シナリオについて説明します。また、この機能の使用方法に関する推奨事項も提供します。
Simple Log Service のインテリジェント異常分析アプリケーションは段階的に廃止され、2025 年 7 月 15 日 (UTC + 08:00) には利用できなくなります。
影響範囲
インテリジェント検査、テキスト分析、時系列予測は利用できなくなります。
機能の置き換え
上記の機能は、Simple Log Service の 機械学習構文、スケジュール済み SQL、および ダッシュボード 機能で完全に置き換えることができます。機能関連の設定を構成するためのドキュメントが提供されます。
背景情報
ログやメトリックなどの時系列データは、時間の経過とともに蓄積されます。たとえば、サービスで 1 日あたり 1,000 万件のデータ エントリが生成される場合、そのサービスでは年間合計 36 億件のデータ エントリが蓄積されます。決定論的なルールを使用してデータ エントリを検査する場合、次の問題が発生する可能性があります。
効率の低下: 異常を特定するには、ビジネス要件に基づいてさまざまな検査ルールを手動で構成する必要があります。
適時性の低下: ほとんどの時系列データは時間に敏感です。障害や変更は、メトリックが表示されるパターンに影響を与えます。特定のルールに基づいて現時点で特定された異常は、後で正常と見なされる場合があります。
複雑な構成: 時系列データにはさまざまな形式があります。たとえば、時系列データは、スパイク状の変化、転換点のような変化、および周期的変化を示すことができます。異なるデータ型の時系列データは、異なるしきい値範囲を持つことができます。時系列データの異常を特定するために使用される検査ルールを構成するには、多くの時間を費やす必要がある場合があります。
精度の低下: データ ストリームはビジネス モデルによって異なります。決定論的な検査ルールでは、誤検知や偽陰性が多数発生する可能性があります。ユーザーは、さまざまなシナリオで異常に対する許容度が異なります。異常のトラブルシューティングを行う場合、多くの正確なアラートは問題の特定に役立ちます。アラートを処理する場合、少数の重要なアラートは処理効率の向上に役立ちます。
これらの問題を解決するために、Simple Log Service はインテリジェント検査機能を提供します。この機能は、Alibaba Cloud の独自の AI アルゴリズムと統合されており、ログやメトリックなどのストリーミング データを集計、検査、およびアラートを生成します。この機能を有効にした後、検査するエンティティとメトリックのみを指定する必要があります。検査ルールを構成する必要はありません。この機能は、異常を自動的に識別し、ビジネスの変化に適応し、詳細なアラートを生成できます。
しくみ
Simple Log Service は、SQL 文を使用してメトリックを構築および集計し、スケジューリング ルールに基づいて一定の間隔でデータをアルゴリズム モデルに取り込み、検査結果をイベント形式で宛先ログストア (internal-ml-log) に書き込み、異常のアラート通知を送信します。次の図はワークフローを示しています。
機能
次の表に、インテリジェント検査機能の機能を示します。
機能 | 説明 |
メトリックの構成 | SQL 文またはクエリ分析文を構成して、ログ データをメトリックに変換し、タスクを作成できます。 |
定期的なデータ分析 | 検査するエンティティとメトリックに基づいてデータ機能を構成できます。インテリジェント検査インスタンスが作成されると、インスタンスは新しいエンティティを自動的に検出し、エンティティのデータを定期的に収集して関連するアルゴリズム モデルに取り込み、インテリジェントにデータを分析します。インテリジェント検査インスタンスがデータを収集して取り込む間隔は、秒単位まで正確にすることができます。 |
パラメーターの構成とアルゴリズム モデルによって生成された結果のプレビュー | アルゴリズム モデルのパラメーターを構成した後、アルゴリズム モデルによって生成された結果をプレビューできます。また、各メトリックの時系列曲線と異常スコア曲線を表示することもできます。インテリジェント検査機能は、データの機能に基づいてアルゴリズム モデルのパラメーターを構成するのに役立ちます。 |
複数の方法によるデータ エクスポート | 検査結果は、指定した宛先ログストアに保存されます。異常情報は、アラート通知によって送信されます。 |
用語
次の表に、インテリジェント検査機能に関連する用語を示します。
用語 | 説明 |
タスク | インテリジェント検査タスクには、データ機能、モデル パラメーター、アラート ポリシーなどの情報が含まれます。 |
インスタンス | インテリジェント検査タスクは、タスクの構成に基づいてインスタンスを作成します。インスタンスは、タスクの構成に基づいて、データをプルし、アルゴリズム モデルを実行し、検査結果を一定の間隔で配信します。
|
インスタンス ID | 各インテリジェント検査インスタンスは、一意の ID によって識別されます。 |
作成時刻 | 各インスタンスは特定の時点で作成されます。ほとんどの場合、インスタンスは指定したスケジューリング ルールに基づいて作成されます。履歴データを処理する必要がある場合、またはレイテンシが存在してオフセットする必要がある場合は、インスタンスがすぐに作成されます。 |
開始時刻 | 各インテリジェント検査インスタンスは、特定の時点で実行を開始します。ジョブが再試行される場合、開始時刻はジョブの最後のインスタンスが実行を開始した時刻です。 |
終了時刻 | 各インテリジェント検査インスタンスは、特定の時点で実行を停止します。インスタンスが属するジョブが再試行される場合、終了時刻はインスタンスが実行を停止した最新の 時刻です。 |
ステータス | 各インテリジェント検査インスタンスは、特定の時点で特定の状態にあります。有効な値:
|
データ機能 | データ機能には、次の項目が含まれます。
|
アルゴリズム構成 | アルゴリズムが異なれば構成項目も異なります。各アルゴリズムの構成項目については、「SQL 文を使用してメトリックを集計することにより、リアルタイムで異常を検出する」をご参照ください。 |
検査イベント | 各検査イベントには、次の項目が含まれます。
|
スケジューリングと使用シナリオ
次の表に、インテリジェント検査タスクのスケジューリングとシナリオを示します。
シナリオ | 説明 |
過去の時点でインテリジェント検査タスクを開始する | 現在の時点でインテリジェント検査タスクを作成した後、タスクはタスク ルールに基づいて履歴データを処理します。アルゴリズム モデルは履歴データをすばやく消費し、モデルをトレーニングし、徐々に現在の時刻に追いつきます。タスクの作成時刻またはモデル学習の終了時刻に達すると、検査イベントが生成されます。 |
インテリジェント検査ジョブのスケジューリング ルールを変更する | ジョブのスケジューリング ルールを変更した後、ジョブは新しいスケジューリング ルールに基づいてインスタンスを生成します。アルゴリズム モデルは、すべての履歴データが分析される前の時点を記録し、最新のデータの分析を続けます。 |
実行に失敗したインテリジェント検査インスタンスを再試行する | 権限の不足、ソース ログストアの利用不可、宛先ログストアの利用不可、無効な構成などの問題によりインスタンスの実行に失敗した場合、Simple Log Service はインスタンスの実行を自動的に再試行できます。インスタンスが STARTING 状態のままになっている場合、インスタンスの構成が失敗している可能性があります。Simple Log Service はエラー ログを生成し、internal-etl-log ログストアに送信します。インスタンスの構成を確認し、インスタンスを再起動できます。インスタンスがスケジュールされて実行されると、Simple Log Service は再試行の結果に基づいてインスタンスのステータスを SUCCEEDED または FAILED に変更します。 |
推奨事項
ビジネス要件に基づいて検査するメトリックを指定することをお勧めします。これにより、インテリジェント検査の効率を向上させることができます。次のルールが適用されます。
指定されたログストアにアップロードされるデータの形式を指定し、データのフィールドを定義し、観測頻度を指定します。これらは、インテリジェント検査タスクを構成するために実行する必要がある基本操作です。
指定したエンティティのメトリック データの変更を取得し、メトリック データの安定性と周期性を理解し、異常の予備的な予測を立てます。これらの操作は、アルゴリズム モデルのパラメーターを構成するのに役立ちます。
観測頻度を整数秒、整数分、または整数時間に合わせます。これにより、正確なアラートをタイムリーに受信できます。
モデル トレーニング
モデル トレーニングを使用して、異常検出の学習を強化し、異常検出のアラートの精度を向上させることができます。モデル トレーニングには次の利点があります。
リアルタイム検査のみを使用する場合、異常検出の精度は期待どおりにならない可能性があります。この場合、モデル トレーニング タスクを使用して精度を向上させることができます。
リアルタイム検査タスクによって検出された異常と予測される異常の間に GAP 値が存在する場合、ビジネス要件に基づいて異常を検出するためにモデル トレーニング タスクを実行することをお勧めします。
プロセス
データ入力: モデル トレーニング タスクに必要なデータを書き込みます。データには、ラベル付きメトリックとラベルなしメトリックが含まれます。データは Log Service に保存され、SQL 文を使用して取得できます。ラベル付きメトリックはアルゴリズム サービスで直接使用でき、ラベルなしメトリックは異常注入シミュレーション方法を使用してラベル付けされた後にのみアルゴリズム サービスで使用できます。
アルゴリズム サービス: アルゴリズム サービスは、特徴エンジニアリングと教師ありモデルで構成されます。アルゴリズム サービスでは、エンティティごとにモデルがトレーニングされ、各モデルはエンティティ ID によって識別できます。
結果の保存と可視化: モデル トレーニング タスクが完了すると、システムはトレーニング済みモデルをクラウドに保存し、データセットの検証結果とタスクによって生成されたイベントをログ形式で internal-ml-log という名前のログストアに保存します。タスクの詳細で可視化結果を表示できます。
予測タスクの作成: モデル トレーニング タスクが完了すると、タスクでエンティティ用にトレーニングされたモデルを取得できます。次に、予測タスクを作成して、リアルタイムでメトリックの異常を検出し、Log Service が提供するツールを使用して検出結果にラベルを追加できます。これにより、モデルの精度が向上します。
アルゴリズム サービスの概要
アルゴリズム サービスは、次の項目で構成されます。
データセット: データセットは、指定された時間範囲に基づいて構築されます。データセットは、トレーニング セットと検証セットに分類されます。
モデル トレーニング タスクでは特徴エンジニアリングに 1 週間の履歴データが必要になるため、トレーニング セットの期間は 12 日以上である必要があります。モデルの適合度、堅牢性、およびパフォーマンスに関する詳細な検証レポートを生成するには 3 日間のデータが必要になるため、検証セットの期間は 3 日以上である必要があります。
特徴エンジニアリング: 特徴には、間隔値比較と周期値比較、変換、トレンド、ウィンドウイング、タイミングが含まれます。
モデル統合: 複数のツリーベースのモデルを統合して最終モデルを構築できます。