カスタムモニターの作成
アラート用のカスタムモニターを作成するには、ナビゲーションパネルの「アラートと診断」> 「アラート管理」から次の手順を実行してください:
画面右上の「新しいモニター」ボタンをクリックし、モニター構成を開きます。
NQL クエリと条件タブを定義します。
トリガー条件とスケジューリング頻度を含めます。
プロアクティブアラート管理のためにメールまたはWebhookで通知を設定します。
一般的なモニター設定の構成
「新しいモニター」構成ページで、「一般」タブの以下のフィールドを入力します:

タイプ: カスタムモニターは、NQLクエリで定義されたメトリクスの値を指定したしきい値と比較するためのメトリックしきい値検出モードを提供します。 たとえば、バイナリを実行しているデバイスの20%がクラッシュを経験したとき、モニターがアラートをトリガーします。
名前: モニターに意味のある名前をつけてください。 システムはこの名前を使用して通知を送信し、アラート概要ページでモニターを視覚化します。
NQL ID: システムはモニター名前から自動的に一意の識別子を生成します。
モニター作成プロセス中にのみ、次の文字を使用してNQL IDを変更できます:
a-z, 0-9, _
。 つまり、モニターを作成した後にこのフィールドを編集することはできません。NQLを使用してこのモニターをクエリするには、NQL IDを使用します。
削除されたモニターに関連付けられているイベントがシステム内にまだ存在する限り、削除されたモニターで使用されたNQL IDのモニターを作成できません(最大30日)。
優先度: 優先度レベルを設定してください。 デフォルトレベルは中間です。
タグ: モニター用のカスタムタグを作成します。 これにより、概要ダッシュボードやWebhook統合でタグを使用してアラートをフィルタリングできます。 現在、各モニターには最大10個のタグがあります。
NQLクエリと条件を定義する
新しいモニターの設定ページにあるクエリと条件タブから:
NQLクエリ入力フィールドを使用して監視するメトリクスを定義します。 NQLは、1つまたは複数のメトリクスの選択を容易にし、
where
句を使用してスコープを指定し、時間の集約とグループ化のためにby
キーワードを使用してアラートコンテキストの適切な粒度を定義します。必要に応じて、調査で表示ボタンを使用して、調査モジュールでNQLクエリの結果を表示します。

モニタークエリに関するNQLのルールと制限事項
モニターをサポートするためには、NQLクエリはいくつかのルールに従う必要があります。
モニターのNQLクエリは、計算されたメトリクスまたは集約されたメトリクスを含む必要があります。つまり、すべてのクエリはモニターと互換性のある
compute
またはsummarize
句を必要とします。
オプションで、複数の条件を設定してアラートをトリガーするために、クエリに1つ以上の計算または集約されたメトリクスを含めることが可能です。
少なくとも1つのメトリクスを使用して監視条件の閾値を設定してください。 元のクエリにメトリクスが含まれていない場合は、追加のメトリクスを作成してください。
モニターと互換性がありません:
モニターと互換性があります:
NQLレベルで評価されたメトリクスに条件を追加しないでください。 代わりに、トリガー条件セクションを使用して条件を定義します。
不正解のモニターNQLクエリ:
条件付き正しいモニターNQLクエリ:
where
句を使用してモニターのスコープを特定の場所、アプリケーション、その他のカテゴリに絞ります。
summarize... by
を使用してアラートコンテキストの適切な粒度を定義します。 以下の例では、バイナリ名ごとに1つのアラートがトリガーされます。
複数のデバイスに影響を与える問題の検出についてはこちらをご覧ください。また、単一のデバイスまたはユーザーへの影響についてはこちらをご覧ください。
トリガー条件の定義
新しいモニターの設定ページから、クエリと条件タブで、アラートをアクティブにするトリガー条件を定義します。
NQLクエリで計算された各メトリクスを使用して条件を絞り込みます。

スケジューリング頻度の定義
アラートのスケジューリング頻度の設定、例えば7日間として設定すると、モニターは毎月1日に開始するアラートを評価します。
これにより、システムが期待よりも早くアラートをトリガーする可能性があります。例として、特定の月の28日にアラートが1回、翌月の1日に再度トリガーされることがあります。
スケジュール頻度は、システムがトリガー条件を評価する頻度を決定します。 可能な時間枠は、15分、1時間、3時間、6時間、12時間、24時間、48時間、7日です。 ただし、これらの時間枠の利用可能性は「過去の」条件とモニターのNQLクエリで照会されたイベントに依存します。
モニタークエリの設定がスケジュール頻度にどのように影響するかを理解するため、以下の例を参照してください。
15分
7日
24時間
7日
15分
7日
12時間
7日
15分
7日
12時間
7日
7日
7日
アラートの自動回復オプションを選択する
多くのアラートシナリオでは、トリガー条件が正常化されているため、モニターは72時間回復期間を延長する必要はありません。
そのような場合には、モニターの初回評価でデータがないためにアラートが発生しない場合、高度なモニター設定のクエリと条件タブの自動回復オプションを使用して、アラートを即座に回復します。
反対に、たとえば週末の休暇を考慮して、この無活動期間中にアラートを閉じる代わりに、72時間待ってアラートを開いたままにすることを選択するかもしれません。
VDI用のカスタムモニターを作成する
内蔵のNexthink Library VDIモニターをアラートに使用するには、Nexthink VDIエクスペリエンスが必要です。
仮想デスクトップ(VDI)用の組み込みモニターは、一部のカスタマイズが可能な標準機能を提供しますが、特定の組織ニーズに応じてカスタムVDIモニターを作成することもできます。
カスタムVDIモニターを作成する際は次の点を考慮してください:
トリガーは、カスタムVDI モニターの唯一の選択肢であるスケジュールトリガーに設定し、最小5分間隔を指定してください。
クエリと条件では、VDI関連のNQLテーブルおよびフィールドを使用します。 例えば、次のクエリはデスクトッププールごとの平均ネットワークレイテンシーを計算します。
必要に応じて、プール内の平均レイテンシーがしきい値(例: 50ms)を超えたときにアラートを発行するトリガー条件を追加できます。
関連トピック
Last updated
Was this helpful?