カスタムモニターの作成

ページの右上隅にある 新しいモニター ボタンをクリックして、新しいモニターをゼロから作成します。

一般情報の定義

新しいモニターを定義するために 一般 タブを使用します。

タイプ

カスタムモニターは1つの検出モードを提供します。 メトリックしきい値 タイプは、NQLクエリで定義されたメトリックの値とユーザーが定義したしきい値を比較します。 例えば、バイナリを実行しているデバイスの20%がクラッシュを経験した時にモニターがアラートを発動します。

名前

モニターに意味のある名前を提供します。 システムはこの名前を使用して通知を送信し、アラートの概要ページでモニターを視覚化します。

NQL ID

システムはモニターの名前から自動的に一意の識別子を生成します。 モニター作成プロセス中の場合のみ、以下の文字 a-z, 0-9, _ を使用してNQL IDを変更できます。 モニターを作成すると、このフィールドを編集することはできません。 このモニターをNQLを使用してクエリするためにNQL IDを使用します。

削除されたモニターに関連付けられたイベントがシステムに残っている場合（最大30日間）、削除されたモニターのNQL IDを使用してモニターを作成することはできません。

優先度

優先度レベルを設定します。 デフォルトレベルは中です。

タグ

モニター用のカスタムタグを作成します。 これにより、OverviewダッシュボードとWebhooksインテグレーションでタグを使用してアラートをフィルタリングできます。 現在、モニターごとのタグの上限は10個です。

NQLクエリの定義

NQLクエリを使用して監視するメトリクスを定義します。 NQLは、1つまたは複数のメトリクスを選択し、where句を使ってスコープを指定し、時間集計とbyキーワードでグループ化することで、アラートコンテキストに適した粒度を定義するのに役立ちます。 調査で表示 ボタンを使用して、調査モジュールでNQLクエリの結果を表示します。

モニターをサポートするためには、NQLクエリはいくつかのルールに従う必要があります:

1. モニター用のNQLクエリは計算済みまたは集約されたメトリクスを含む必要があり、すべてのクエリはモニターに対応するためにcomputeまたはsummarize句を要求します。

devices
| with device_performance.system_crashes during past 7d 
| compute 
  total_number_of_system_crashes = number_of_system_crashes.sum()

execution.crashes during past 24h
| summarize total_number_of_crashes = count()

1. クエリで複数の条件を設定してアラートをトリガーできるように、追加の計算済みまたは集約されたメトリクスをクエリに含めることもできます。

execution.crashes during past 24h
| summarize 
  total_number_of_crashes = count(), 
  devices_with_crashes = device.count()

1. 監視条件のしきい値を設定するために、少なくとも1つのメトリクスを使用します。 元のクエリにメトリクスが含まれていない場合は、追加のメトリクスを作成します。

モニターと互換性がありません:

devices
| with antiviruses
| where is_up_to_date == no

モニターと互換性があります:

devices
| with antiviruses
| where is_up_to_date == no
| compute device_count = count()

1. NQLレベルで評価されるメトリクスに条件を追加しないでください。 代わりに、トリガー条件 セクションを使用して条件を定義してください。

誤ったモニターNQLクエリ:

execution.crashes during past 24h
| summarize total_number_of_crashes = count()
| where total_number_of_crashes >= 10

条件を含む正しいモニターNQLクエリ:

execution.crashes during past 24h
| summarize total_number_of_crashes = count()

1. where句を使って特定の場所、アプリケーション、その他のカテゴリにモニターの範囲を絞り込みます。

execution.crashes during past 24h
| where binary.name == "excel.exe"
| summarize total_number_of_crashes = count()

1. summarize... by を使用して、アラートコンテキストの正しい粒度を定義します。 次の例では、1つのバイナリ名ごとに1つのアラートが発動されます。

execution.crashes during past 24h
| summarize total_number_of_crashes = count() by binary.name

複数のデバイスに影響を与える問題の検出および単一のデバイスまたはユーザーに影響を与える問題の検出ドキュメントを参照して、NQLクエリを定義する方法をさらに学びましょう。

トリガー条件の定義

アラートをトリガーする条件を定義します。 NQLクエリで計算された各メトリクスを使用して条件を絞り込みます。

スケジューリング頻度の定義

スケジューリング頻度は、システムがトリガー条件を評価する頻度を決定します。 可能な時間枠は15分、1時間、3時間、6時間、12時間、24時間、48時間、7日間です。 しかし、これらの時間枠の利用可能性は during past句およびモニターのNQLクエリで照会されたイベントによって異なります。

モニタークエリの設定がスケジューリング頻度の利用可能性をどのように決定するかを理解するには、次の例を参照してください。

過去に監視されたイベント	最小頻度	最大頻度
device_performance.boots during past 24h	15分	7日間
device_performance.boots during past 7d	24時間	7日間
session.events during past 1h	15分	7日間
session.events during past 24h	12時間	7日間
execution.events during past 1h	15分	7日間
execution.events during past 24h	12時間	7日間
execution.events during past 7d	7日間	7日間

カスタムモニターのインポート

モニターを作成する方法の1つは、以前にエクスポートした設定ファイルからインポートすることです。

削除されたモニターとまだ関連付けられているイベントがシステムに残っている場合、その削除されたモニターと同じNQL IDを持つモニターのインポートはシステムにより許可されません。 アラートイベントはPlatformで最大30日間保存されます。

モニターのインポート中に_NQL IDは既存のアラートを持つ削除済みモニターで既に使用されています_メッセージが表示された場合、エクスポートファイルを変更して新しいNQL IDを作成してください。

---

関連トピック

• 複数のデバイスに影響を与える問題の検出

• 単一のデバイスまたはユーザーに影響を与える問題の検出

• Nexthink Library

• 製品構成