カスタムモニターの作成

カスタムモニタを作成するには、ナビゲーションパネルのアラートと診断 > アラートの管理から操作します。

1. 画面右上の「新しいモニター」ボタンをクリックし、モニター構成を開きます。

2. 一般タブのフィールドに入力してください。

3. NQLクエリと条件タブを定義してください。

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

4. プロアクティブアラート管理のためにメールまたはWebhookで通知を設定します。

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

最初からモニターを作成する代わりに、Nexthinkは組み込みモニターをカスタマイズすることを推奨しています。組み込みモニターはカスタムモニターよりも多くの機能を提供します。

新規モニタ設定ページから一般タブのフィールドを以下のように入力します。

イベントトリガーとグローバル検出は、組み込みモニター（システムモニター、またはNexthinkライブラリーからインストールされたもの）でのみ利用可能です。

• トリガー: カスタムモニターは、定期的なチェックに使用されるスケジュールトリガー方法を提供します。 特定の間隔をスケジュール頻度セクションのクエリと条件タブで設定します。

• タイプ: カスタムモニタは以下のタイプの検出モードを提供します。

メトリックのしきい値

メトリックのしきい値は、1つ以上のメトリックの値がユーザー定義のしきい値に達するとアラートをトリガーします。

メトリックの変化

メトリックの変更は、現在のメトリック値が7日間のグローバル平均と異なる場合にトリガーされます。詳細はこちらを参照してください。

メトリックの季節的変化

メトリック季節変動は、現在のメトリック値が直近7日間の時刻別基準値から外れる場合にアラートをトリガーします。これは設定された標準偏差帯に基づいています。

最大5つのカスタムモニターをメトリックの変化またはメトリックの季節変動を使用して構成できます。

最大50個のモニターを作成できます。

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

• NQL ID: システムはモニタ名から自動的に一意の識別子を生成します。 このモニタをNexthink内でクエリするためにNQL IDを使用します。

  • NQL IDはモニター作成時にのみ編集可能で、a-z、0-9、_の文字を使用してください。

  • 削除されたモニターに関連付けられているイベントがシステム内にまだ存在する限り、削除されたモニターで使用されたNQL IDのモニターを作成できません（最大30日）。

• 優先度: 優先度レベルを設定してください。 デフォルトレベルは中間です。

• タグ: モニター用のカスタムタグを作成します。 これにより、アラート概要およびWebhookの統合でアラートをフィルタリングすることが可能です。 現在、モニターごとに最大で10個のタグを定義できます。

カスタムモニタのNQLクエリと条件の定義

モニター構成ページから、クエリと条件 タブに以下の項目を入力します。

必要に応じて、調査で表示ボタンをクリックしてクエリ調査結果を表示します。

1. 監視するメトリックを定義するために、NQLクエリを書いてください。 NQLを使用して、次のことが可能です:

   • 1つまたは複数のメトリックを選択します。

   • where句を使って範囲を指定します。

   • 時間集計とグループ化のためのbyキーワードを使用して、アラートの粒度を定義します。

システムは、10000を超える結果コンテキスト/グループを計算するNQLクエリ用のエラーメッセージを表示します。

これらの場合、各グループは独自の[ベースライン](../../getting-started-with-alerts.md#baseline-computation-depending-on-the-aler t-detection-mode)を必要とするため、粒度を減らし、'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. オプションで、複数の条件を設定してアラートをトリガーするために、クエリに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つのアラートがトリガーされます。

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

複数のデバイスに影響を与える問題の検出についてはこちらをご覧ください。また、単一のデバイスまたはユーザーへの影響についてはこちらをご覧ください。

1. アラートをアクティブにする、トリガー条件を定義します。 トリガー条件は、モニターの選択した検出タイプに敏感です。\n条件を絞り込むために、NQLクエリで計算された各メトリックを使用してください。

メトリックしきい値のトリガー条件

メトリックしきい値の検出でのトリガー条件において**、モニターはメトリック値が指定された値より大きいまたは等しい、または小さいまたは等しい場合にアラートをトリガーします。

すべてのトリガー条件が満たされると、システムはアラートをトリガーします。

メトリック変化のトリガー条件

メトリック変化 検出を持つモニターのための トリガー条件 ：

• 最初のトリガー条件は偏差ルール—高いか低い—を表しており、現在のメトリックを基準値（7日間の全球平均）と比較しています。

• 追加のトリガー条件は、値が指定されたしきい値以上またはそれ以下であるときに、アラートを有効にする条件を定義します。

すべてのトリガー条件が満たされると、システムがアラートをトリガーします。

以下の例では、最初のトリガー条件により、CPU使用率の値が過去7日間のメトリック平均の2倍になるとアラートが起動します。

これらのトリガー条件は、スケジュールおよびイベントトリガーモニターの両方に適用されます。

メトリック季節変化のトリガー条件

メトリック季節変動検出を持つモニターのトリガー条件において:

• 最初のトリガー条件は、直近7日間の時刻別基準値から計算された感度帯または範囲を設定します。 モニターは、現時点のメトリック値がその時間枠の選択された標準偏差範囲から外れるときにアラートをトリガーします:

  • わずかに ＝ 標準偏差1（±1σ）

  • 適度に = 2倍の標準偏差 (±2σ)

  • 高度に = 標準偏差の三倍（±3σ）

• 追加のトリガー条件は、値が指定されたしきい値以上またはそれ以下であるときに、アラートを有効にする条件を定義します。

すべてのトリガー条件が満たされると、システムはアラートを発します。

以下の例では、最初のトリガー条件は、接続の失敗率が基準値から2標準偏差（±2σ）帯域外の場合にアラートを作動させます。

1. モニターのスケジューリング頻度を設定して、システムがトリガー条件を評価する頻度を決定します。

   • 可能なタイムフレームは15分、1時間、3時間、6時間、12時間、24時間、48時間、そして7日です。 これらのタイムフレームは、モニターNQLクエリ内（過去句）、および構成済みの検出方法に依存します：

     • メトリックの変化については、スケジューリング頻度は15分から数日にわたります。

     • メトリックの季節変動の場合、最大スケジューリング頻度は24時間です。1日以上の頻度では同じスロットの平均を過去7日間で計算することには寄与しません。

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

これによりシステムが予想より早くアラートを発する可能性があります。特定の月の28日に1つのアラートが、翌月の1日に再び発されることがあります。

NQLクエリ は利用可能なスケジューリングタイムフレームにどのように影響しますか？

スケジューリング頻度のタイムフレームの可用性は、過去句およびモニター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日間
session.vdi_events during past 1h	15分	7日間
session.vdi_events during past 7d	24時間	7日間

1. アラートの自動復旧オプションを選択してください。 多くのアラートシナリオでは、トリガー条件が標準化されているため、モニターが72時間の回復期間を延長する必要がありません。

   • このような場合、モニターの最初の評価で無活動によるデータが返されなかった場合は、直ちにアラートを回復します。

   • 逆に、たとえば週末の休暇に対応するために72時間待つことを決定し、この無活動期間中にアラートを開いたままにすることもできます。」

---

仮想デスクトップ（VDI）のカスタムモニター作成

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

仮想デスクトップ（VDI）用の組み込みモニターは、一部のカスタマイズが可能な標準機能を提供しますが、特定の組織ニーズに応じてカスタムVDIモニターを作成することもできます。

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

• カスタムVDIモニターでは、最小粒度15分のスケジュールトリガーのみが利用可能です。

• クエリと条件でVDI関連のNQLテーブルおよびフィールドを使用します。 以下のクエリ例では、デスクトッププールごとに平均ネットワーク遅延を計算します。

  • 必要に応じて、プール内の平均レイテンシーが閾値を超えたときにアラートを作動させるトリガー条件を追加できます。たとえば、50ミリ秒です。

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

• 製品設定