サポート (英語のみ)

カスタムモニターの作成

注意: この文書は利便性と情報提供を目的に翻訳されたものです。 この翻訳とオリジナルの英語版間に差異や矛盾がある場合、オリジナルの英語版が優先されます。 この翻訳から生じる可能性のある誤りや誤解についての責任は負いかねます。

Nexthinkは、より広範な機能を提供する組み込みモニターから始めることを推奨しています 組み込みモニターのカスタマイズ。 また、ローカルデバイスから事前設定済みのインポートモニターを利用することもできます。

アラート用のカスタムモニターを作成するには、ナビゲーションパネルの「アラートと診断」> 「アラート管理」から次の手順を実行してください：

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

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

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

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

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

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

「新しいモニター」構成ページで、「一般」タブの以下のフィールドを入力します：

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

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

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

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

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

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

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

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

NQLクエリと条件を定義する

新しいモニターの設定ページにあるクエリと条件タブから:

  1. NQLクエリ入力フィールドを使用して監視するメトリクスを定義します。 NQLは、1つまたは複数のメトリクスの選択を容易にし、where句を使用してスコープを指定し、時間の集約とグループ化のためにbyキーワードを使用してアラートコンテキストの適切な粒度を定義します。

  2. 必要に応じて、調査で表示ボタンを使用して、調査モジュールで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. オプションで、複数の条件を設定してアラートをトリガーするために、クエリに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

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

トリガー条件の定義

新しいモニターの設定ページから、クエリと条件タブで、アラートをアクティブにするトリガー条件を定義します。

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

Trigger conditions

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

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

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

スケジュール頻度は、システムがトリガー条件を評価する頻度を決定します。 可能な時間枠は、15分、1時間、3時間、6時間、12時間、24時間、48時間、7日です。 ただし、これらの時間枠の利用可能性は「過去の」条件とモニターの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日

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

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

そのような場合には、モニターの初回評価でデータがないためにアラートが発生しない場合、高度なモニター設定のクエリと条件タブの自動回復オプションを使用して、アラートを即座に回復します。

反対に、たとえば週末の休暇を考慮して、この無活動期間中にアラートを閉じる代わりに、72時間待ってアラートを開いたままにすることを選択するかもしれません。

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

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

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

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

  • トリガーは、カスタムVDI モニターの唯一の選択肢であるスケジュールトリガーに設定し、最小5分間隔を指定してください。

  • クエリと条件では、VDI関連のNQLテーブルおよびフィールドを使用します。 例えば、次のクエリはデスクトッププールごとの平均ネットワークレイテンシーを計算します。

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

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

関連トピック

Last updated

Was this helpful?