組み込みモニターのカスタマイズ
システム と ライブラリのモニターをカスタマイズし、アラートの関連性を高めるための、より複雑なモニター設定の出発点として使用します。
内蔵モニターをカスタマイズするには、ナビゲーションパネルのAlerts and Diagnostics > アラートを管理から:
システムまたはライブラリモニターのアクションメニューを開き、構成を選択します。
一般タブのフィールドをカスタマイズします。
定義されたNQLクエリと条件タブを適応させます。
トリガー条件、フィルター、‘グループ化’句およびスケジューリング頻度を含みます。
プロアクティブなアラート管理のためのメールまたはウェブフックによる通知の設定を確認します。

組み込みのモニターを使用する前に、
次のライブラリモニターには、コラボレーション エクスペリエンス拡張製品が必要です。
コール品質 - Zoom の悪いコール数(増加)
コール品質 - Teams の悪いコール数(増加)
以下のシステムモニターは、完全にInfinityに移行したNexthinkインスタンスを必要とします:
バイナリ接続確立時間の増加
バイナリの接続失敗比率の増加
Nexthinkからのライブラリモニターの更新は、あなたが行ったカスタマイズを保持しません。
システムとライブラリモニターを含む組み込みのモニターの特定のフィールドの編集を、システムが防いでいます。
組み込みモニターの全般フィールドをカスタマイズする
モニター構成ページで、全般タブの以下のフィールドを確認してください。
組み込みのモニターは、以下のタイプの検出モードを提供します:
システムはモニター名を使用して、アラート概要ページに通知を送信し、モニターを視覚化します。
既存のモニターのためのNQL IDを編集することはできませんが、このIDを使用してNexthink内でモニターをクエリすることができます。
組み込みモニターの既定のクエリと条件の調整
モニター構成ページから、クエリと条件タブのフィールドを適応させます。
必要に応じて、Show in Investigationsボタンをクリックしてクエリ調査結果を表示します。
アラートを起動する既存のトリガー条件をカスタマイズします。 モニターの検出タイプに応じて、トリガー条件が敏感になります:
監視する、または除外する特定のアプリケーションやデバイスを含めたり、除外するためにフィルタを使用して
where条件を追加します—最大20プロパティ値フィルタは、ユーザー、デバイス、アプリケーション、バイナリといったオブジェクトを評価する組み込みモニタにのみ使用可能です。
組織階層の詳細を含むデバイスのパフォーマンスや通話品質の問題の監視における**「グループ化」条件**を追加します。カスタムレベルや位置の内訳も含めます。
デバイスパフォーマンスモニターにおいて、オプションの**「グループ化」**として場所ごとの内訳を使用するには、製品コンフィギュレーションでジオロケーションを有効にする必要があります。
組み込みモニターの固定されたスケジューリング頻度を確認して、システムがトリガー条件を評価する頻度を決定します。 詳細については、アラートのFAQドキュメントを参照してください。アラートのトリガーのためのデータポイントのスケジューリングについて詳しく学べます。
アラートのスケジューリング頻度、例として7日間とは、モニターがそれぞれの月の1日から始まって7日ごとにアラートを評価することを意味します。
これによりシステムが月ごとの28日に1つのアラート、次の月の1日に再びアラートをトリガーするなど、予期しない速さで警告をトリガーすることがあります。
アラートの自動復旧オプションを選択します。 多くのアラートシナリオでは、組み込みモニターはトリガー条件が正規化されているため、72時間の回復期間を延長する必要はありません。
これらのケースでは、モニターの最初の評価がアクティビティのないためにデータを返さない場合、アラートを直ちに回復します。
逆に、例えば週末の休暇を考慮し、非アクティブ期間中にアラートを開いたままにして、新しい警告を閉じたり開いたりしないために、72時間待つことを選択するかもしれません。
関連トピック
Last updated
Was this helpful?