Dash イベントで発表された新しいサーバーレス、ネットワーク、RUM などの機能をぜひご確認ください! Dash イベントで発表された新機能!

異常値モニター

異常検知は、傾向や 1 週間または 1 日単位の季節性パターンなどを考慮して、メトリクスが過去とは異なる挙動をしている時間を特定するためのアルゴリズム機能です。これは、しきい値ベースのアラート設定では監視することが困難または不可能な強い傾向や反復パターンを持つメトリクスに適しています。

たとえば、Web トラフィックが平日の夜遅い時間はまったく普通のレベルなのに、午後は異常に低いという現象を見つける場合に異常検知が役立ちます。別の例として、順調にアクセスを伸ばしているサイトへのログイン数を計測するメトリクスを考えます。ログイン数は毎日増加していくため、どのようなしきい値もすぐに古くなってしまいます。異常検知であれば、ログインシステムに何らかの問題がある可能性を示す予想外の落ち込みがあったときに、すばやくアラートできます。

異常検知モニターの作成方法

Datadog クエリ言語に anomalies 関数があります。この関数を系列に適用すると、通常の結果に加えて、予測される「正常」範囲が返されます。

異常検知モニターには、「Historical Context」(メトリクスが過去にどのような挙動をしていたかを示す履歴的コンテキスト) と、即時的コンテキストを示すアラートウィンドウより長時間の「Evaluation Window」(評価ウィンドウ) の 2 つが示されます。これにより、異常値アルゴリズムが範囲を計算する際に何を考慮しているかがわかります。

anomalies は過去のデータを使用して将来の予想を行うため、データ収集を始めたばかりの新しいメトリクスに anomalies を使用しても良質の結果が得られないことに注意してください。

異常検知モニターを作成するには、New Monitor ページに移動し、Anomaly Detection をクリックします。次に、他のモニターの場合と同様にDefine the metric セクションに入力します。

これで、上のようなフォームが表示されます。ここには、異常な挙動をいつアラートするかを決定するためのパラメーターが用意されています。異常に高い値または異常に低い値だけに注意を払う場合は、範囲より上または下の値にのみアラートを生成するように選択します。次に、アラートウィンドウの長さを決定します。これは、メトリクスの異常がどのくらい続いたときにアラートをトリガーするかを指定します。アラートウィンドウが短すぎると、無意味なノイズが原因で誤ってアラートが発生する可能性があることに注意してください。最後に、メトリクスの正常がどのくらい続けばアラートから回復するかを指定して、リカバリ期間を決定します。

New Monitor フォームの残りのステップを完了し (Say what’s happening など)、Save をクリックすると、異常値モニターが作成されます。

高度なオプション

Datadog は、選択されたメトリクスを分析し、自動的にいくつかのパラメーターを設定します。ただし、高度なオプションのタブで、以下のオプションを編集することもできます。

オプション

  • 灰色の帯の幅。「Deviations」は、ダッシュボードで anomalies 関数に使用される bounds パラメーターに相当します。
  • 使用する異常検知アルゴリズム
  • ロールアップ期間。
  • アラート/警告/リカバリのそれぞれに必要になるポイントの割合。
  • 季節性の設定
    • Weekly - このアルゴリズムは、特定の曜日が過去の同じ曜日と同様に挙動すると想定します。たとえば、今週の火曜の挙動が過去の火曜と同じだと想定します。
    • Daily - このアルゴリズムは、今日の特定の時間が過去の同じ時間と同様に挙動すると想定します。たとえば、今日の午後 5 時の挙動が前日の午後 5 時と同じだと想定します。
    • Hourly - このアルゴリズムは、毎時の特定の分が過去の同じ分と同様に挙動すると想定します。たとえば、5:15 の挙動が 4:15、3:15 … と同じだと想定します。
  • Daylight savings time - Agile または Robust 異常検知アルゴリズムを Weekly または Daily 季節性と共に使用する場合は、ローカルタイムゾーンを考慮するように異常検知モニターを更新できます。詳細については、ローカルタイムゾーンを考慮した異常検知モニターの更新方法を参照してください。

: 機械学習アルゴリズムが十分な効果を上げるには、選択した季節性時間の少なくとも 2 倍の長さの履歴データ時間が必要です。

異常検知アルゴリズム

異常検知アルゴリズムは 3 種類あります。

  • Basic: このアルゴリズムは、反復する季節性パターンがないメトリクスに使用します。 Basic は、単純な遅れローリング分位計算を使用して予測値の範囲を決定します。データをほとんど使用せず、状況の変化にすばやく対応しますが、季節的な挙動や長期の傾向については認識しません。

  • Agile: このアルゴリズムはメトリクスのレベルシフトにすばやく対応するため、季節性メトリクスに使用されます。 Agile は SARIMA アルゴリズムの安定版です。直近の過去のデータを予測に組み込むことで、レベルシフトに合わせてすばやく更新できます。ただし、最近の長期的な異常値に対する安定性は低下します。

  • Robust: このアルゴリズムは、安定していることが期待できる季節性メトリクスのゆっくりとしたレベルシフトを異常値と見なした場合に使用されます。 Robust は季節的傾向分解アルゴリズムの 1 つです。極めて安定しており、長期的な異常値の間も予測は一定しています。ただし、意図的なレベルシフトへの応答には時間がかかります (コードの変更によってメトリクスのレベルがシフトした場合など)。

どの季節性アルゴリズムも、メトリクスの正常範囲の挙動予測を計算する際に、最長で数か月分の履歴データを使用します。これらのアルゴリズムは、大量の過去データを使用することで、通常とは異なる挙動が最近も発生していた場合には重視し過ぎないようにすることができます。

以下の図は、この 3 つのアルゴリズムがそれぞれ異なる動作を行う様子を示しています。最初の図で、Basic は正常な値の範囲を超えてスパイクする異常値を正しく特定していますが、反復的な季節性パターンが予測値の範囲に組み込まれていません。対照的に、RobustAgile は、どちらも季節性パターンを認識し、より繊細な異常値を検知できます (メトリクスが最小値付近で平坦になる場合など)。

次の図のメトリクスは、突然のレベルシフトを示しています。AgileRobust よりすばやくレベルシフトに対応します。また、Robust の範囲はレベルシフト以降の不確実性を反映して幅が広くなっていますが、Agile の境界の幅は変わりません。メトリクスが週単位の強い季節性パターンを示すシナリオに Basic が適していないことは明らかです。

次の図は、1 時間続く異常値にこれらのアルゴリズムがどのように対応するかを示すものです。Robust はこの異常値を完全に無視します。他のアルゴリズムは、この異常値が新しい標準であるかのように振る舞い始めます。Agile は、メトリクスが元のレベルに戻ったことも異常値として特定しています。

これらのアルゴリズムはスケールの扱いも異なります。BasicRobust はスケールの影響を受けませんが、Agile は影響を受けます。左側のグラフは、AgileRobust もレベルシフトを異常とマークしています。右側では、同じメトリクスに 1000 を加算しました。これで、Agile はレベルシフトを異常と見なさなくなりますが、Robust は引き続き異常と見なしています。

最後に、各アルゴリズムが新しいメトリクスをどのように処理するかを見てみます。RobustAgile では、最初の数シーズンに範囲が表示されません (ここでは季節性を「週単位」に設定)。Basic では、メトリクスが最初に表示された直後に範囲が表示され始めます。

API による異常値モニター

エンタープライズレベルのお客様は、anomalies 関数をモニタークエリに追加すれば、標準のモニターの作成 API エンドポイントを使用して API から異常検知モニターを作成できます。クエリは次の式に従います。

time_aggr(eval_window_length):anomalies(space_aggr:metric{tags}, 'basic/agile/robust', deviation_number, direction='both/above/below', alert_window='alert_window_length', interval=seconds, count_default_zero='true')>= threshold_value

: 異常検知モニターは、エンタープライズレベルのカスタマーサブスクリプションでのみ使用できます。プロレベルのカスタマーサブスクリプションのお客様が異常検知モニター機能を使用される場合は、カスタマーサクセス担当者にお問い合わせいただくか、Datadog の課金チームまで電子メールでお問い合わせください。

Cassandra ノードの CPU の平均が直近の 5 分間に通常の値を標準偏差の 3 倍を上回る場合に通知を行う異常検知モニターを作成するには、API コールで次のクエリを使用します。

avg(last_1h):anomalies(avg:system.cpu.system{name:cassandra}, 'basic', 3, direction='above', alert_window='last_5m', interval=20, count_default_zero='true')>= 1

FAQ

あらゆるものに対して異常検知を使用した方がいいですか。

いいえ。異常検知は、予測可能なパターンを持つメトリクスを視覚化して監視できるように設計されています。たとえば、my_site.page_views{*} はユーザートラフィックに左右され、時間と曜日に基づいて予測可能な変動を見せます。 メトリクスが反復パターンも予測パターンも持たない場合は、異常検知より単純なチャートオーバーレイまたはしきい値アラートをお勧めします。

また、異常検知が適切な予測を行うには履歴データが必要です。数時間や数日分のメトリクスしか収集されていない場合、異常検知が役立たない可能性があります。

ダッシュボードで複数のグループに異常検知を使用できないのはなぜですか。

1 つのグラフに独立した多数の時系列を表示するとスパゲッティ化することがあり、これに異常検知の視覚化を追加しても事態を悪化させるだけです。

ただし、1 つのグラフに複数の系列を一度に 1 つ追加することは可能です。マウスを重ねたときにのみ、灰色のエンベロープが表示されます。

過去の異常値は現在の予測に影響しますか。

Basic 以外のアルゴリズムは、膨大な履歴データを使用するため、ほとんどの異常値に対して安定です。最初のグラフでは、メトリクスが 0 に減少した後もエンベロープは 400K 付近で安定し、それが 1 日中継続しています。

2 つ目のグラフは、1 日後の同じメトリクスを示しています。エンベロープの計算には前日のデータも使用されていますが、そのときに発生した異常値には影響されていません。

ズームインすると異常値が「消える」のはなぜですか。

ズームレベルが異なると、同じクエリでも特性がまったく異なる時系列になる可能性があります。表示する期間が長いほど、各ポイントは、さらに粒度が細かい多数のポイントの集計値を表すことになります。したがって、粒度が細かいポイントでは、観察されるノイズがこれらの集計ポイントによって隠される可能性があります。たとえば、1 週間を表示するチャートが 10 分間を表示するチャートより滑らかに (ノイズが少なく) 表示されることはよくあります。

Datadog の異常検知アルゴリズムによって描画される灰色の帯の幅は、ある程度プロットの時系列に含まれるノイズの多さに基づいています。この帯は、大部分の通常ノイズがその中に収まり、異常として表示されることがない程度に十分な幅を持つ必要があります。ただし、通常ノイズが収まる程度に帯の幅を広くすると、特に短いタイムウィンドウを表示する場合に、一部の異常値が隠蔽される可能性もあります。

以下に具体的な例を示します。app.requests メトリクスにはノイズがありますが、平均値は 8 で一定しています。ある日、10 分間の異常期間が発生しました。9:00 に始まり、その間のメトリクスの平均値は 10 です。次のチャートはこの系列をグラフに表示したもので、タイムウィンドウは 1 日、グラフの各ポイントは 5 分間の集計値です。

この灰色の帯は適切なものだと言えます。時系列内のノイズが収まるだけの十分な幅があり、しかも、幅が広すぎることがないので 9:00 の異常値が目立つようになっています。次のチャートは、30 分のタイムウィンドウにズームインしたビューで、上の 10 分間の異常値が含まれています。グラフの各ポイントは 10 秒間の集計値です。

ここでも、帯は合理的にサイズ変更されています。8:50 ~ 9:00 と 9:10 ~ 9:20 の正常なデータが帯の中にあるからです。これよりも帯が狭くなると、通常のデータが異常と見なされるようになってしまいます。 このグラフの帯が、前のグラフより 8 倍近く広くなっていることに注目してください。9:00 ~ 9:10 の異常期間は系列の他の部分とは多少違って見えますが、帯の外側に出るほど極端ではありません。

一般に、ズームインしたときに異常値が消えても、それが異常値ではないという意味ではありません。つまり、ズームインしたビューでの個別のポイントは個々の異常として切り分けられなくても、普通とは少し違うポイントが多数発生しているという事実が異常ということになります。

一部の関数を異常検知と組み合わせようとするとクエリパースエラーが発生するのはなぜですか。

anomalies() 関数の呼び出しの中にすべての関数をネストできるわけではありません。特に、cumsum()integral()outliers()piecewise_constant()robust_trend()trend_line() の各関数は、異常検知モニターまたはダッシュボードクエリに組み込めません。

異常検知は、履歴データを使用して系列の正常な挙動のベースラインを確立します。上に挙げた関数は、クエリウィンドウの配置に影響されます。つまり、あるタイムスタンプでの系列の値は、それがクエリウィンドウ内のどこにあるかによって大幅に変化する可能性があります。この不安定性のため、異常検知機能は安定した系列のベースラインを決定できなくなります。

adaptive アルゴリズムはどうなったのですか。

以前、adaptive というアルゴリズムを公開していました。これはメトリクス固有の季節性を考えて予測を適宜調整しようとするものです。現在、モニターのセットアップ時にメトリクスの季節性が自動的に検出されるため、このアルゴリズムが特に必要ではなくなりました。しかもこのアルゴリズムは遅く、他のアルゴリズムより多くのデータが必要でした。adaptive アルゴリズムを使用する既存のモニターは、引き続き機能します。

count_default_zero 引数とは何ですか。

以前はカウントメトリクスをゲージとして扱い、報告されたポイント間を補間していました。そのため、報告数がまばらなカウントに対しては、見た目に非常におかしなメトリクスが生成されることがありました。anomalies はカウント間を補間しなくなりましたが、レガシーモニターでは、count_default_zero 引数を使用して以前の挙動が維持されます。

カウントメトリクスを意図的にゲージとして扱っていたのですが、その場合はどうすればよいですか。

カウントしている対象がエラーなどの場合は、カウント間を補間しないのが当然です。ただし、毎時に定期的に行われるジョブがある場合は、ランとランの間でメトリクスが値 0.0 を報告しない方がよいこともあります。それには、1) ロールアップ (Advanced options セクション) を 1 時間に設定するか、2) API を使用して明示的に count_default_zero='false' を設定するという 2 つの方法があります。

「Advanced options」でロールアップ期間を設定する方法と、.rollup() を使用してクエリで設定する方法では、どのような違いがありますか。

ロールアップをクエリで明示的に設定すると、異常値モニターのロールアップ期間オプションが無視されます。

メトリクスの値が X 未満の場合は異常でもかまいません。このような異常値を無視する方法はありますか。

範囲を超える値をアラートする異常値モニター A を作成し、さらにしきい値アラートを使用して X より大きい値をアラートする別のメトリクスモニター B を作成して、最後に A && B複合条件モニターを作成します。

モニターを保存しようとしたら、「alert and alert recovery criteria are such that the monitor can be simultaneously in alert and alert recovery states」(アラートとアラートリカバリの基準が、モニターが同時にアラート状態およびアラートリカバリ状態になり得る内容です) というメッセージが表示され、保存できませんでした。どうしてですか。

アラート期間とアラートリカバリ期間に異なるウィンドウを設定すると、あいまいな状態になる可能性があります。アラートとアラートリカバリのウィンドウサイズは、両方が同時に満たされないように設定する必要があります。たとえば、2 時間のウィンドウに対してアラートしきい値 50% を設定し (つまり、異常が 1 時間続けばアラートをトリガーする)、10 分間のウィンドウに対してリカバリしきい値 50% を設定すると (つまり、非異常が 5 分間続けば回復する)、アラート状態とアラートリカバリ状態が同時にトリガーされる可能性があります。たとえば、最後の 5 分間が異常ではなく、その前の 1 時間が異常だった場合は、アラートとアラートリカバリの両方がトリガーされます。

夏時間は異常検知モニターにどのように影響しますか。

Datadog のモニターは UTC 時間を使用し、デフォルトではローカルタイムゾーン (例: EST、PST、CST) を考慮しません。ユーザーアクティビティは、ユーザーのローカルタイムに対して変わらないことが普通なので、UTC 時間からは相対的にシフトします。これが予期しない異常値として検出される可能性があります。

Datadog では、タイムシフトに対して自動的に修正が行われるタイムゾーンを異常検知モニターごとに構成することができます。手順については、ローカルタイムゾーンを考慮した異常検知モニターの更新方法を参照してください。

その他の参考資料

目次