- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
異常検知は、傾向や、季節的な曜日や時間帯のパターンを考慮しながらメトリクスの挙動が過去のものとは異なる期間を認識するアルゴリズム機能です。これは、しきい値ベースのアラート設定では監視することが困難な強い傾向や反復パターンを持つメトリクスに適しています。
たとえば、 ある平日のウェブトラフィック量が夜間帯は通常であるにもかかわらず、午後は異常に低い時間帯を見つけることができます。また、確実にアクセス数が伸びているサイトへのログイン数を測定するメトリクスを考慮できます。 なぜなら、ログイン数が日々増加すると、しきい値が古くなってしまいますが、ログインシステムの潜在的な問題を示唆する予想外の激減が見られた場合、異常検知が警告してくれるからです。
Datadog で異常検知モニターを作成するには、メインナビゲーション画面でMonitors –> New Monitor –> Anomaly の順に移動します。
Datadog にレポートが送信されるメトリクスはすべて、モニターに使用できます。詳細については、メトリクスモニターページをご確認ください。
注: anomalies
関数は過去のデータを使用して今後の予想を立てるため、新しいメトリクスで使用するとあまり正確な結果が得られないことがあります。
メトリクスを定義すると、異常検知モニターにより作成された 2 種のグラフがエディターに表示されます。
直近15 minutes
、1 hour
などの値が範囲を above or below
、above
、below
場合、または custom
に設定した 15 分〜24 時間の値で、アラートをトリガーします。
値が少なくとも 15 minutes
、1 hour
などの範囲内にある場合は回復するか、custom
に 15 分〜24 時間の値を設定します。
above or below
) では、メトリクスが灰色の異常検知帯の外にある場合、異常とみなされます。帯の above
または below
にある場合のみを異常とみなすよう任意で指定することもできます。Datadog は、選択したメトリクスを自動的に分析して、複数のパラメーターを設定しますが、Advanced Options に、編集可能なオプションがあります。
basic
、agile
、robust
)。agile
または robust
アルゴリズムの季節性 (hourly
、daily
、weekly
) サイクル。agile
または robust
の異常検知で季節性に weekly
または daily
を使用する場合に利用可能。詳細については、異常検知とタイムゾーンを参照。異常検出アルゴリズムに必要なデータ履歴: 機械学習アルゴリズムは、ベースラインを計算するために、選択された季節性時間の少なくとも 3 倍の履歴データ時間を必要とします。 例:
季節性アルゴリズムはすべて、メトリクスの挙動の正常範囲を予測する際に、最大で 6 週間分の履歴データを使用します。過去データを大量に使用することで、通常とは異なる挙動が最近発生していた場合、アルゴリズムはこれを重視しません。
下記のグラフでは、これら 3 つのアルゴリズムがいつどのように異なる挙動を示すか表しています。
この例では、basic
は正常値範囲を超えてスパイクする異常値を正しく特定していますが、反復的な季節的パターンが予測値範囲に含まれていません。対照的に、robust
と agile
は、どちらも季節的パターンを認識し、メトリクスが最小値付近で平坦な線になった場合など、より繊細な異常値を検知しています。トレンドも 1 時間ごとのパターンを示しているので、この場合は 1 時間ごとの季節性が最も効果的です。
この例では、メトリクスが突然のレベルシフトを示しています。Agile
は robust
よりも早くレベルシフトに対応しています。さらに、レベルシフト以降、robust
の範囲はより大きな不確実性を反映して広がっていますが、Agile
の範囲に変化は見られません。また、メトリクスが週単位の強い季節性パターンを示すシナリオでは、Basic
が適していないことは明らかです。
この例では、1 時間にわたる異常値に対してアルゴリズムがどのように反応するかを示しています。 Robust
は、急激な変化に対する反応が遅いため、このシナリオでは異常値の境界を調整しません。他のアルゴリズムは、この異常値があたかも新しい正常値であるかのように振る舞い始めます。Agile
は、メトリクスが元のレベルに戻ったことも異常値として認識しています。
これらのアルゴリズムはスケールの扱いも異なります。Basic
と robust
はスケールの影響を受けませんが、agile
は影響を受けます。下の左側のグラフでは、agile
と robust
がレベルシフトを異常としてマークしています。右側のグラフで、同じメトリクスに 1000 を加算したところ、agile
ではレベルシフトを異常とみなすコールアウトは見られなくなりますが、robust
では引き続き見られます。
この例では、各アルゴリズムが新しいメトリクスをどのように処理するか示しています。 Robust
と agile
では、最初の数日は範囲がまったく表示されていません (週単位)。Basic
では、メトリクスが最初に表示された直後から範囲が表示されています。
高度なアラートオプション (自動解決、評価遅延など) の詳細な手順については、モニターコンフィギュレーションページを参照してください。メトリクス固有のオプションのフルデータウィンドウについては、メトリクスモニターページを参照してください。
Say what’s happening と Notify your team のセクションに関する詳しい説明は、通知のページを参照してください。
エンタープライズレベルのお客様は、モニターの作成 API エンドポイントを使用して異常検知モニターを作成できます。Datadog では、モニターの JSON をエクスポートして API のクエリを作成することを強く推奨しています。Datadog のモニター作成ページを使用することで、顧客はプレビューグラフと自動パラメーター調整の恩恵を受け、不適切に構成されたモニターを回避できます。
注: 異常検知モニターは、エンタープライズレベルのお客様専用のサービスです。プロレベルのお客様で、異常検知モニターのご利用を希望される場合は、カスタマーサクセス担当者にお問い合わせいただくか、Datadog 請求担当チームにメールでお問い合わせください。
異常モニターは、他のモニターと同じ API を使用して管理されます。これらのフィールドは、異常モニターに固有です。
query
リクエストの本文の query
プロパティには、次の形式のクエリ文字列を含める必要があります。
avg(<query_window>):anomalies(<metric_query>, '<algorithm>', <deviations>, direction='<direction>', alert_window='<alert_window>', interval=<interval>, count_default_zero='<count_default_zero>' [, seasonality='<seasonality>']) >= <threshold>
query_window
last_4h
や last_7d
などのタイムフレーム。通知のグラフに表示される時間ウィンドウ。少なくとも alert_window
と同じ大きさでなければならず、alert_window
の約 5 倍にすることをお勧めします。metric_query
sum:trace.flask.request.hits{service:web-app}.as_count()
)。algorithm
basic
、agile
、またはrobust
。deviations
direction
above
、below
、またはboth
。alert_window
last_5m
、last_1h
)。interval
alert_window
期間の 5 分の 1 以下でなければなりません。count_default_zero
true
を使用します。値の欠如をゼロとして解釈してはならないカウントメトリクスを送信する場合にのみ、false
に設定します。seasonality
hourly
、daily
、またはweekly
。 basic
アルゴリズムを使用するときはこのパラメーターを除外します。threshold
alert_window
内のポイントの割合。下記の例は、異常検知モニターのクエリを示したものです。Cassandra ノードの平均 CPU が直近 5 分間で通常値を上回る 3 つの標準偏差である場合にアラートを発します。
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
options
thresholds
と threshold_windows
を除いて、リクエスト本文の options
にあるほとんどのプロパティは、他のクエリアラートと同じです。
thresholds
critical
、critical_recovery
、warning
、warning_recovery
のしきい値をサポートします。しきい値は 0 から 1 までの数値で表され、異常である関連ウィンドウの割合として解釈されます。たとえば、critical
のしきい値が 0.9
の場合、trigger_window
(以下で説明)のポイントの少なくとも 90% に異常があると、クリティカルアラートがトリガーされます。または、warning_recovery
の値が 0 の場合、recovery_window
のポイントの 0% が異常である場合にのみ、モニターが警告状態から回復します。critical
threshold
は、query
で使用される threshold
と一致する必要があります。threshold_windows
options
に threshold_windows
プロパティがあります。threshold_windows
には、trigger_window
と recovery_window
の 2 つのプロパティの両方を含める必要があります。これらのウィンドウは、last_10m
や last_1h
などのタイムフレーム文字列として表現されます。trigger_window
は、query
の alert_window
と一致する必要があります。trigger_window
は、モニターをトリガーする必要があるかを評価する際に異常について分析する時間範囲です。recovery_window
は、トリガーされたモニターを回復する必要があるかを評価する際に異常について分析する時間範囲です。しきい値としきい値ウィンドウの標準コンフィギュレーションは次のようになります。
"options": {
...
"thresholds": {
"critical": 1,
"critical_recovery": 0
},
"threshold_windows": {
"trigger_window": "last_30m",
"recovery_window": "last_30m"
}
}
お役に立つドキュメント、リンクや記事: