組み込みモニターのカスタマイズ
正確性を確保するために、システムは仮想デスクトップ(VDI)のライブラリモニターを含む、内蔵モニターの特定のフィールドの編集を防ぎます。
ただし、特定の制限の範囲内でカスタムVDIモニターを作成できます。
システムおよびライブラリモニターをカスタマイズして、アラートの関連性を高めるためのより複雑なモニター構成の出発点として使用します。 Nexthinkが元のライブラリモニターを更新しても、カスタマイズした変更は保持されません。
内蔵モニターをカスタマイズするには、ナビゲーションパネルのAlerts and Diagnostics > アラートを管理から:
トリガー条件、フィルター、‘グループ化’句およびスケジューリング頻度を含みます。
プロアクティブなアラート管理のためのメールまたはウェブフックによる通知の設定を確認します。

内蔵モニターの使用の前提条件と依存関係
以下のライブラリモニターにはCollaboration Experience拡張製品が必要です。
コール品質 - Zoom の悪いコール数(増加)
コール品質 - Teams の悪いコール数(増加)
以下のシステムモニターは、完全にInfinityに移行されたNexthinkインスタンスを必要とします。
バイナリ接続確立時間の増加
バイナリの接続失敗比率の増加
場所別の内訳をデバイスパフォーマンスモニターにオプションの「グループ化」として使用するには、製品構成ページの管理モジュールにあるジオロケーションを有効にする必要があります。
内蔵モニターの一般フィールドをカスタマイズする
モニター構成ページから、一般タブの以下のフィールドを確認してください:
タイプ:モニターが使用している検出モードの種類を表示します。内蔵モニターでは次の検出モードを提供します。
メトリック閾値は、1つ以上のメトリックの値がユーザー定義の閾値に達したときにアラートをトリガーします。
メトリック変更は、現在のメトリック値が基準ベースライン(過去7日間に取得されたメトリック値の平均)と異なる場合にアラートをトリガーします。
メトリック季節変動は、現在のメトリック値が期待される平均範囲を超えて逸脱したときにアラートをトリガーします。これは、過去7日間に収集された値の標準偏差を使用して計算されます。
グローバル検出は、特定の数のデバイスが他のバージョンや構成よりもパフォーマンスが劣る特定のバイナリバージョンまたはバイナリ構成を使用するときにアラートをトリガーします。 このアラートの閾値を自社内で調整してください。
名前:内蔵モニターの名前を表示。 システムはこの名前を使用して通知を行い、アラート概要ページでモニターを可視化します。
NQL ID:モニターのNQL IDを表示。 NQLを使用してこのモニターをクエリするのに使用します。
グローバル問題検出タイプはNexthinkを使用しているすべての組織から匿名化されたデータに基づいているため、NQLクエリを必要としません。

事前定義されたクエリと条件の適応
モニター構成ページから、クエリと条件タブの以下のフィールドを適応します:
内蔵モニターは、評価するメトリックを決定するために事前定義されたクエリを使用します。 Show in Investigations ボタンをクリックすることで、直接Investigationsでクエリを表示できます。

設定されたトリガー条件の強化
アラートを起動する内蔵モニターの既存のトリガー条件をカスタマイズします。 以下を考慮してください:
各メトリックの条件はNQLクエリで計算されます。
メトリック変更 型のモニターでは、最初の条件のみがメトリックの変更を確認し、それ以外の条件はすべて閾値と比較します。
内蔵モニターでは、いくつかの条件が事前構成されていますが、組織のニーズに合わせて調整できます。
複数のメトリック閾値を使用することにより、アラートの関連性を高めることができます。 例えば、サービス利用が少ないときや、少数のデバイスに影響が及んだ場合にアラートが発生しないようにします。
閾値を定義する際には、以上または以下を選択できます。
設定されたフィルターの強化
特定のアプリケーションやデバイスを監視に含める、または除外するための追加フィルターを追加できます。 フィルタリングは、ユーザー、デバイス、アプリケーション、およびバイナリといったインベントリオブジェクトを評価する内蔵モニターでのみ利用可能です。
追加の「グループ化」句
デバイスのパフォーマンスや通話品質の問題を組織階層の詳細、およびカスタムレベルやロケーションの詳細ごとに追跡するモニターのためにメトリックを追加します。 グルーピングは、デバイスを評価する内蔵モニターでのみ利用可能です。
スケジューリング頻度の設定
時刻間隔は、システムがトリガー条件を評価する頻度を決定します。 内蔵モニターのスケジュール頻度は固定です。
アラートのスケジュール頻度、たとえば7日間のように、各月の1日から開始し、モニターがアラートを7日ごとに評価することを意味します。
これにより、システムが予想よりも早くアラートをトリガーする可能性があり、特定の月の28日にアラートが発生した後、翌月の1日に再度トリガーされるようなケースが起こるかもしれません。
アラートの自動回復オプションの選択
多くのアラートシナリオでは、トリガー条件が正規化されているため、モニターが72時間の回復期間を延長する必要はありません。
これらのケースでは、モニターの最初の評価で活動の欠如によりデータが返されない場合、アラートを即座に回復するために高度なモニター構成のクエリと条件タブの自動回復オプションを使用します。
逆に、たとえば週末休暇を考慮してアラートを閉じるのではなく、72時間待機して活動のない期間中にアラートを開いたままにしておくこともあります。
関連トピック
Last updated
Was this helpful?