検出ルール¶

システムには豊富な検出ルールが組み込まれており、さまざまなデータのモニタリングニーズに的確に対応し、誤アラートとアラート漏れを効果的に防ぎます。

設定フロー¶

モニターを作成するには、以下の順序で設定を完了する必要があります：

1. ルールタイプの選択：検出設定のデータ範囲とアルゴリズムロジックを決定します；
2. 検出設定：タイプごとに対応する設定項目が異なります；
3. イベント通知：イベントタイトル、内容、関連情報、およびデータ欠落時の処理を定義します；
4. アラート設定：通知ポリシーとミュート期間を設定します；
5. 関連付け：ダッシュボードの関連付けを設定します；
6. 権限：操作権限を設定します。

「検出設定」はルールタイプによって異なりますが、イベント通知、アラート設定、関連付け、権限の設定ロジックはすべてのルールタイプで共通です。

ルールタイプ¶

モニタリング対象に応じて適切な検出ロジックを選択できます：

ルールタイプを選択すると、「検出設定」モジュールで選択可能なパラメータがそれに応じて変わります。イベント通知と以降の設定は、すべてのタイプで共通です。

検出設定¶

検出ルールのタイプに応じて、対応する検出頻度、検出区間、検出メトリクスをそれぞれ設定できます。

ルールタイプによって検出設定は大きく異なります。対応するタイプの詳細設定ドキュメントを参照してください。

データ待機ウィンドウ¶

データ待機ウィンドウはすべてのモニタータイプに適用されます。計画された実行時間に達すると、モニターは指定した時間だけ待機してから監視判定を実行し、データ遅延による誤報の可能性を低減します。

• デフォルトは待機なしです；
• 選択可能な待機時間は 1 分、2 分、3 分、5 分、10 分、15 分、30 分です；
• 待機時間は隣接する 2 回の計画実行時間の間隔より短い必要があります。そうでない場合、モニターを保存できず、「データ待機ウィンドウはモニター実行間隔より短くする必要があります」と表示されます。Crontab モードでも隣接する 2 回の計画実行時間に基づいて検証されます。

たとえば、モニターが 10:00 に実行される予定で、データ待機ウィンドウが 5 分に設定されている場合、タスクは約 10:05 に実行されます。待機によって実行時間が遅れるだけで、クエリの時間範囲は変わりません。検出区間が直近 1 時間の場合でも、09:00 ~ 10:00 のデータを引き続きクエリします。

詳細な実行ロジックについては、モニターの内部原理を参照してください。

イベント通知¶

モニターがトリガーされたときに生成されるイベントのタイトル、内容、通知メンバー、および関連処理を定義します。

イベントタイトル¶

アラートのトリガー条件となるイベント名を定義します。プリセットのテンプレート変数を使用できます。

イベント内容¶

イベント通知の内容を入力します。トリガー条件を満たすと、システムはこの内容を外部に送信します。通常、以下の情報が含まれます：

• Markdown 形式の本文；
• 関連リンクやテンプレート変数を挿入できます；
• 詳細設定に基づいて関連ログやエラー情報を追加できます；
• イベント内容の送信先となる通知メンバー。

イベント内容は構文チェックとテンプレートプレビューに対応しており、保存前に変数や条件分岐のレンダリング結果を確認できます。

関連リンク¶

+ リンクをクリックすると、システムが現在の検出メトリクスに基づいてジャンプリンクを自動生成します。リンクアドレスには、現在のドメイン名、ワークスペース ID、検出時間範囲（{{df_check_range_start}} ~ {{df_check_range_end}}）、および動的なフィルター条件が含まれます。

リンク形式の例：

ログエクスプローラー：[関連ログを表示](<{{STUDIO_CONSOLE_BASE_URL}}/logIndi/log/all?time={{df_check_range_start}},{{df_check_range_end}}&w={{df_workspace_uuid}}>)

トレースエクスプローラー：[関連トレースを表示](<{{STUDIO_CONSOLE_BASE_URL}}/tracing/link/all?time={{df_check_range_start}},{{df_check_range_end}}&w={{df_workspace_uuid}}>)

テンプレート変数¶

+ 変数をクリックしてプリセットのテンプレート変数を挿入します。変数はイベントのトリガー時に実際の値に動的に置き換えられます：

サポートされているすべてのテンプレート変数は、クリックしてご確認ください。

詳細設定¶

「詳細設定」を通じて、DQL を使用して関連データのコンテキストをイベントに埋め込めます。

1. 関連ログを追加

クリックするとテンプレートが自動生成されます：

{% set dql_data = DQL("L::RE(`.*`):(`message`) { `index` = 'default' } LIMIT 1") %}
{{ dql_data.message | limit_lines(10) }}

設定のポイント：

• {index= 'default' } を実際のインデックス名に置き換える必要があります
• RE(``.*``) は正規表現のマッチングをサポートします。例：RE(``error\|exception``)
• limit_lines(10) は出力行数を制限し、通知が長くなりすぎるのを防ぎます

2. 関連エラースタックを追加

クリックするとテンプレートが自動生成されます：

{% set dql_data = DQL("T::re(`.*`):(`error_message`,`error_stack`){ (`source` NOT IN ['service_map', 'tracing_stat', 'service_list_1m', 'service_list_1d', 'service_list_1h', 'profile']) AND (`error_stack` = exists()) } LIMIT 1") %}
{{ dql_data.error_message | limit_lines(10) }}
{{ dql_data.error_stack | limit_lines(10) }}

設定のポイント：

• source NOT IN [...] は統計系の集約データを除外し、元のトレースのみを保持します
• (error_stack= exists()) はスタック情報を含むエラーを確実に返します

通知メンバー（@）¶

クリックしてワークスペースメンバーを選択します。

有効になる条件：

1. インシデント関連付けが有効な場合のみ、@メンバー設定が有効になり、指定したメンバーにこのイベント内容が送信されます；
2. この設定はアラート設定の通知先とは独立しており、アラート通知の範囲には影響しません。

カスタム通知内容¶

デフォルトでは、システムはイベント内容をアラート通知の内容として使用します。実際に外部へ送信する通知をカスタマイズする必要がある場合は、ここでスイッチを有効にして通知情報を入力できます。

• 独立したエディターが展開され、外部に送信する通知内容を個別に定義できます；
• 元のイベント内容は引き続きプラットフォーム内に保持され、イベント詳細の表示に使用されます；
• 独立したエディターでも、Markdown、テンプレート変数、関連リンク、詳細設定を使用できます。

データ欠落イベント¶

データ欠落（データの報告がない）時の通知内容をカスタマイズします。この種のイベントが最終的に外部に送信される際のタイトルや内容などを併せて設定できます。

カスタム設定がない場合、システムは公式のデフォルトテンプレートを使用して欠落アラートを送信します。

カスタマイズしたデータ欠落イベントの内容でも構文チェックとテンプレートプレビューに対応しており、プレビューでは現在入力されているデータ欠落のタイトルと内容が使用されます。

インシデント関連付け¶

関連付けを有効にすると、このモニターで異常イベントが発生した場合、インシデントが同時に作成されます。

設定項目¶

1. 自動的に作成されたインシデントにタグを追加し、インシデントセンターでの分類・絞り込みを容易にします；

2. イベント重要度とインシデント重要度のマッピング関係を設定します。複数のルールを追加できます。

3. 致命的/重大/重要/警告/データ欠落レベルのイベントが発生すると、新しいインシデント重要度 P0/P1/P2/P3/... が同時に作成されます

ここで作成されたインシデントはインシデントセンターで確認できます（❗️この種のインシデントにはタグのフィルター条件が含まれます）。

連動の仕組み¶

1. イベントがトリガーされると、インシデントセンターにインシデントレコードが自動的に作成され、インシデントの説明にイベント内容が自動的に同期されます；
2. イベント内容の @メンバー リストに基づいて、インシデント作成の通知を送信します；
3. インシデントセンターでインシデントの詳細を確認できます。システムは、そのインシデントに関連するデータ全体（パフォーマンスメトリクス、エラーログ、呼び出しトレース、インフラストラクチャートポロジーなど）を自動的に関連付けて表示します。

アラート設定¶

モニターがトリガー条件を満たすと、指定された通知先にアラートメッセージが直ちに送信されます。

アラートポリシー¶

作成済みのアラートポリシーを選択します。複数選択に対応しています。ポリシー名をクリックすると詳細が展開され、アラートポリシーを編集をクリックすると設定を変更できます：

関連付け¶

作成済みのダッシュボードを選択してモニターとダッシュボードの関連付けを確立し、すばやくジャンプして監視データを可視化して確認できるようにします。

権限¶

モニターの操作権限を設定し、各ユーザーが役割と権限レベルに応じて設定に沿った操作を行えるようにします。現在のワークスペースの Owner は、ここでの操作権限設定の影響を受けません。

• この設定を有効にしない場合：「モニター設定管理」のデフォルト権限に従います；
• この設定を有効にしてカスタム権限オブジェクトを選択した場合：作成者と権限が付与されたオブジェクトのみが、このモニターに設定されたルールの有効化/無効化、編集、削除を実行できます；
• この設定を有効にしたがカスタム権限オブジェクトを選択していない場合：作成者のみがこのモニターの有効化/無効化、編集、削除の権限を持ちます。

さらに、ワークスペースの Owner は統合権限管理設定を使用して、管理者、役割、またはメンバーにモニターの操作権限を一括して付与できます。権限を付与されたオブジェクトは、カスタム操作権限が有効になっているすべてのモニターを操作できるため、各モニターのカスタム権限オブジェクトに個別に追加する必要はありません。

検出を即時トリガー¶

ルールの設定が完了したら、検出を即時トリガーをクリックしてテストを手動で 1 回実行し、現在のルール設定の全体的な効果を検証できます。テストの実行によって実際のアラート通知が生成されることはありません。

アラートキャッシュ保護メカニズム¶

設定が完了すると、モニターは実行中に以下の保護ポリシーを実行します。システムは以下のメカニズムにより、高カーディナリティの集約によって過剰な検出オブジェクトが生成されるのを防ぎ、システムへの負荷を軽減します：

アラートキャッシュの上限は 100,000 件、警告比率は 80% です。

一時停止からの復旧メカニズム¶

アラートキャッシュの上限超過によりモニターがシステムによって一時停止された場合、次のいずれかの操作を実行すると自動的に復旧します：

• クエリ条件を変更してモニターを再保存する
• モニターを直接再保存する

システムはアラートキャッシュのマーカーを自動的にクリアし、モニターの通常動作を復旧します。追加の操作は必要ありません。

関連情報¶

モニタールールの作成が完了したら、以下の操作が必要になる場合があります：