しきい値検出¶

現在のドキュメントの位置づけ

このドキュメントは、検出ルール設定フローの第2ステップです。設定が完了したら、メインドキュメントに戻り第3ステップ：イベント通知に進んでください。

データ範囲：すべてのデータタイプをサポートします（例：メトリクス M、ログ L、トレース T、ユーザーアクセスデータ R、オブジェクト O など）。

検出設定¶

検出頻度¶

検出を実行する時間間隔を設定します。

プリセットオプション：1 分、5 分、10 分、15 分、30 分、1 時間
Crontab モード：「Crontab モードに切り替える」をクリックするとカスタム周期を設定できます。秒、分、時、日、月、週などの周期に基づいてスケジュールタスクの実行を設定できます。

検出範囲¶

各検出でクエリするデータの時間範囲を設定します（❗️検出範囲は検出頻度以上に設定し、データの実際の報告周期と一致させる必要があります。漏れや誤検出を防ぐためです）。

プリセットオプション：

検出頻度	検出範囲（ドロップダウン選択肢）
30s	1m/5m/15m/30m/1h/3h
1m	1m/5m/15m/30m/1h/3h
5m	5m/15m/30m/1h/3h
15m	15m/30m/1h/3h/6h
30m	30m/1h/3h/6h
1h	1h/3h/6h/12h/24h
6h	6h/12h/24h
12h	12h/24h
24h	24h

カスタム形式：検出範囲をカスタム入力できます。例：20m（直近20分）、2h（直近2時間）、1d（直近1日）。

検出メトリクス¶

DQLに基づいて検出データソースと集約方法を定義します。

高基数フィールドを検出ディメンションとして選択しないでください。設定が不適切でトリガー条件が緩すぎると、頻繁なアラートが発生する可能性があります。現在のクエリの最大返却件数は10万レコードです。

設定例：モニターの検出メトリクスを設定する際に、グループ化フィールドとして trace_id を選択した場合。

システムはこの時点で次のように警告します：

現在のグループ化フィールド trace_id は高基数リスクフィールドです。このようなフィールドを使用して集約すると、大量のグループが生成され、アラート爆発を引き起こしやすくなり、モニターがシステムによって自動的に一時停止される可能性があります。グループ設定を最適化してください。

設定要素¶

設定項目	説明
ワークスペース	デフォルトは現在のワークスペースです。他の権限付与されたワークスペースに切り替えることができます。権限付与後、現在のアカウント配下の他のワークスペースの検出メトリクスを使用してモニターを作成できます。ルールが正常に作成されると、ワークスペース間のアラート設定が可能になります。注意点として、他のワークスペースを選択した場合、検出メトリクスのドロップダウンリストには、現在のワークスペースで使用権限があるデータタイプのみが表示されます。
データソースタイプ	メトリクス、ログ、トレース、ユーザーアクセスデータなど
クエリ方式	シンプルクエリ、式クエリ、PromQL クエリ、データソースクエリ
フィルター条件	タグで検出対象をフィルタリングします
集約方法	`avg`、`sum`、`max`、`min`、`count` など
関数サポート	`fx` ボタンをクリックすると、以下の関数を選択できます：ラベルフィルター：タグ値に基づいてフィルタリングまたはグループ化変換関数：データ型の変換または形式の変換選択関数：first、last、max、min データ欠落補完：前値補完、線形補完、数値補完 ❗️変換関数 `derivative`、`difference`、`non_negative_derivative`、`non_negative_difference` を選択する場合は、`interval` を追加する必要があります。例：`[::5m]`

クリックするとクエリ方式の詳細、関数の詳細説明を参照できます。

トリガー条件¶

トリガー条件と重要度を設定します。クエリ結果が複数の値の場合、いずれかの値がトリガー条件を満たすとイベントが生成されます。

致命的、重大、重要、警告の4段階のしきい値と、正常復旧条件を設定できます。

レベル	設定	説明
致命的	Result >= `[値]` の場合	最高レベルのアラート。即時対応が必要です
重大	Result >= `[値]` の場合	高レベルのアラート。優先的に対応が必要です
重要	Result >= `[値]` の場合	中レベルのアラート。注意が必要です
警告	Result >= `[値]` の場合	低レベルのアラート。留意が必要です
正常	`[N]` 回の検出でイベントが発生しない場合	検出メトリクスが「致命的」「重大」「重要」「警告」の異常イベントをトリガーした後、連続N回の検出が正常だった場合、「正常」イベントが生成されます。異常イベントが正常に復旧したかどうかを判断するために使用します。設定を推奨します。

詳細については、イベントレベル説明を参照してください。

詳細オプション¶

連続トリガー判定¶

有効にすると、トリガー条件を継続的に満たした場合にのみイベントが生成され、瞬間的な変動による誤報を防ぎます（❗️最大設定上限は10回です）。

大量アラート保護¶

システムデフォルトで有効です。

1回の検出で生成されるアラート数が事前設定されたしきい値を超えた場合、システムは自動的にステータス別集約戦略に切り替わります：アラート対象を個別に処理するのではなく、イベントステータスに基づいて少数のサマリアラートを生成し、プッシュします。

これにより、通知の即時性を確保しつつ、アラートノイズを大幅に削減し、過剰なアラート処理によるタイムアウトのリスクを回避できます。

このスイッチが有効な場合、モニターが異常を検出した後に生成されるこのようなイベント詳細には、履歴や関連イベントは表示されません。

復旧条件¶

復旧条件と重要度を設定します。クエリ結果が複数の値の場合、いずれかの値がトリガー条件を満たすと復旧イベントが生成されます。

異なるレベルに対して独立した復旧しきい値を設定し、段階的な復旧を実現します。例：重大アラートは数値が70未満に低下した場合に復旧し、重要アラートは80未満で復旧します。

復旧アラートロジック¶

「復旧条件」を有効にすると、システムは Fault ID（フォールト ID）を一意の識別子として使用し、アラートのライフサイクル全体（Issue 作成などの操作を含む）を管理します。

段階的復旧機能を同時に有効にした場合：

プラットフォームは、アラートレベルごとに（例：critical、warning）個別の復旧ルール（復旧しきい値）を設定します。
各レベルのアラートステータスと復旧ステータスは独立して計算されます。
元の Fault ID で識別されるアラートライフサイクルには影響しません。

したがって、モニターが初めてアラートをトリガーした（新しいアラートライフサイクルを開始した）場合、システムは同時に2つのアラートメッセージを生成します。これらは一見同じように見えますが、理由は以下の通りです：

1つ目のアラートのソース：全体検出（check）、フォールトライフサイクル全体の開始を表します（元のルールに基づく）。
2つ目のアラートのソース：段階的検出（critical/error/warning/…）、有効になった段階的復旧機能が起動していることを表し、具体的なアラートレベルとその後の復旧ステータス（例：critical_ok）を表示します。

上記において、df_monitor_checker_sub フィールドは2種類のアラートを区別するための主要な基準です。

check：全体検出の結果を示します。
その他の値（例：critical、error、warning など）：段階的検出ルールの結果に対応します。

したがって、アラートが初めてトリガーされた場合、2つのレコードが表示されます。内容は似ていますが、ソースと用途が異なります。

`df_monitor_checker_sub`	T+0	T+1	T+2	T+3
`check`	`check`	`error`	`warning`	`ok`
`critical`	`critical`	`critical_ok`
`error`		`error`	`error_ok`
`warning`			`warning`	`warning_ok`

データ欠落¶

検出メトリクスが検出範囲内でクエリ結果が空の場合の処理方法：

オプション	説明
イベントをトリガーしない（デフォルト）	データがない場合にアラートを生成しません。データ欠落を許容するシナリオに適しています。
クエリ結果を0とみなす	空データを0値とみなしてしきい値判定を行います。
データ欠落イベントをトリガーする	データがない場合に異常とみなし、データ欠落イベントをトリガーします。
致命的イベントをトリガーする	データがない場合に致命的レベルのイベントをトリガーします。
重大イベントをトリガーする	データがない場合に重大レベルのイベントをトリガーします。
重要イベントをトリガーする	データがない場合に重要レベルのイベントをトリガーします。
警告イベントをトリガーする	データがない場合に警告レベルのイベントをトリガーします。
復旧イベントをトリガーする	データがない場合に復旧イベントをトリガーします。

トリガー条件、データ欠落、情報イベント生成を同時に設定する場合、以下の優先順位でトリガーを判断します：データ欠落 > トリガー条件 > 情報イベント生成。

つまり、最初にデータ欠落の有無を判断し、次にしきい値トリガーの有無を判断し、最後に情報イベント生成の有無を判断します。

情報イベント生成¶

このオプションを有効にすると、情報イベント生成条件を設定する必要があります。検出結果が「致命的」「重大」「重要」「警告」のいずれのしきい値もトリガーせず、かつ情報イベント生成条件を満たした場合にのみ、システムは「情報」イベントを書き込みます。

正常な状態変化や低優先度の情報を記録する必要があるシナリオに適しています。

後続設定¶

上記の検出設定が完了したら、以下の設定を続けて行ってください：

イベント通知：イベントのタイトル、内容、通知メンバー、データ欠落処理、関連フォールトを定義します。
アラート設定：アラートポリシーを選択し、通知先とミュート周期を設定します。
関連付け：ダッシュボードを関連付け、データを素早く参照できるようにします。
権限：操作権限を設定し、誰がこのモニターを編集/削除できるかを制御します。