How intelligent health check works - Simple Log Service - Alibaba Cloud ドキュメントセンター

Simple Log Service (SLS) のインテリジェント異常検知機能は、モデルトレーニングとリアルタイムヘルスチェック機能を提供します。ログやメトリクスなどのデータに対し、自動的でインテリジェント、かつ適応性のあるモデルトレーニングと異常検知をサポートします。

背景情報

ログやメトリクスのような時系列データは、時間とともに蓄積されます。例えば、あるサービスが 1 日に 1,000 万件のデータを生成する場合、年間で合計 36 億件のデータが蓄積されます。固定のルールを使用してこのデータをチェックする場合、次のような問題に直面する可能性があります。

低効率：異常を特定し捕捉するために、さまざまなルールを手動で設定する必要があります。
適時性の欠如：ほとんどの時系列データは時間的な影響を強く受けます。障害や変更はメトリクスのパターンに影響を与えます。特定のルールで識別された異常が、後の時点では正常と見なされることがあります。
設定の困難さ：時系列データは、スパイク、転換点、周期的な変化など、さまざまなパターンを示します。しきい値の範囲もさまざまです。複雑なパターンに対して、ルールを設定することはしばしば困難です。
パフォーマンスの低下：データストリームは動的に変化し、ビジネスモデルは急速に進化するため、固定ルールは新しいビジネスシナリオでは効果がなくなります。これにより、多くの偽陽性や偽陰性が発生する可能性があります。異常に対する許容度は、シナリオやユーザーによって異なります。問題をトラブルシューティングする際には、より多くの有効な異常点を捕捉することが調査の助けとなります。アラートを処理する際には、より少なく、より重要な異常点に絞ることで、アラート処理の効率が向上します。

これらの問題を解決するために、SLS はインテリジェントヘルスチェック機能を提供します。この機能は、独自の AI アルゴリズムを使用して、ログやメトリクスなどのストリーミングデータを集約、チェックし、アラートを作成します。ユーザーは監視項目を指定するだけで、アルゴリズムモデルが自動的に異常を検知し、ビジネスの変化に適応し、手動でのルール設定なしでアラートの精度を高めます。

仕組み

SLS は SQL 文を使用して監視メトリクスを構築および集計します。スケジューリングルールに基づいて定期的にデータをモデルにプルし、イベント標準に基づいてヘルスチェック結果を送信先 Logstore (internal-ml-log) に書き込み、異常に対してアラート通知を送信します。

機能

インテリジェントヘルスチェックは、以下の機能を提供します。

機能	説明
監視対象オブジェクトの設定	SQL またはクエリ・分析文を使用して、ログデータを監視メトリクスに変換し、タスクを開始します。
定期的なデータ分析	必要に応じて、データ特徴、エンティティフィールド、メトリックフィールドを設定します。ヘルスチェックインスタンスは、新しい監視対象エンティティを自動的に検出し、定期的にデータをプルし、自動モデリングとインテリジェント分析を実行します。モデルは、最短 1 秒のプル間隔に対応しています。
パラメーター設定とモデルパフォーマンスのプレビュー	異なるモデルパラメーターの効果をプレビューし、メトリクスの時系列曲線と異常スコア曲線を可視化します。これにより、データの特徴に最も適したモデルパラメーターを設定する上で役立ちます。
マルチチャネルの結果出力	ヘルスチェックの結果は送信先 Logstore に保存されます。異常情報はアラート通知を通じて送信されます。

用語

次の表は、インテリジェントヘルスチェックで使用される主要な用語を説明しています。

用語	説明
タスク	ヘルスチェックタスクには、データ特徴、モデルパラメーター、アラートポリシーなどの情報が含まれます。
インスタンス	ヘルスチェックタスクは、タスク設定に基づいて実行インスタンスを生成します。各インスタンスは、タスク設定に基づいて定期的にデータをプルし、アルゴリズムモデルを実行し、ヘルスチェック結果を配信します。タスクは 1 つのインスタンスのみを生成します。インスタンスが正常にスケジュールされているか、異常によりリトライされているかに関わらず、複数のインスタンスを同時に実行することはできません。パラメーターのホットアップグレードはサポートされていません。タスク設定を変更すると、ヘルスチェックタスクは新しいインスタンスを作成してアルゴリズムモデルを実行します。新しいインスタンスは以前のインスタンスとは独立しています。異なる操作がインスタンスのスケジューリングと実行にどのように影響するかについての詳細は、「スケジューリングと実行シナリオ」をご参照ください。
インスタンス ID	実行インスタンスの一意の識別子。
作成時刻	インスタンスが作成された時刻。インスタンスは通常、設定したタスクルールに基づいて作成されます。バックフィル実行や遅延を取り戻すために、インスタンスはすぐに作成されます。
実行時刻	インスタンスが実行を開始した時刻。タスクがリトライされた場合、これは最後の実行の開始時刻です。
終了時刻	インスタンスが実行を終了した時刻。タスクがリトライされた場合、これは最後の実行の終了時刻です。
実行ステータス	インスタンスの実行ステータス。有効な値：実行中 (RUNNING) 開始中 (STARTING) 成功 (SUCCEEDED) 失敗 (FAILED)
データ特徴	データ特徴には、次の設定が含まれます。観測間隔：データの観測と収集の時間間隔。これはアルゴリズム分析の間隔でもあります。タスクルールによって生成され、前のインスタンスのタイムアウト、遅延、またはバックフィル実行の影響を受けません。ほとんどのシナリオで、データストリームの観測間隔は安定しています。間隔は最短 1 秒です。時間フィールド：観測値の時刻を示すデータ内のフィールド。時間フィールドは 1 つだけ指定できます。エンティティフィールド：特定の観測エンティティを示すデータ内のフィールド。特徴量フィールド：特定の観測値を示すデータ内のフィールド。複数の特徴量フィールドを設定できます。また、各特徴量に値の範囲を設定して、モデルがより正確な異常検知を行うように促すこともできます。
アルゴリズム設定	アルゴリズムによって設定項目が異なります。各アルゴリズムの設定項目の詳細については、「SQL を使用したリアルタイム検知のためのメトリックデータ集計」をご参照ください。
検査イベント	ヘルスチェックイベントには、次の情報が含まれます。エンティティ情報：現在のヘルスチェック結果のデータソースを識別します。設定情報：現在のヘルスチェック結果のタスク設定を識別します。異常スコア：異常の深刻度を示す、モデルからの定量的な結果です。値の範囲は 0 から 1 です。異常スコアが 0.75 を超える場合、アラート通知が送信されます。異常タイプ：モデルによって決定された初期の異常タイプ。スパイク、シフト、ジッター、欠損、しきい値超過の 5 種類があります。

スケジューリングと実行シナリオ

次の表は、ヘルスチェックタスクの一般的なスケジューリングと実行シナリオを説明しています。

シナリオ	説明
過去の時点からヘルスチェックタスクを開始する	ヘルスチェックタスクを作成した後、タスクルールに基づいて履歴データを処理します。アルゴリズムモデルは履歴データを迅速に消費し、モデルトレーニングを実行し、徐々に現在時刻に追いつきます。タスク作成時刻またはモデル学習終了時刻に達すると、ヘルスチェックイベントが生成されます。
スケジューリング設定の変更	スケジューリング設定を変更すると、次のインスタンスは新しい設定に基づいて生成されます。アルゴリズムモデルは現在の消費時刻を記憶し、新しいデータのチェックを続行します。
失敗したインスタンスのリトライ	権限不足、ソースまたは宛先データベースの不存在、無効な設定などの問題によりインスタンスが失敗した場合、システムは自動的にリトライします。ステータスが Starting のままである場合、設定が間違っている可能性があります。エラーログは internal-etl-log Logstore に書き込まれます。設定を確認し、タスクを再起動してください。スケジューリングと実行が成功した後、システムは結果に基づいてインスタンスのステータスを Succeeded または Failed に更新します。

利用にあたっての推奨事項

インテリジェントヘルスチェックを最大限に活用するには、次の推奨事項に従ってください。

ヘルスチェックタスクを設定する前に、Logstore 内のデータの形式を理解し、フィールドの意味を明確にし、観測間隔を決定してください。
アルゴリズムパラメーターを効果的に設定するには、安定性や周期性など、監視対象オブジェクトの時系列データの変化を理解し、異常パターンについてある程度想定しておく必要があります。
ヘルスチェックタスクの時間ウィンドウを、きりの良い時間単位 (秒、分、時間など) に合わせるようにしてください。これにより、異常イベントアラートの適時性と、複数イベントの相関性の正確性が確保されます。

モデルトレーニング

モデルトレーニングを使用して、異常学習を強化し、将来の異常アラートの精度を向上させることができます。モデルトレーニングには、次の利点があります。

リアルタイムヘルスチェック機能だけでは異常検知の精度が期待に満たない場合、モデルトレーニングタスクを使用して精度を向上させます。
リアルタイムヘルスチェックタスクで検出された異常が、ユーザーが想定する異常と異なる場合は、まずモデルトレーニングタスクを実行して、必要な異常タイプを適応的に検出します。

基本的なプロセス

データ入力：モデルトレーニングサービスに必要なデータを提供します。これには、ラベル付きおよびラベルなしのメトリックデータが含まれます。このデータは SLS に保存され、SQL クエリを使用して取得する必要があります。ラベル付きメトリックデータは、アルゴリズムサービスに直接送信できます。ラベルなしメトリックデータは、アルゴリズムサービスに送信する前に、異常注入シミュレーションを使用してラベル付けする必要があります。
アルゴリズムサービス：このサービスは、特徴量エンジニアリングと教師ありモデルという 2 つの主要部分で構成されています。アルゴリズムサービスでは、エンティティごとにモデルがトレーニングされます。エンティティ ID は、対応するモデルを識別するために使用されます。
結果の保存と可視化：モデルトレーニングタスクが完了すると、システムはトレーニング済みのモデルをクラウドに保存します。また、データセットの検証結果とタスク実行時に発生したイベントを、internal-ml-log という名前の Logstore にログとして保存します。タスクの詳細で可視化結果を表示することもできます。
予測タスクの作成：モデルトレーニングタスクが完了すると、タスク内の各エンティティに対してトレーニングされたモデルが得られます。その後、予測タスクを作成して、将来のメトリックデータに対してリアルタイムの異常検知を実行できます。SLS のラベリングツールを使用して結果にラベルを付け、より多くのラベル付きデータを取得し、モデルを繰り返しトレーニングして精度を向上させます。

アルゴリズムサービスの概要

アルゴリズムサービスは、次の 3 つの主要部分で構成されています。

データセット：データセットは指定された時間範囲に基づいて構築され、トレーニングセットと検証データセットに分割されます。

モデルトレーニングタスクでは 1 週間の履歴データが必要なため、トレーニングセットは 12 日以上の期間をカバーする必要があります。検証データセットは、モデルの適合度、堅牢性、パフォーマンスをより良く説明する検証レポートを生成するために 3 日間のデータが必要となるため、3 日以上の期間をカバーする必要があります。
特徴量エンジニアリング：これには、周期的比較特徴、シフト特徴、トレンド特徴、ウィンドウ特徴、および時間特徴が含まれます。
アンサンブルモデル：アンサンブルモデルは、複数のツリーベースのモデルを統合して構築されます。