カスタムモニターの作成
Last updated
Was this helpful?
Last updated
Was this helpful?
アラートのカスタムモニターを作成するには、ナビゲーションパネルの Alerts と Diagnostics > アラート管理 に進みます：
ページの右上隅にある 新しいモニター ボタンをクリックして、モニター構成を開きます。
NQL クエリと条件タブを定義します。
トリガー条件とスケジューリング頻度を含めます。
事前対応型アラート管理のためにメールまたはWebhooksによる通知を設定します。
新しいモニター構成ページから、一般タブの次のフィールドに入力します：
タイプ: カスタムモニターは、NQLクエリで定義されたメトリックの値をユーザーが定義したしきい値と比較するためのメトリックしきい値検出モードを提供します。 例えば、バイナリを実行しているデバイスの20%がクラッシュを経験したときにモニターがアラートをトリガーします。
名前: モニターに意味のある名前を付けてください。 システムはこの名前を使用して通知を送信し、アラートの概要ページでモニターを視覚化します。
NQL ID: システムはモニターの名前から自動的に一意の識別子を生成します；
モニター作成プロセス中の場合のみ、以下の文字 a-z, 0-9, _ を使用してNQL IDを変更できます。 つまり、モニターを作成した後、このフィールドを編集することはできません；
このモニターをNQLを使用してクエリするためにNQL IDを使用します。
削除されたモニターに関連付けられたイベントがシステムに残っている場合（最大30日間）、削除されたモニターのNQL IDを使用してモニターを作成することはできません。
優先度: 優先度レベルを設定します。 デフォルトのレベルは中位です。
タグ: カスタムタグをモニターに作成します。 これにより、OverviewダッシュボードとWebhooksインテグレーションでタグを使用してアラートをフィルタリングできます。 現在、モニターごとのタグの上限は10個です。
新しいモニター構成ページから、クエリと条件タブで：
モニターするメトリックを定義するために、NQLクエリ入力フィールドを使用します。 NQLは、1つまたは複数のメトリックを選択し、where句を使用して範囲を指定し、時間の集計とグループ化に使うbyキーワードを使用して、適切な粒度でアラートコンテキストを定義するのに役立ちます；
必要に応じて、Investigationsで表示ボタンを使用して、InvestigationsモジュールでNQLクエリの結果を確認します。
モニターをサポートするためには、NQLクエリはいくつかのルールに従う必要があります:
モニター用のNQLクエリは計算済みまたは集約されたメトリクスを含む必要があり、すべてのクエリはモニターに対応するためにcomputeまたはsummarize句を要求します。
クエリで複数の条件を設定してアラートをトリガーできるように、追加の計算済みまたは集約されたメトリクスをクエリに含めることもできます。
監視条件のしきい値を設定するために、少なくとも1つのメトリクスを使用します。 元のクエリにメトリクスが含まれていない場合は、追加のメトリクスを作成します。
モニターと互換性がありません:
モニターと互換性があります:
NQLレベルで評価されるメトリクスに条件を追加しないでください。 代わりに、トリガー条件 セクションを使用して条件を定義してください。
誤ったモニターNQLクエリ:
条件を含む正しいモニターNQLクエリ:
where句を使って特定の場所、アプリケーション、その他のカテゴリにモニターの範囲を絞り込みます。
summarize... by を使用して、アラートコンテキストの正しい粒度を定義します。 次の例では、1つのバイナリ名ごとに1つのアラートが発動されます。
複数のデバイスに影響を与える問題の検出および単一のデバイスまたはユーザーに影響を与える問題の検出ドキュメントを参照して、NQLクエリを定義する方法をさらに学びましょう。
新しいモニター構成ページから、クエリと条件タブで、アラートをアクティブにするトリガー条件を定義します；
NQLクエリで計算された各メトリクスを使用して条件を絞り込みます。
アラートのスケジューリング頻度を設定するとき、例えば7日に設定すると、その月の1日から毎月7日ごとにモニターがアラートを評価します。
これはシステムが予想より早くアラートをトリガーする原因となる可能性があります。たとえば、特定の月の28日にアラートが1回トリガーされても、翌月の1日にも再度トリガーされることがあります。
スケジューリング頻度は、システムがトリガー条件を評価する頻度を決定します。 可能な時間枠は15分、1時間、3時間、6時間、12時間、24時間、48時間、7日間です。 しかし、これらの時間枠の利用可能性は during past句およびモニターのNQLクエリで照会されたイベントによって異なります。
モニタークエリの設定がスケジューリング頻度の利用可能性をどのように決定するかを理解するには、次の例を参照してください。
15分
7日
24時間
7日
15分
7日
12時間
7日
15分
7日
12時間
7日
7日
7日間
多くのアラートシナリオでは、モニターが72時間回復期間を延長する必要がありません。これはトリガー条件が正規化されているためです；
これらの場合、モニターの最初の評価が非アクティブのためデータを返さないときにアラートを即座に回復するために、クエリと条件タブの高度なモニター構成の自動回復オプションを使用します。
それとは対照的に、週末の休みを考慮し、非アクティブな期間中にアラートをそのままにしておくために新しいアラートを閉じるのではなく開けたままにしておくためには例えば72時間待つことを決めることができます；
内蔵のNexthink Library VDIモニターをアラートに使用するには、Nexthink VDIエクスペリエンスが必要です。
仮想デスクトップ（VDI）の内蔵モニターは部分的なカスタマイズとともに即時使用の機能を提供しますが、特定の組織のニーズに合わせたカスタムVDIモニターを作成することもできます。
カスタムVDIモニターを作成する際は次のことを考慮してください：
カスタムVDIモニターの唯一の利用可能なオプションであるスケジュールトリガーを、最小粒度15分単位でトリガーに設定します。
クエリと条件にVDIに関連するNQLテーブルとフィールドを使用します。 たとえば、以下のクエリは、デスクトッププールごとの平均ネットワーク待ち時間を計算します。
必要に応じて、プール内の平均待ち時間がしきい値を超えたときにアラートを有効にするトリガー条件を追加できます。たとえば、50msを超えた場合です。
モニターを作成する方法の1つは、以前にエクスポートした設定ファイルからインポートすることです。
削除されたモニターとまだ関連付けられているイベントがシステムに残っている場合、その削除されたモニターと同じNQL IDを持つモニターのインポートはシステムにより許可されません。 アラートイベントはPlatformで最大30日間保存されます。
モニターのインポート中に_NQL IDは既存のアラートを持つ削除済みモニターで既に使用されています_メッセージが表示された場合、エクスポートファイルを変更して新しいNQL IDを作成してください。
関連トピック
