サポート (英語のみ)

カスタムモニターの作成

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

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

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

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

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

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

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

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

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

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

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

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

メトリックのしきい値

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

メトリックの変化

メトリックの変化は、現在のメトリック値が7日間のグローバル平均から設定されたしきい値を超えて異なる場合にトリガーされます。

メトリックの季節的変化

メトリックの季節変動 はアラートをトリガーします。これは、現在のメトリック値が設定済みの標準偏差バンドに基づいて、過去7日間の時刻別ベースラインを外れた場合です。

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

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

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

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

    • モニター作成中にNQL IDを編集できるのは、\n a-z, 0-9, _ の文字だけです。

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

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

  • タグ: モニター用のカスタムタグを作成します。 これは、Alerts overviewや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. アラートをアクティブにする、トリガー条件を定義します。 トリガー条件は、モニターの選択された検出タイプ に敏感です。 各メトリックをNQLクエリで計算して、条件を絞り込みます。

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

メトリックしきい値検出を持つモニターのトリガー条件では、設定した値に対して演算子—以上、以下—に基づいてモニターがアラートをトリガーします。

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

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

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

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

  • 追加のトリガー条件で、定義された閾値に対して—以上、以下—の関係演算子に基づいてアラートをアクティブにします。

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

以下の例では、最初のトリガー条件は、CPU使用率 が過去7日間のメトリック平均を倍にした場合にアラートをトリガーします。

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

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

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

  • 最初のトリガー条件は、過去7日間の時刻別ベースライン から計算された感度バンドまたは範囲を設定します。 モニターは、その時間枠のために選択された標準偏差範囲を外れた場合にアラートをトリガーします：

    • わずかに = 1標準偏差 (±1σ)

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

    • 非常に = 3倍の標準偏差 (±3σ)

  • 追加のトリガー条件で、定義された閾値に対して—以上、以下—の関係演算子に基づいてアラートをアクティブにします。

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

以下の例では、最初のトリガー条件は、失敗した接続の割合 がベースラインから2つの標準偏差 (±2σ) を外れた場合にアラートをトリガーします。

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

    • 可能な時間枠は、15分、1時間、3時間、6時間、12時間、24時間、48時間、7日です。 これらのタイムフレームは、モニターの NQLクエリ ( 過去節) と設定された検出方法に依存します。

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

これにより、システムが期待よりも早くアラートをトリガーする可能性があります。例として、特定の月の28日にアラートが1回、翌月の1日に再度トリガーされることがあります。

NQLクエリが利用可能なスケジュール時間枠にどのように影響するか?

スケジュール頻度時間枠の可用性は、during past句およびモニタのNQLクエリで定義されたイベントに依存します。

モニタークエリの設定がスケジュール頻度にどのように影響するかを理解するため、以下の例を参照してください。

過去の監視イベント
最小頻度
最大頻度
デバイスのパフォーマンス。過去24時間の起動

15～分

7日間

device_performance.boots during past 7d

24時間

7日間

セッション。過去1時間のイベント

15～分

7日間

セッション。過去24時間のイベント

12時間

7日間

execution.events during past 1h

15分

7日間

実行。過去24時間のイベント

12時間

7日間

実行。過去7日間のイベント

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テーブルおよびフィールドを使用します。 例えば、次のクエリはデスクトッププールごとの平均ネットワークレイテンシーを計算します。

    • 必要に応じて、プール内の平均レイテンシーがしきい値（例: 50ms）を超えたときにアラートを発行するトリガー条件を追加できます。

セッション。過去15分のvdiイベント
| session.vdi_event.network_rtt が null 以外の場合
| 平均ネットワークレイテンシーを集計してネットワーク_rtt.avg()、
| vdi_session.desktop_poolごとにセッション数をカウントします。

関連トピック

Last updated

Was this helpful?