カスタムモニターの作成

Nexthinkは、内蔵モニターを使用開始することを推奨しています。これらはより幅広い機能の範囲を提供しています。 または、ローカルデバイスから事前設定されたモニターをインポートすることができます。

アラートのカスタムモニターを作成するには、ナビゲーションパネルの Alerts と Diagnostics > アラート管理 に進みます：

1. ページの右上隅にある 新しいモニター ボタンをクリックして、モニター構成を開きます。

2. 一般タブのフィールドに入力します。

3. NQL クエリと条件タブを定義します。

• トリガー条件とスケジューリング頻度を含めます。

1. 事前対応型アラート管理のためにメールまたはWebhooksによる通知を設定します。

一般的なモニター設定の構成

新しいモニター構成ページから、一般タブの次のフィールドに入力します：

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

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

• NQL ID: システムはモニターの名前から自動的に一意の識別子を生成します；

  • モニター作成プロセス中の場合のみ、以下の文字 a-z, 0-9, _ を使用してNQL IDを変更できます。 つまり、モニターを作成した後は、このフィールドの編集はできません；

  • このモニターをNQLを使用してクエリするためにNQL IDを使用します。

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

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

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

NQLクエリと条件の定義

新しいモニター構成ページから、クエリと条件タブで：

1. モニターするメトリックを定義するために、NQLクエリ入力フィールドを使用します。 NQLは、1つまたは複数のメトリックを選択し、where句を使用して範囲を指定し、時間の集計とグループ化に使うbyキーワードを使用して、適切な粒度でアラートコンテキストを定義するのに役立ちます；

2. 必要に応じて、Investigationsで表示ボタンを使用して、InvestigationsモジュールでNQLクエリの結果を確認します。

モニタークエリのための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クエリで計算された各メトリクスを使用して条件を絞り込みます。

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

アラートのスケジューリング頻度を設定するとき、例えば7日に設定すると、その月の1日から毎月7日ごとにモニターがアラートを評価します。

これはシステムが予想より早くアラートをトリガーする原因となる可能性があります。たとえば、特定の月の28日にアラートが1回トリガーされても、翌月の1日にも再度トリガーされることがあります。

スケジューリング頻度は、システムがトリガー条件を評価する頻度を決定します。 可能な時間枠は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日間

アラートの自動回復オプションを選択する；

多くのアラートシナリオでは、モニターが72時間回復期間を延長する必要がありません。これはトリガー条件が正規化されているためです；

これらの場合、モニターの最初の評価が非アクティブのためデータを返さないときにアラートを即座に回復するために、クエリと条件タブの高度なモニター構成の自動回復オプションを使用します。

それとは対照的に、週末の休みを考慮し、非アクティブな期間中にアラートをそのままにしておくために新しいアラートを閉じるのではなく開けたままにしておくためには例えば72時間待つことを決めることができます；

---

VDI用カスタムモニターの作成

内蔵のNexthink Library VDIモニターをアラートに使用するには、Nexthink VDIエクスペリエンスが必要です。

仮想デスクトップ（VDI）の内蔵モニターは部分的なカスタマイズとともに即時使用の機能を提供しますが、特定の組織のニーズに合わせたカスタムVDIモニターを作成することもできます。

カスタムVDIモニターを作成する際は次のことを考慮してください：

• カスタムVDIモニターの唯一の利用可能なオプションであるスケジュールトリガーを、最小粒度15分単位でトリガーに設定します。

• クエリと条件にVDIに関連するNQLテーブルとフィールドを使用します。 たとえば、以下のクエリは、デスクトッププールごとの平均ネットワーク待ち時間を計算します。

  • 必要に応じて、プール内の平均待ち時間がしきい値を超えたときにアラートを有効にするトリガー条件を追加できます。たとえば、50msを超えた場合です。

session.vdi_events during past 15min
| where session.vdi_event.network_rtt != null
| summarize average_network_latency = network_rtt.avg(), 
total_number_of_sessions = vdi_session.count() by vdi_session.desktop_pool

---

関連トピック

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

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

• Nexthink Library

• 製品構成