アラーム サービスが過負荷状態になっています。

イベントの検出時：「大量のアラームが報告されたため、アラーム サービスが一時的に過負荷状態になっています。NSX ユーザー インターフェイスと GET /api/v1/alarms NSX API が新しいアラームの報告を停止しました。ただし、Syslog エントリと SNMP トラップ（有効になっている場合）は引き続き送信され、基になるイベントの詳細を報告します。アラームの大量発生の原因となっている問題が解決されると、アラーム サービスが新しいアラームの報告を再開します。」

イベントの解決時：「アラームの大量発生が収まりました。新しいアラームの報告が再開されました。」

NSX ユーザー インターフェイスの [アラーム] ページまたは GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED NSX API を使用して、すべてのアクティブ アラームを確認します。それぞれのアクティブ アラームに対して、アラームの推奨アクションに従い、根本原因を調査します。十分なアラームが解決されると、アラーム サービスが新しいアラームの報告を再開します。

特定のタイプのアラームが大量に検出されました。

イベントの検出時：「{event_id} アラームが大量に発生しているため、アラーム サービスはこのタイプのアラームの報告を一時的に停止しています。NSX UI と GET /api/v1/alarms NSX API は、これらのアラームの新しいインスタンスを報告しません。ただし、Syslog エントリと SNMP トラップ（有効になっている場合）は引き続き送信され、基になるイベントの詳細を報告します。{event_id} アラームの大量発生の原因となる問題が解決されると、新しい問題が再度検出されたときに、アラーム サービスが新しい {event_id} アラームの報告が開始します。」

イベントの解決時：「{event_id} アラームの大量発生が収まりました。このタイプの新しいアラームの報告が再開されました。」

NSX UI の [アラーム] 画面を使用するか、NSX API GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED を使用して、{event_id} タイプのアクティブ アラームをすべて確認してください。それぞれのアクティブ アラームに対して、アラームの推奨アクションに従い、根本原因を調査します。十分なアラームが解決されると、アラーム サービスが新しい {event_id} アラームの報告を再開します。

1 つ以上のモニタリング対象ログ ファイルに書き込むことができません。

イベントの検出時：「マネージャ ノード、グローバル マネージャ ノード、Edge ノード、Public Cloud Gateway ノード、KVM または Linux 物理サーバ ノードのモニター対象のログ ファイルの少なくとも 1 つに読み取り専用権限が設定されているか、ユーザー/グループの所有権が正しく設定されていません。あるいは、Windows 物理サーバ ノードにログ フォルダがないか、マネージャ ノード、グローバル マネージャ ノード、Edge ノードまたは Public Cloud Gateway ノードに rsyslog.log がありません。」

イベントの解決時：「マネージャ ノード、グローバル マネージャ ノード、Edge ノード、Public Cloud Gateway ノード、KVM または Linux 物理サーバ ノードのモニター対象のすべてのログ ファイルに正しいファイル権限と所有権が設定されています。また、Windows 物理サーバ ノードにログ フォルダが存在します。マネージャ ノード、グローバル マネージャ ノード、Edge ノードまたは Public Cloud Gateway ノードに rsyslog.log が存在します。」

1.マネージャ ノードとグローバル マネージャ ノード、Edge ノードと Public Cloud Gateway ノード、Ubuntu KVM ホスト ノードで、/var/log ディレクトリの権限が 775、所有権が root:syslog であることを確認します。Rhel KVM ノードと BMS ホスト ノードで、/var/log ディレクトリの権限が 755、所有権が root:root であることを確認します。
2.マネージャ ノードとグローバル マネージャ ノードで、/var/log の auth.log、nsx-audit.log、nsx-audit-write.log、rsyslog.log、syslog のファイル権限が 640、所有権が syslog:admin であることを確認します。
3.Edge ノードと Public Cloud Gateway ノードで、/var/log の rsyslog.log と syslog のファイル権限が 640、所有権が syslog:admin であることを確認します。
4.Ubuntu KVM ホスト ノードと Ubuntu 物理サーバ ノードで、/var/log の auth.log と vmware/nsx-syslog のファイル権限が 640、所有権が syslog:admin であることを確認します。
5.Rhel KVM ホスト ノードと Centos/Rhel/Sles 物理サーバ ノードで、/var/log の vmware/nsx-syslog のファイル権限が 640 で、所有権が root:root であることを確認します。
6.これらのファイルのいずれかの権限または所有権が間違っている場合は、chmod &ltmode&gt &ltpath&gt コマンドと chown &ltuser&gt:&ltgroup&gt &ltpath&gt コマンドを呼び出します。
7.マネージャ ノード、グローバル マネージャ ノード、Edge ノード、または Public Cloud Gateway ノードに rsyslog.log がない場合は、NSX CLI コマンド restart service syslog を呼び出します。これにより、ロギング サービスが再起動し、/var/log/rsyslog.log が再生成されます。
8.Windows 物理サーバ ノードで、ログ フォルダC:\ProgramData\VMware\NSX\Logs が存在することを確認します。存在しない場合は、Windows 物理サーバ ノードに NSX を再インストールしてください。

リモート ログ サーバの構成が正しくないため、ログ メッセージを配信できません。

イベントの検出時：「ログ メッセージをログ サーバ {hostname_or_ip_address_with_port} ({entity_id}) に配信できません。FQDN が解決できなか、TLS 証明書が無効な可能性があります。また、NSX アプライアンスに iptables ルールがない可能性もあります。」

イベントの解決時：ログ サーバ {hostname_or_ip_address_with_port} ({entity_id}) の構成に問題はありません。」

1.{hostname_or_ip_address_with_port} が正しいホスト名か、正しい IP アドレスとポートの組み合わせであることを確認します。
2.ログ サーバの指定で FQDN が使用されている場合は、NSX CLI コマンド nslookup &ltfqdn&gt を使用して FQDN が NSX アプライアンスから解決可能であることを確認します。解決可能でない場合は、正しい FQDN が指定され、FQDN に必要なエントリがネットワークの DNS サーバに存在することを確認します。
3.ログ サーバの構成で TLS が使用されている場合は、指定された証明書が有効であることを確認します。たとえば、ログ サーバが実際にその証明書を使用しているかどうか確認します。また、openssl コマンド openssl x509 -in &ltcert-file-path&gt -noout -dates を使用して、証明書が期限切れになっていないかどうか確認します。
4.NSX アプライアンスは、iptables ルールを使用して送信トラフィックを明示的に許可します。NSX CLI コマンド verify logging-servers を呼び出し、ログ サーバの iptables ルールが正しく構成されているかどうかを確認します。必要であれば、ログ サーバの iptables ルールを再構成します。
5.何らかの理由でログ サーバの構成に誤りがあった場合は、NSX CLI コマンド `del logging-server &lthostname-or-ip-address[:port]&gt proto &ltproto&gt level &ltlevel&gt` を実行して構成を削除し、正しい構成を再度追加します。

最小キャパシティのしきい値に違反しています。

イベントの検出時：「システムで {capacity_display_name} に定義されているオブジェクト数が {capacity_usage_count} に達しています。これは、{min_capacity_threshold}% の最小キャパシティのしきい値を超えています。」

イベントの解決時：「システムで {capacity_display_name} に定義されているオブジェクト数が {capacity_usage_count} に達しています。これは、{min_capacity_threshold}% の最小キャパシティのしきい値に達しているか、下回っています。」

NSX ユーザー インターフェイスの [キャパシティ] ページに移動し、現在の使用量としきい値の制限を確認します。現在の使用量が予期されるものである場合は、最小しきい値を増やすことを検討してください。現在の使用量が予期しないものである場合は、構成されたネットワーク ポリシーを確認して、使用量を最小しきい値以下に減らすようにしてください。

最大キャパシティのしきい値に違反しています。

イベントの検出時：「システムで {capacity_display_name} に定義されているオブジェクト数が {capacity_usage_count} に達しています。これは、{max_capacity_threshold}% の最大キャパシティのしきい値を超えています。」

イベントの解決時：「システムで {capacity_display_name} に定義されているオブジェクト数が {capacity_usage_count} に達しています。これは、{max_capacity_threshold}% の最大キャパシティのしきい値に達しているか、下回っています。」

NSX ユーザー インターフェイスの [キャパシティ] ページに移動し、現在の使用量としきい値の制限を確認します。現在の使用量が予期されるものである場合は、最大しきい値を増やすことを検討してください。現在の使用量が予期しないものである場合は、構成されたネットワーク ポリシーを確認して、使用量を最大しきい値以下に減らします。

最大キャパシティに違反しています。

イベントの検出時：「システムで {capacity_display_name} に定義されているオブジェクト数が {capacity_usage_count} に達しています。これは、サポートされている {max_supported_capacity_count} の最大数を超えています。」

イベントの解決時：「システムで {capacity_display_name} に定義されているオブジェクト数が {capacity_usage_count} に達しています。これは、サポートされている {max_supported_capacity_count} の最大数に達しているか、下回っています。」

作成される NSX オブジェクトの数が、NSX でサポートされている制限内であることを確認します。未使用のオブジェクトがある場合は、それぞれの NSX ユーザー インターフェイスまたは API を使用してシステムから削除します。すべてのマネージャ ノードまたは Edge ノードのフォーム ファクタを拡大することも検討してください。ただし、各ノード タイプのフォーム ファクタは同じにする必要があります。同じでない場合、展開された最小フォーム ファクタの容量制限が使用されます。

証明書が期限切れです。

イベントの検出時：「証明書 {entity_id} は期限切れです。」

イベントの解決時：「期限切れの証明書 {entity_id} が削除されたか、有効期限の問題が解決されました。」

現在、証明書を使用しているサービスが、期限切れでない新しい証明書を使用するように更新されていることを確認します。期限切れの証明書が使用されなくなったら、DELETE {api_collection_path}{entity_id} NSX API を呼び出して、これらの証明書を削除する必要があります。期限切れの証明書が NAPP プラットフォームで使用されていると、NSX と NAPP プラットフォーム間の接続が切断されます。接続を復旧するには、NAPP プラットフォームのトラブルシューティング ドキュメントを参照して、自己署名の NAPP CA 証明書を使用してください。

証明書がまもなく期限切れになります。

イベントの検出時：「証明書 {entity_id} はまもなく期限切れになります。」

イベントの解決時：「有効期限の近い証明書 {entity_id} が削除されたか、有効期限の問題が解決されました。」

現在、証明書を使用しているサービスが、有効期限が近くない新しい証明書を使用するように更新されていることを確認します。期限切れの近い証明書が使用されなくなったら、DELETE {api_collection_path}{entity_id} NSX API を呼び出して、これらの証明書を削除する必要があります。

証明書の期限切れが近づいています。

イベントの検出時：「証明書 {entity_id} の有効期限が近づいています。」

イベントの解決時：「有効期限の近い証明書 {entity_id} が削除されたか、有効期限の問題が解決されました。」

現在、証明書を使用しているサービスが、有効期限が近くない新しい証明書を使用するように更新されていることを確認します。期限切れの近い証明書が使用されなくなったら、DELETE {api_collection_path}{entity_id} NSX API を呼び出して、これらの証明書を削除する必要があります。

信頼された CA バンドルの更新を推奨します。

イベントの検出時：「信頼された CA バンドル {entity_id} は、{ca_bundle_age_threshold} 日以上前に更新されています。信頼された CA バンドルの更新を推奨します。」

イベントの解決時：「信頼された CA バンドル {entity_id} が削除または更新されたか、使用されなくなりました。」

信頼された CA バンドルを現在使用しているサービスが、最近更新された信頼された CA バンドルを使用するように更新されていることを確認します。システム提供のバンドルでない限り、バンドルは PUT /policy/api/v1/infra/cabundles/{entity_id} NSX API で更新できます。システム提供のバンドルを除き、期限切れで未使用のバンドルは、DELETE /policy/api/v1/infra/cabundles/{entity_id} NSX API を呼び出して削除する必要があります。

信頼された CA バンドルの更新を提案します。

イベントの検出時：「信頼された CA バンドル {entity_id} は、{ca_bundle_age_threshold} 日以上前に更新されています。信頼された CA バンドルの更新が提案されます。」

イベントの解決時：「信頼された CA バンドル {entity_id} が削除または更新されたか、使用されなくなりました。」

信頼された CA バンドルを現在使用しているサービスが、最近更新された信頼された CA バンドルを使用するように更新されていることを確認します。システム提供のバンドルでない限り、バンドルは PUT /policy/api/v1/infra/cabundles/{entity_id} NSX API で更新できます。システム提供のバンドルを除き、期限切れで未使用のバンドルは、DELETE /policy/api/v1/infra/cabundles/{entity_id} NSX API を呼び出して削除する必要があります。

証明書が期限切れです。

イベントの検出時：「トランスポート ノード {entity_id} の証明書の有効期限が切れています。」

イベントの解決時：「トランスポート ノード {entity_id} の期限切れの証明書が置換されたか、有効期限の問題が解決されました。」

トランスポート ノード {entity_id}の証明書を期限切れでない証明書に置き換えます。期限切れの証明書は、POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id} NSX API を呼び出して置き換える必要があります。期限切れの証明書がトランスポート ノードによって使用されている場合、トランスポート ノードとマネージャ ノード間の接続が切断されます。

証明書がまもなく期限切れになります。

イベントの検出時：「トランスポート ノード {entity_id} の証明書がまもなく期限切れになります。」

イベントの解決時：「トランスポート ノード {entity_id} の有効期限の近い証明書が削除されたか、有効期限の問題が解決されました。」

トランスポート ノード {entity_id}の証明書を期限切れでない証明書に置き換えます。期限切れの証明書は、POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id} NSX API を呼び出して置き換える必要があります。証明書が置き換えられていない場合、証明書の有効期限が切れると、トランスポート ノードとマネージャ ノード間の接続が切断されます。

証明書の期限切れが近づいています。

イベントの検出時：「トランスポート ノード {entity_id} の証明書の有効期限が近づいています。」

イベントの解決時：「トランスポート ノード {entity_id} の有効期限の近い証明書が削除されたか、有効期限の問題が解決されました。」

トランスポート ノード {entity_id}の証明書を期限切れでない証明書に置き換えます。期限切れの証明書は、POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id} NSX API を呼び出して置き換える必要があります。証明書が置き換えられていない場合、証明書の有効期限が切れると、トランスポート ノードとマネージャ ノード間の接続が切断されます。

グループ メンバーが停止しています。

イベントの検出時：「サービス {group_type} のグループ メンバー {manager_node_id} が停止しています。」

イベントの解決時：「{group_type} のグループ メンバー {manager_node_id} は稼動しています。」

1.NSX CLI コマンド 'get cluster status' を呼び出して、クラスタのグループ メンバーの状態を確認します。
2.{group_type} のサービスがノードで実行されていることを確認します。GET /api/v1/node/services/&ltservice_name&gt/status NSX API または NSX CLI コマンド get service &ltservice_name&gt を呼び出し、サービスが実行されているかどうか確認します。実行されていない場合は、POST /api/v1/node/services/&ltservice_name&gt?action=restart NSX API または restart service &ltservice_name&gt NSX CLI を呼び出して、サービスを再起動します。
3.サービス {group_type} の /var/log/ で、エラーが報告されているかどうか確認します。

サービスのすべてのグループ メンバーが停止しています。

イベントの検出時：「サービス {group_type} のすべてのグループ メンバー {manager_node_ids} が停止しています。」

イベントの解決時：サービス {group_type} のすべてのグループ メンバー {manager_node_ids} が稼動しています。」

1.{group_type} のサービスがノードで実行されていることを確認します。GET /api/v1/node/services/&ltservice_name&gt/status NSX API または NSX CLI コマンド get service &ltservice_name&gt を呼び出して、サービスが実行されているかどうか確認します。実行されていない場合は、POST /api/v1/node/services/&ltservice_name&gt?action=restart NSX API または restart service &ltservice_name&gt NSX CLI を呼び出し、サービスを再起動します。
2.サービス {group_type} の /var/log/ で、エラーが報告されているかどうか確認します。

DPU で Hyperbus はマネージャ ノードと通信不能です。

イベントの検出時：「DPU {dpu_id} で Hyperbus はマネージャ ノードと通信不能です。」

イベントの解決時：「DPU {dpu_id} で Hyperbus はマネージャ ノードと通信可能です。」

DPU {dpu_id} の Hyperbus vmkernel インターフェイス (vmk50) が存在しない可能性があります。ナレッジベースの記事 https://kb.vmware.com/s/article/67432 を参照してください。

Hyperbus がマネージャ ノードと通信できません。

イベントの検出時：「Hyperbus がマネージャ ノードと通信できません。」

イベントの解決時：「Hyperbus はマネージャ ノードと通信可能です。」

Hyperbus vmkernel インターフェイス (vmk50) が存在しない可能性があります。ナレッジベースの記事 https://kb.vmware.com/s/article/67432 を参照してください。

DPU 上の指定された VDS の vmknic 経由で、指定されたコレクタは到達不能です。

イベントの検出時：「{vertical_name} コレクタ {collector_ip} は、DPU {dpu_id} の VDS {dvs_alias} 上の vmknic (スタック {stack_alias}) 経由で到達不能ですが、他の VDS の vmknic (スタック {stack_alias}) 経由では到達可能です。」

イベントの解決時：「{vertical_name} コレクタ {collector_ip} は、DPU {dpu_id} の VDS {dvs_alias} 上の vmknic (スタック {stack_alias}) 経由で到達可能です。あるいは、{vertical_name} コレクタ {collector_ip} には完全に到達不能です。」

警告がオンになっていても、コレクタに到達不能とは限りません。VDS {dvs_alias} に基づいて垂直方向に生成されたエクスポート フローは、VDS {dvs_alias} 以外にも、VDS 上の vmknic 経由でコレクタ {collector_ip} に到達可能です。これが許容できない場合は、VDS {dvs_alias} 上のスタック {stack_alias} を使用して vmknic を作成し、これを適切な IPv4(6) アドレスで構成します。その後、ESXi 経由で DPU への SSH を有効にして、vmkping {collector_ip} -S {stack_alias} -I vmkX を呼び出し、DPU {dpu_id} に新しく作成した vmknic 経由で {vertical_name} コレクタ {collector_ip} に到達可能かどうか確認します。

DPU 上の既存の vmknic 経由で、指定されたコレクタは完全に到達不能です。

イベントの検出時：「{vertical_name} コレクタ {collector_ip} は、DPU {dpu_id} の VDS 上の既存の vmknic (スタック {stack_alias}) 経由で到達不能です。」

イベントの解決時：「{vertical_name} コレクタ {collector_ip} は、DPU {dpu_id} 上の既存の vmknic (スタック {stack_alias}) 経由で到達可能です。」

VDS 上の指定された垂直方向でコレクタに到達できるようにするには、想定されるスタック {stack_alias} を使用する vmknic が作成され、IPv4(6) アドレスが構成されていることと、{vertical_name} コレクタ {collector_ip} へのネットワーク接続が正常であることを確認する必要があります。この条件を満たすには、DPU {dpu_id} で確認を行い、必要な構成を実行する必要があります。最後に、ESXi 経由で DPU への SSH を有効にした状態で vmkping {collector_ip} -S {stack_alias} が成功した場合は、問題が解決されています。

マネージャ ノード間のネットワークの平均遅延が大きくなっています。

イベントの検出時：「マネージャ ノード {manager_node_id} ({appliance_address}) と {remote_manager_node_id} ({remote_appliance_address}) 間で過去 5 分間のネットワーク平均遅延が 10 ミリ秒を超えています。」

イベントの解決時：「マネージャ ノード {manager_node_id} ({appliance_address}) と {remote_manager_node_id} ({remote_appliance_address}) 間のネットワークの平均遅延は 10 ミリ秒以下です。」

マネージャ ノード間の ping トラフィックをブロックするファイアウォール ルールがないことを確認します。ローカル ネットワークを共有している他の高帯域幅のサーバとアプリケーションがある場合は、これらを別のネットワークに移行することを検討してください。

トランスポート ノードの制御プレーンからマネージャ ノードへの接続が長時間停止しています。

イベントの検出時：「トランスポート ノード {entity_id} の制御プレーンからマネージャ ノード {appliance_address} への接続が停止しています。トランスポート ノード側からみると、少なくとも {timeout_in_minutes} 分間停止しています。」

イベントの解決時：「トランスポート ノード {entity_id} で、制御プレーンからマネージャ ノード {appliance_address} への接続が復旧されました。」

1.ping を実行して、トランスポート ノード {entity_id} からマネージャ ノード {appliance_address} インターフェイスへの接続を確認します。ping に失敗した場合は、ネットワーク接続が不安定かどうか確認します。
2.netstat の出力で、マネージャ ノード {appliance_address} のコントローラ サービスがポート 1235 で接続を待機しているかどうか確認し、TCP 接続が確立しているかどうか調べます。確立していない場合は、ファイアウォール ルールまたは iptables ルールを調べて、ポート 1235 でトランスポート ノード {entity_id} の接続要求がブロックされているかどうか確認します。アンダーレイのホスト ファイアウォールまたはネットワーク ファイアウォールによって、マネージャ ノードとトランスポート ノード間で必要な IP ポートがブロックされていないことを確認します。ポートとプロトコルの詳細については、https://ports.vmware.com/ を参照してください。
3.トランスポート ノード {entity_id} がまだメンテナンス モードになっている可能性があります。トランスポート ノードがメンテナンス モードかどうか確認するには、次の API を使用します。GET https://&ltnsx-mgr&gt/api/v1/transport-nodes/&lttn-uuid&gt.メンテナンス モードになっていると、トランスポート ノードはコントローラ サービスに接続しません。通常、ホストのアップグレードが進行中の場合、このモードに設定されています。数分たってから、接続を再度確認してください。

トランスポート ノードの制御プレーンからマネージャ ノードへの接続が停止しています。

イベントの検出時：「トランスポート ノード {entity_id} の制御プレーンからマネージャ ノード {appliance_address} への接続が停止しています。トランスポート ノード側からみると、少なくとも {timeout_in_minutes} 分間停止しています。」

イベントの解決時：「トランスポート ノード {entity_id} で、制御プレーンからマネージャ ノード {appliance_address} への接続が復旧されました。」

1.ping を実行して、トランスポート ノード {entity_id} からマネージャ ノード {appliance_address} インターフェイスへの接続を確認します。ping に失敗した場合は、ネットワーク接続が不安定かどうか確認します。
2.netstat の出力で、マネージャ ノード {appliance_address} のコントローラ サービスがポート 1235 で接続を待機しているかどうか確認し、TCP 接続が確立しているかどうか調べます。確立していない場合は、ファイアウォール ルールまたは iptables ルールを調べて、ポート 1235 でトランスポート ノード {entity_id} の接続要求がブロックされているかどうか確認します。アンダーレイのホスト ファイアウォールまたはネットワーク ファイアウォールによって、マネージャ ノードとトランスポート ノード間で必要な IP ポートがブロックされていないことを確認します。ポートとプロトコルの詳細については、https://ports.vmware.com/ を参照してください。
3.トランスポート ノード {entity_id} がまだメンテナンス モードになっている可能性があります。トランスポート ノードがメンテナンス モードかどうか確認するには、次の API を使用します。GET https://&ltnsx-mgr&gt/api/v1/transport-nodes/&lttn-uuid&gt メンテナンス モードになっていると、トランスポート ノードはコントローラ サービスに接続しません。通常、ホストのアップグレードが進行中の場合、このモードに設定されています。数分たってから、接続を再度確認してください。注：このアラームは解決する必要がありますが、重大なものではありません。しばらくしてもこのアラームが解決しない場合を除き、このアラームの通知を VMware サポートに連絡する必要はありません。

コントローラ サービスからトランスポート ノードへの接続が停止しています。

イベントの検出時：「Manager ノード {appliance_address} ({central_control_plane_id}) のコントローラ サービスからトランスポート ノード {transport_node_name} ({entity_id}) への接続が停止しています。コントローラ サービス側からみると、少なくとも 3 分間停止しています。」

イベントの解決時：「Manager ノード {appliance_address} ({central_control_plane_id}) のコントローラ サービスがトランスポート ノード {entity_id} への接続をリストアします。」

1.ping と traceroute を使用して、コントローラ サービス {central_control_plane_id} からトランスポート ノード {entity_id} インターフェイスへの接続を確認します。この操作は、NSX Manager ノードの admin CLI で実行できます。ping のテストで損失と一定の遅延値がなければ問題ありません。150ms 以下の遅延値が推奨値です。
2.NSX UI で [システム] > [ファブリック] > [ノード] の順に移動してトランスポート ノード {entity_id} を選択し、マネージャ ノード {appliance_address} ({central_control_plane_id}) のコントローラ サービスとトランスポート ノード {entity_id} の間の TCP 接続が確立しているかどうか確認します。確立していない場合は、ネットワークとホストのファイアウォール ルールにより、ポート 1235 でトランスポート ノード {entity_id} の接続要求がブロックされているかどうか確認します。アンダーレイのホスト ファイアウォールまたはネットワーク ファイアウォールによって、マネージャ ノードとトランスポート ノード間で必要な IP ポートがブロックされていないことを確認します。ポートとプロトコルの詳細については、https://ports.vmware.com/ を参照してください。

コントローラ サービスからトランスポート ノードへの接続が長時間停止しています。

イベントの検出時：「Manager ノード {appliance_address} ({central_control_plane_id}) のコントローラ サービスからトランスポート ノード {transport_node_name} ({entity_id}) への接続が停止しています。コントローラ サービス側からみると、少なくとも 15 分間停止しています。」

イベントの解決時：「Manager ノード {appliance_address} ({central_control_plane_id}) のコントローラ サービスがトランスポート ノード {entity_id} への接続をリストアします。」

1.ping と traceroute を使用して、コントローラ サービス {central_control_plane_id} からトランスポート ノード {entity_id} インターフェイスへの接続を確認します。この操作は、NSX Manager ノードの admin CLI で実行できます。ping のテストで損失と一定の遅延値がなければ問題ありません。150ms 以下の遅延値が推奨値です。
2.NSX UI で [システム] > [ファブリック] > [ノード] の順に移動してトランスポート ノード {entity_id} を選択し、マネージャ ノード {appliance_address} ({central_control_plane_id}) のコントローラ サービスとトランスポート ノード {entity_id} の間の TCP 接続が確立しているかどうか確認します。確立していない場合は、ネットワークとホストのファイアウォール ルールにより、ポート 1235 でトランスポート ノード {entity_id} の接続要求がブロックされているかどうか確認します。アンダーレイのホスト ファイアウォールまたはネットワーク ファイアウォールによって、マネージャ ノードとトランスポート ノード間で必要な IP ポートがブロックされていないことを確認します。ポートとプロトコルの詳細については、https://ports.vmware.com/ を参照してください。

マネージャからコントローラ チャネルへの接続が停止しています。

イベントの検出時：「マネージャノード {manager_node_name} ({appliance_address}) で管理機能と制御機能の通信が失敗しました。」

イベントの解決時：「マネージャノード {manager_node_name} ({appliance_address}) で管理機能と制御機能の通信がリストアされました。」

1.マネージャ ノード {manager_node_name} ({appliance_address}) で、NSX CLI コマンド get service applianceproxy を呼び出し、サービスの状態を 60 分間隔で確認します。
2.サービスが 60 分以上実行されていない場合は、NSX CLI コマンド「restart service applianceproxy」を呼び出し、状態を再確認します。サービスがまだ停止している場合は、VMware のサポートにお問い合わせください。

管理チャネルからトランスポート ノードへの接続が停止しています。

イベントの検出時：「管理チャネルからトランスポート ノード {transport_node_name} ({transport_node_address}) の接続が 5 分間停止しています。」

イベントの解決時：「管理チャネルからトランスポート ノード {transport_node_name} ({transport_node_address}) の通信が稼動しています。」

マネージャ ノードとトランスポート ノード {transport_node_name} ({transport_node_address}) 間でネットワーク接続が確立していることと、これらのノード間のトラフィックがファイアウォールでブロックされていないことを確認します。Windows トランスポート ノードで、Windows PowerShell から C:\NSX\nsx-proxy\nsx-proxy.ps1 status コマンドを実行し、トランスポート ノードで nsx-proxy サービスが実行されていることを確認します。実行されていない場合は、C:\NSX\nsx-proxy\nsx-proxy.ps1 restart コマンドを呼び出して再起動します。他のすべてのトランスポート ノードで、/etc/init.d/nsx-proxy status コマンドを呼び出し、トランスポート ノードで nsx-proxy サービスが実行されていることを確認します。実行されていない場合は、/etc/init.d/nsx-proxy restart コマンドを呼び出して再起動します。

管理チャネルからトランスポート ノードへの接続が長時間停止しています。

イベントの検出時：「管理チャネルからトランスポート ノード {transport_node_name} ({transport_node_address}) の接続が 15 分間停止しています。」

イベントの解決時：「管理チャネルからトランスポート ノード {transport_node_name} ({transport_node_address}) の通信が稼動しています。」

マネージャ ノードとトランスポート ノード {transport_node_name} ({transport_node_address}) 間でネットワーク接続が確立していることと、これらのノード間のトラフィックがファイアウォールでブロックされていないことを確認します。Windows トランスポート ノードで、Windows PowerShell から C:\NSX\nsx-proxy\nsx-proxy.ps1 status コマンドを呼び出して、トランスポート ノードで nsx-proxy サービスが実行されていることを確認します。実行されていない場合は、C:\NSX\nsx-proxy\nsx-proxy.ps1 restart コマンドを呼び出して再起動します。他のすべてのトランスポート ノードで、/etc/init.d/nsx-proxy status コマンドを呼び出し、トランスポート ノードで nsx-proxy サービスが実行されていることを確認します。実行されていない場合は、/etc/init.d/nsx-proxy restart コマンドを呼び出して再起動します。

マネージャ ノードの FQDN の DNS 参照に失敗しました。

イベントの検出時：「FQDN {appliance_fqdn} のマネージャ ノード {entity_id} の DNS 参照に失敗し、publish_fqdns フラグが設定されました。」

イベントの解決時：「FQDN {appliance_fqdn} のマネージャ ノード {entity_id} の FQDN 参照に成功したか、publish_fqdns フラグがクリアされました。」

1.すべてのマネージャ ノードに正しい FQDN を割り当てます。DNS 構成をチェックし、すべてのマネージャ ノードの FQDN の参照が正常に行われることを確認します。
2.または、要求本文で publish_fqdns を false に設定して NSX API PUT /api/v1/configs/management を呼び出し、FQDN の使用を無効にします。その後、このクラスタでトランスポート ノードからの呼び出しと、フェデレーションからマネージャ ノードへの呼び出しでは、IP アドレスのみが使用されます。

マネージャ ノードの IP アドレスの DNS 逆引き参照に失敗しました。

イベントの検出時：「IP アドレス {appliance_address} のマネージャ ノード {entity_id} の DNS 逆引き参照が失敗し、publish_fqdns フラグが設定されました。」

イベントの解決時：「IP アドレス {appliance_address} のマネージャ ノード {entity_id} の DNS 逆引き参照に成功したか、publish_fqdns フラグがクリアされました。」

1.すべてのマネージャ ノードに正しい FQDN を割り当てます。DNS 構成をチェックし、マネージャ ノードの IP アドレスの逆引き参照が正常に行われることを確認します。
2.または、要求本文で publish_fqdns を false に設定して NSX API PUT /api/v1/configs/management を呼び出し、FQDN の使用を無効にします。その後、このクラスタでトランスポート ノードからの呼び出しと、フェデレーションからマネージャ ノードへの呼び出しでは、IP アドレスのみが使用されます。

管理チャネルからマネージャ ノードへの接続が停止しています。

イベントの検出時：「管理チャネルからマネージャ ノード {manager_node_id} ({appliance_address}) の接続が 5 分間停止しています。」

イベントの解決時：「管理チャネルからマネージャ ノード {manager_node_id} ({appliance_address}) の通信が稼動しています。」

トランスポート ノード {transport_node_id} とマスター マネージャ ノードの間にネットワーク接続があることを確認します。また、これらのノード間のトラフィックがファイアウォールでブロックされていないことを確認します。/etc/init.d/messaging-manager status コマンドを呼び出して、マネージャ ノードでメッセージング マネージャ サービスが実行されていることを確認します。実行されていない場合は、/etc/init.d/messaging-manager restart コマンドを呼び出してサービスを再起動します。

管理チャネルからマネージャ ノードへの接続が長時間停止しています。

イベントの検出時：「管理チャネルからマネージャ ノード {manager_node_id} ({appliance_address}) の接続が 15 分間停止しています。」

イベントの解決時：「管理チャネルからマネージャ ノード {manager_node_id} ({appliance_address}) の通信が稼動しています。」

トランスポート ノード {transport_node_id} とマスター マネージャ ノードの間にネットワーク接続があることを確認します。また、これらのノード間のトラフィックがファイアウォールでブロックされていないことを確認します。/etc/init.d/messaging-manager status コマンドを呼び出して、マネージャ ノードでメッセージング マネージャ サービスが実行されていることを確認します。実行されていない場合は、/etc/init.d/messaging-manager restart コマンドを呼び出してサービスを再起動します。

管理ノードからトランスポート ノードへのネットワーク遅延が大きくなっています。

イベントの検出時：「マネージャ ノードとホスト {transport_node_name} ({transport_node_address}) 間のネットワーク平均遅延は、5 分間で 150 ミリ秒を超えています。」

イベントの解決時：「マネージャ ノードとホスト {transport_node_name} ({transport_node_address}) 間のネットワークの平均遅延は正常です。」

1.5 分待って、アラームが自動的に解決されるかどうかを確認します。
2.マネージャ ノードから NSX トランスポート ノードに ping を実行します。ping のテストで損失と一定の遅延値がなければ問題ありません。150ms 以下の遅延値が推奨値です。
3.物理ネットワーク レイヤーのその他の問題を調べます。問題が解決しない場合は、VMware のサポートにお問い合わせください。

IP プール内の IP アドレスが不足しています。

イベントの検出時：「DHCP サーバ {dhcp_server_id} の IP プール {entity_id} のアドレスがすべて使用されています。最後の DHCP 要求は失敗しています。以降の要求も失敗します。」

イベントの解決時：「DHCP サーバ {dhcp_server_id} の IP プール {entity_id} の問題が解決されました。前回の DHCP 要求にリースが正常に割り当てられています。」

NSX ユーザー インターフェイスで、あるいは DHCP サーバが実行されている Edge ノードで NSX CLI コマンド get dhcp ip-pool を呼び出して、DHCP プールの構成を確認します。さらに、NSX CLI コマンド get dhcp lease を呼び出して、Edge ノードで現在アクティブなリースを確認します。リースとアクティブな仮想マシンの数を比較します。アクティブなリースの数と比較して、仮想マシンの数が少ない場合は、DHCP サーバ構成でリース時間を短縮することを検討します。また、NSX UI で [ネットワーク] | [セグメント] | [セグメント] 画面の順にアクセスして、DHCP サーバのプール範囲を拡張することを検討します。

IP プールが過負荷状態になっています。

イベントの検出時：「DHCP サーバ {dhcp_server_id} の IP プール {entity_id} の使用率が上限に近づいています。{dhcp_pool_usage}% の IP が割り当てられています。」

イベントの解決時：「DHCP サーバ {dhcp_server_id} の IP プールの {entity_id} が使用率の高しきい値を下回りました。」

NSX ユーザー インターフェイスで、あるいは DHCP サーバが実行されている Edge ノードで NSX CLI コマンド get dhcp ip-pool を呼び出して、DHCP プールの構成を確認します。さらに、NSX CLI コマンド get dhcp lease を呼び出して、Edge ノードで現在アクティブなリースを確認します。リースとアクティブな仮想マシンの数を比較します。アクティブなリースの数と比較して、仮想マシンの数が少ない場合は、DHCP サーバ構成でリース時間を短縮することを検討します。また、NSX UI で [ネットワーク] | [セグメント] | [セグメント] 画面の順にアクセスして、DHCP サーバのプール範囲を拡張することを検討します。

DFW の CPU 使用率が非常に高くなっています。

イベントの検出時：「トランスポート ノード {entity_id} の DFW の CPU 使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値に達しているか、超えています。」

イベントの解決時：「トランスポート ノード {entity_id} の DFW の CPU 使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値を下回っています。」

このホストと他のホストの間で仮想マシン ワークロードのリバランシングを行うことを検討してください。最適化でのセキュリティ設計を確認してください。たとえば、ルールがデータセンター全体に適用されない場合は、適用先の構成を使用します。

DPU で DFW の CPU 使用率が非常に高くなっています。

イベントの検出時：「DPU {dpu_id} で、トランスポート ノード {entity_id} の DFW の CPU 使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値に達しているか、超えています。」

イベントの解決時：「DPU {dpu_id} で、トランスポート ノード {entity_id} の DFW の CPU 使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値を下回っています。」

このホストと他のホストの間で仮想マシン ワークロードのリバランシングを行うことを検討してください。最適化でのセキュリティ設計を確認してください。たとえば、ルールがデータセンター全体に適用されない場合は、適用先の構成を使用します。

DFW のメモリ使用率が非常に高くなっています。

イベントの検出時：「トランスポート ノード {entity_id} の DFW のメモリ使用率 {heap_type} が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値に達しているか、超えています。」

イベントの解決時：「トランスポート ノード {entity_id} の DFW のメモリ使用率 {heap_type} が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値を下回っています。」

ホストで NSX CLI コマンド get firewall thresholds を呼び出して、現在の DFW のメモリ使用率を確認します。このホストと他のホストの間でワークロードのリバランシングを行うことを検討してください。

DPU で DFW のメモリ使用率が非常に高くなっています。

イベントの検出時：「DPU {dpu_id} で、トランスポート ノード {entity_id} の DFW のメモリ使用率 {heap_type} が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値に達しているか、超えています。」

イベントの解決時：「DPU {dpu_id} で、トランスポート ノード {entity_id} の DFW のメモリ使用率 {heap_type} が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値を下回っています。」

DPU で NSX CLI コマンド get firewall thresholds を呼び出して、現在の DFW のメモリ使用率を確認します。このホストと他のホストの間でワークロードのリバランシングを行うことを検討してください。

DFW vMotion に失敗し、ポートが切断されました。

イベントの検出時：「宛先ホスト {transport_node_name} の DFW フィルタ {entity_id} の DFW vMotion でエラーが発生し、エンティティのポートが切断されました。」

イベントの解決時：「宛先ホスト {transport_node_name} の DFW フィルタ {entity_id} の DFW 構成に成功し、DFW vMotion の障害で発生したエラーが解決されました。」

NSX Manager でホスト上の仮想マシンを確認します。NSX Manager ユーザー インターフェイスで、DFW 構成を手動で再度プッシュします。再プッシュされる DFW ポリシーは、DFW フィルタ {entity_id} で追跡できます。また、DFW フィルタが接続している仮想マシンを特定して再起動することも検討してください。

DFW フラッド制限が警告レベルに達しました。

イベントの検出時：「ホスト {transport_node_name} の DFW フィルタ {entity_id} の DFW フラッド制限が警告レベル（プロトコル {protocol_name} に構成されている制限の 80%）に達しました。」

イベントの解決時：「ホスト {transport_node_name} の DFW フィルタ {entity_id} で、プロトコル {protocol_name} に対する警告フラッド制限条件がクリアされました。」

NSX Manager でホスト上の仮想マシンを確認し、DFW フィルタ {entity_id} でプロトコル {protocol_name} に構成されている警告フラッド レベルを確認します。

DFW フラッド制限が重大レベルに達しました。

イベントの検出時：「ホスト {transport_node_name} の DFW フィルタ {entity_id} の DFW フラッド制限が重大レベル（プロトコル {protocol_name} に構成されている制限の 98%）に達しました。」

イベントの解決時：「ホスト {transport_node_name} の DFW フィルタ {entity_id} で、プロトコル {protocol_name} に対する重大フラッド制限条件がクリアされました。」

NSX Manager でホスト上の仮想マシンを確認し、DFW フィルタ {entity_id} でプロトコル {protocol_name} に構成されている重大フラッド レベルを確認します。

DFW セッション数が多くなっています。

イベントの検出時：「トランスポート ノード {entity_id} の DFW セッション数が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。」

イベントの解決時：「トランスポート ノード {entity_id} の DFW セッション数が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% のしきい値を下回っています。」

ホスト上で、ワークロードのネットワーク トラフィックの負荷レベルを確認します。このホストと他のホストの間でワークロードのリバランシングを行うことを検討してください。

vNIC あたりの DFW ルール数の制限がまもなく上限を超えます。

イベントの検出時：「宛先ホスト {transport_node_name} の VIF {entity_id} の DFW ルール数がまもなく上限を超えます。」

イベントの解決時：「宛先ホスト {transport_node_name} の VIF {entity_id} の DFW ルールの制限が上限を下回りました。」

ESX ホスト {transport_node_name} にログインし、NSX CLI コマンド get firewall &ltVIF_UUID&gt ruleset rules を呼び出して、対応する VIF に構成されたルールの統計情報を取得します。VIF {entity_id} に構成されたルールの数を減らします。

vNIC あたりの DFW ルール数が上限に近づいています。

イベントの検出時：「宛先ホスト {transport_node_name} の VIF {entity_id} の DFW ルール数が最大数の上限に近づいています。」

イベントの解決時：「宛先ホスト {transport_node_name} の VIF {entity_id} の DFW ルールの上限がしきい値を下回りました。」

ESX ホスト {transport_node_name} にログインし、NSX CLI コマンド get firewall &ltVIF_UUID&gt ruleset rules を呼び出して、対応する VIF に構成されたルールの統計情報を取得します。VIF {entity_id} に構成されたルールの数を減らします。

ホスト 1 台あたりの DFW ルール数の制限がまもなく上限を超えます。

イベントの検出時：「ホスト {transport_node_name} の DFW ルール数がまもなく上限を超えます。」

イベントの解決時：「ホスト {transport_node_name} の DFW ルールの上限が最大値を下回りました。」

ESX ホスト {transport_node_name} にログインし、NSX CLI コマンド get firewall rule-stats total を呼び出して、ESX ホスト {transport_node_name} で構成されたルールのルール統計情報を取得します。ホスト {transport_node_name} に構成されたルールの数を減らします。NSX CLI コマンドget firewall &ltVIF_UUID&gt ruleset rules を使用して、さまざまな VIF に構成されているルールの数を確認します。さまざまな VIF に構成されているルールの数を減らします。

ホスト 1 台あたりの DFW ルール数が上限に近づいています。

イベントの検出時：「ホスト {transport_node_name} の DFW ルール数が上限に近づいています。」

イベントの解決時：「ホスト {transport_node_name} の DFW ルールの上限がしきい値を下回りました。」

ESX ホスト {transport_node_name} にログインし、NSX CLI コマンド get firewall rule-stats total を呼び出して、ESX ホスト {transport_node_name} で構成されたルールのルール統計情報を取得します。ホスト {transport_node_name} に構成されたルールの数を減らします。NSX CLI コマンドget firewall &ltVIF_UUID&gt ruleset rules を使用して、さまざまな VIF に構成されているルールの数を確認します。さまざまな VIF に構成されているルールの数を減らします。

侵入イベントの最大数に達しました。

イベントの検出時：「システムの侵入イベントの数が {ids_events_count} になっています。これは、許容される最大値 {max_ids_events_allowed} を超えています。」

イベントの解決時：「システムの侵入イベントの数が {ids_events_count} になりました。これは、許容される最大値 {max_ids_events_allowed} を下回っています。」

手動での操作は必要ありません。パージ ジョブは 3 分ごとに自動的に開始し、古いレコードの 10% が削除されます。これにより、システム内のすべての侵入イベントの合計数がイベントのしきい値（150 万）を下回ります。

NSX-IDPS エンジンのメモリ使用量が 75% 以上に達しています。

イベントの検出時：「NSX-IDPS エンジンのメモリ使用率が {system_resource_usage}% になっています。これは、高しきい値の 75% に達しているか、超えています。」

イベントの解決時：「NSX-IDPS エンジンのメモリ使用率が {system_resource_usage}% に達しています。これは、高しきい値の 75% を下回っています。」

このホストと他のホストの間で仮想マシン ワークロードのリバランシングを行うことを検討してください。

DPU で NSX-IDPS エンジンのメモリ使用量が 75% 以上に達します。

イベントの検出時：「DPU {dpu_id} で、NSX-IDPS エンジンのメモリ使用率が {system_resource_usage}% になっています。これは、高しきい値の 75% に達しているか、超えています。」

イベントの解決時：「DPU {dpu_id} で、NSX-IDPS エンジンのメモリ使用率が {system_resource_usage}% に達しています。これは、高しきい値の 75% を下回っています。」

このホストと他のホストの間で仮想マシン ワークロードのリバランシングを行うことを検討してください。

NSX-IDPS エンジンのメモリ使用量が 85% 以上に達します。

イベントの検出時：「NSX-IDPS エンジンのメモリ使用率が {system_resource_usage}% になっています。これは、中高しきい値の 85% に達しているか、超えています。」

イベントの解決時：「NSX-IDPS エンジンのメモリ使用率が {system_resource_usage}% になっています。これは、中高しきい値の 85% を下回っています。」

このホストと他のホストの間で仮想マシン ワークロードのリバランシングを行うことを検討してください。

DPU で NSX-IDPS エンジンのメモリ使用量が 85% 以上に達します。

イベントの検出時：「DPU {dpu_id} で、NSX-IDPS エンジンのメモリ使用率が {system_resource_usage}% になっています。これは、中高しきい値の 85% に達しているか、超えています。」

イベントの解決時：「DPU {dpu_id} で、NSX-IDPS エンジンのメモリ使用率が {system_resource_usage}% に達しています。これは、中高しきい値の 85% を下回っています。」

このホストと他のホストの間で仮想マシン ワークロードのリバランシングを行うことを検討してください。

NSX-IDPS エンジンのメモリ使用量が 95% 以上に達しています。

イベントの検出時：「NSX-IDPS エンジンのメモリ使用率が {system_resource_usage}% になっています。これは、超高しきい値の 95% に達しているか、超えています。」

イベントの解決時：「NSX-IDPS エンジンのメモリ使用率が {system_resource_usage}% に達しています。これは、超高しきい値の 95% を下回っています。」

このホストと他のホストの間で仮想マシン ワークロードのリバランシングを行うことを検討してください。

DPU で NSX-IDPS エンジンのメモリ使用量が 95% 以上に達します。

イベントの検出時：「DPU {dpu_id} で NSX-IDPS エンジンのメモリ使用率が {system_resource_usage}% になっています。これは、超高しきい値の 95% に達しているか、超えています。」

イベントの解決時：「DPU {dpu_id} で、NSX-IDPS エンジンのメモリ使用率が {system_resource_usage}% に達しています。これは、超高しきい値の 95% を下回っています。」

このホストと他のホストの間で仮想マシン ワークロードのリバランシングを行うことを検討してください。

NSX-IDPS エンジンの CPU 使用率が 75% 以上に達しています。

イベントの検出時：「NSX-IDPS エンジンの CPU 使用率が {system_resource_usage}% になっています。これは、高しきい値の 75% に達しているか、超えています。」

イベントの解決時：「NSX-IDPS エンジンの CPU 使用率が {system_resource_usage}% に達しています。これは、高しきい値の 75% を下回っています。」

このホストと他のホストの間で仮想マシン ワークロードのリバランシングを行うことを検討してください。

NSX-IDPS エンジンの CPU 使用率が 85% 以上に達しています。

イベントの検出時：「NSX-IDPS エンジンの CPU 使用率が {system_resource_usage}% になっています。これは、中高しきい値の 85% に達しているか、超えています。」

イベントの解決時：「NSX-IDPS エンジンの CPU 使用率が {system_resource_usage}% になっています。これは、中高しきい値の 85% を下回っています。」

このホストと他のホストの間で仮想マシン ワークロードのリバランシングを行うことを検討してください。

NSX-IDPS エンジンの CPU 使用率が 95% を超えています。

イベントの検出時：「NSX-IDPS エンジンの CPU 使用率が {system_resource_usage}% になっています。これは、超高しきい値の 95% に達しているか、超えています。」

イベントの解決時：「NSX-IDPS エンジンの CPU 使用率が {system_resource_usage}% に達しています。これは、超高しきい値の 95% を下回っています。」

このホストと他のホストの間で仮想マシン ワークロードのリバランシングを行うことを検討してください。

NSX ポリシーで NSX IDPS が有効になり、IDPS ルールが構成されていますが、NSX-IDPS エンジンが停止しています。

イベントの検出時：「NSX ポリシーで NSX IDPS が有効になり、IDPS ルールが構成されていますが、NSX-IDPS エンジンが停止しています。」

イベントの解決時：「NSX IDPS は次のいずれかの状態です。1.NSX ポリシーによって NSX IDPS が無効になっています。2.NSX IDPS エンジンが有効で、VDPI が実行されています。NSX ポリシーによって NSX IDPS エンジンが有効にされ、IDPS ルールが構成されています。」

1./var/log/nsx-syslog.log で、エラーが報告されているかどうか確認します。
2.NSX CLI コマンド get ids engine status を呼び出して、NSX 分散 IDPS が無効な状態かどうかを確認します。無効になっている場合は、/etc/init.d/nsx-idps start を呼び出してサービスを開始します。
3./etc/init.d/nsx-vdpi status を呼び出して、nsx-vdpi が実行中かどうか確認します。実行されていない場合は、/etc/init.d/nsx-vdpi start を呼び出してサービスを開始します。

NSX ポリシーで NSX IDPS が有効になり、IDPS ルールが構成されていますが、DPU で NSX-IDPS エンジンが停止しています。

イベントの検出時：「NSX ポリシーで NSX IDPS が有効になり、IDPS ルールが構成されていますが、DPU {dpu_id} で NSX-IDPS エンジンが停止しています。」

イベントの解決時：「DPU {dpu_id} で、NSX IDPS は次のいずれかの状態です。1.NSX ポリシーによって NSX IDPS が無効になっています。2.NSX IDPS エンジンが有効で、VDPI が実行されています。NSX ポリシーによって NSX IDPS エンジンが有効にされ、IDPS ルールが構成されています。」

1./var/log/nsx-idps/nsx-idps.log と /var/log/nsx-syslog.log を調べて、エラーが報告されているかどうかを確認します。
2.NSX CLI コマンド get ids engine status を呼び出して、NSX 分散 IDPS が無効な状態かどうかを確認します。無効になっている場合は、/etc/init.d/nsx-idps start を呼び出してサービスを開始します。
3./etc/init.d/nsx-vdpi status を呼び出して、nsx-vdpi が実行中かどうか確認します。実行されていない場合は、/etc/init.d/nsx-vdpi start を呼び出してサービスを開始します。

分散 IDPS エンジンの CPU 使用率が高くなっています。

イベントの検出時：「分散 IDPS エンジンの CPU 使用率が {system_usage_threshold}% の高しきい値に達しているか、超えています。」

イベントの解決時：「分散 IDPS エンジンの CPU 使用率が {system_usage_threshold}% の高しきい値を下回りました。」

オーバーサブスクリプションの理由を確認します。特定のアプリケーションを別のホストに移動します。

分散 IDPS エンジンの CPU 使用率が非常に高くなっています。

イベントの検出時：「分散 IDPS エンジンの CPU 使用率が {system_usage_threshold}% の超高しきい値に達したか、上回っています。」

イベントの解決時：「分散 IDPS エンジンの CPU 使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

オーバーサブスクリプションの理由を確認します。特定のアプリケーションを別のホストに移動します。

分散 IDPS エンジンのネットワーク使用率が高くなっています。

イベントの検出時：「分散 IDPS エンジンのネットワーク使用率が {system_usage_threshold}% の高しきい値に達したか、上回っています。」

イベントの解決時：「分散 IDPS エンジンのネットワーク使用率が {system_usage_threshold}% の高しきい値を下回りました。」

オーバーサブスクリプションの理由を確認します。IDPS ルールを確認して、IDPS サービスの対象となるトラフィックの量を減らします。

分散 IDPS エンジンのネットワーク使用率が非常に高くなっています。

イベントの検出時：「分散 IDPS エンジンのネットワーク使用率が {system_usage_threshold}% の超高しきい値に達したか、上回っています。」

イベントの解決時：「分散 IDPS エンジンのネットワーク使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

オーバーサブスクリプションの理由を確認します。IDPS ルールを確認して、IDPS サービスの対象となるトラフィックの量を減らします。

CPU オーバーサブスクリプションが原因で、分散 IDPS エンジンがトラフィックをドロップしました。

イベントの検出時：「IDPS エンジンの CPU リソースが不足しているため、受信トラフィックに対応できません。このため、過剰なトラフィックがドロップされています。詳細については、ESX ホストにログインして、vsipioctl getdpiinfo -s コマンドを発行し、オーバーサブスクリプションの統計情報を確認します。」

イベントの解決時：「分散 IDPS エンジンには十分な CPU リソースがあります。トラフィックはドロップされていません。」

オーバーサブスクリプションの理由を確認します。特定のアプリケーションを別のホストに移動します。

ネットワーク オーバーサブスクリプションが原因で、分散 IDPS エンジンがトラフィックをドロップしました。

イベントの検出時：「IDPS エンジンが、受信トラフィックのレートに対応できないため、過剰なトラフィックがドロップされています。詳細については、ESX ホストにログインして、vsipioctl getdpiinfo -s コマンドを発行し、オーバーサブスクリプションの統計情報を確認します。」

イベントの解決時：「分散 IDPS エンジンはトラフィックをドロップしていません。」

オーバーサブスクリプションの理由を確認します。IDPS ルールを確認して、IDPS サービスの対象となるトラフィックの量を減らします。

CPU オーバーサブスクリプションが原因で、分散 IDPS エンジンがトラフィックをバイパスしました。

イベントの検出時：「IDPS エンジンの CPU リソースが不足しているため、受信トラフィックに対応できません。このため、過剰なトラフィックがバイパスされています。詳細については、ESX ホストにログインして、vsipioctl getdpiinfo -s コマンドを発行し、オーバーサブスクリプションの統計情報を確認します。」

イベントの解決時：「分散 IDPS エンジンには十分な CPU リソースがあります。トラフィックはバイパスされていません。」

オーバーサブスクリプションの理由を確認します。特定のアプリケーションを別のホストに移動します。

ネットワーク オーバーサブスクリプションが原因で、分散 IDPS エンジンがトラフィックをバイパスしました。

イベントの検出時：「IDPS エンジンが、受信トラフィックのレートに対応できないため、過剰なトラフィックがバイパスされています。詳細については、ESX ホストにログインして、vsipioctl getdpiinfo -s コマンドを発行し、オーバーサブスクリプションの統計情報を確認します。」

イベントの解決時：「分散 IDPS エンジンはトラフィックをバイパスしていません。」

オーバーサブスクリプションの理由を確認します。IDPS ルールを確認して、IDPS サービスの対象となるトラフィックの量を減らします。

DNS フォワーダが停止しています。

イベントの検出時：「DNS フォワーダ {entity_id} が実行されていません。これは、現在有効になっている識別済みのすべての DNS フォワーダに影響します。」

イベントの解決時：「DNS フォワーダ {entity_id} が再実行されています。」

1.NSX CLI コマンド get dns-forwarders status を呼び出し、DNS フォワーダが停止状態かどうかを確認します。
2./var/log/syslog で、エラーが報告されているかどうか確認します。
3.サポート バンドルを収集して、NSX サポート チームに連絡してください。

DNS フォワーダが無効になっています。

イベントの検出時：「DNS フォワーダ {entity_id} が無効になっています。」

イベントの解決時：「DNS フォワーダ {entity_id} が有効になっています。」

1.NSX CLI コマンド get dns-forwarders status を呼び出し、DNS フォワーダが無効になっているかどうかを確認します。
2.NSX ポリシー API またはマネージャ API を使用して、DNS フォワーダを有効にします。これは、無効な状態にしておくことはできません。

1 台の DNS フォワーダ アップストリーム サーバがタイムアウトになりました。

イベントの検出時：「DNS フォワーダ {intent_path}({dns_id}) がアップストリーム サーバ {dns_upstream_ip} からの応答をタイムリーに受信しませんでした。タイムアウトした FQDN へのコンピューティング インスタンスの接続が影響を受ける可能性があります。」

イベントの解決時：「DNS フォワーダ {intent_path}({dns_id}) のアップストリーム サーバ {dns_upstream_ip} は正常です。」

1.NSX API GET /api/v1/dns/forwarders/{dns_id}/nslookup? address=&ltaddress&gt&server_ip={dns_upstream_ip}&source_ip=&ltsource_ip&gt を呼び出します。この API 要求は、DNS フォワーダのネットワーク ネームスペース内のアップストリーム サーバに DNS ルックアップをトリガします。&ltaddress&gt は、アップストリーム サーバと同じドメイン内の IP アドレスまたは FQDN です。&ltsource_ip&gt は、アップストリーム サーバのゾーン内の IP アドレスです。API から接続タイムアウト応答が返された場合、ネットワーク エラーが発生しているか、アップストリーム サーバに問題がある可能性があります。DNS ルックアップがアップストリーム サーバに到達しない理由またはアップストリーム サーバから応答がない理由を確認してください。API の応答で、アップストリーム サーバからの応答が示されている場合は、手順 2 に進みます。
2.NSX API GET /api/v1/dns/forwarders/{dns_id}/nslookup? address=&ltaddress&gt を呼び出します。この API 要求は、DNS フォワーダに対して DNS ルックアップをトリガします。API から有効な応答が返された場合は、アップストリーム サーバが復旧し、このアラームが数分で解決される可能性があります。API から接続タイムアウト応答が返された場合は、手順 3 に進みます。
3.NSX CLI コマンド「get dns-forwarder {dns_id} live-debug server-ip {dns_upstream_ip}」を呼び出します。このコマンドは、アップストリーム サーバでライブ デバッグをトリガし、詳細と統計情報をログに記録します。このログに、DNS フォワーダが応答を受信していない理由が記録されています。

Edge ノードの設定が一致しません。

イベントの検出時：「Edge ノード {entity_id} の設定構成がポリシー インテント構成と一致しません。UI または API でユーザーに表示される Edge ノードの構成が認識済みのものと異なります。このアラームの詳細に、ユーザーが NSX Manager の外部で認識済みの Edge ノードに行った変更が表示されます。UI または API で編集すると、認識済みの構成が上書きされます。Edge ノードで異なるフィールドがランタイム データに表示されます。{edge_node_setting_mismatch_reason}」

イベントの解決時：「Edge ノード {entity_id} のノード設定がポリシー インテントと一致するようになりました。」

この Edge トランスポート ノード {entity_id} のノード設定を確認してください。アラームを解決するには、以下のいずれかのアクションを実行してください。-
1.API: PUT https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt を使用して、Edge トランスポート ノード設定のポリシー インテントを手動で更新します。
2.Edge トランスポート ノード リゾルバを使用して、この Edge トランスポート ノードのインテントまたは認識済みの Edge ノード設定を受け入れて、このアラートを解決します。
3.更新 API - POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode を使用して、Edge ノードの設定構成を受け入れて、アラームを解決します。

Edge 仮想マシンの vSphere の設定が一致しません。

イベントの検出時：「Edge ノード {entity_id} の vSphere の構成がポリシー インテント構成と一致しません。UI または API でユーザーに表示される Edge ノードの構成が認識済みのものと異なります。このアラームの詳細に、ユーザーが NSX Manager の外部で認識済みの Edge ノードに行った変更が表示されます。UI または API で編集すると、認識済みの構成が上書きされます。Edge ノードで異なるフィールドがランタイム データに表示されます。{edge_vm_vsphere_settings_mismatch_reason}」

イベントの解決時：「Edge ノード {entity_id} の仮想マシンの vSphere の設定が、ポリシー インテントと一致するようになりました。」

この Edge トランスポート ノード {entity_id} の vSphere 構成を確認してください。アラームを解決するには、以下のいずれかのアクションを実行してください。-
1.Edge トランスポート ノード リゾルバを使用して、この Edge トランスポート ノードのインテントまたは vSphere で認識済みの Edge ノード構成を受け入れて、このアラームを解決します。
2.更新 API POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode を使用して、vSphere Edge で構成が認識されている Edge ノードを受け入れてアラームを解決します。

Edge ノードの設定と vSphere の設定が変更されています。

イベントの検出時：「Edge ノード {entity_id} の設定と vSphere の構成が変更され、ポリシー インテント構成と一致しません。UI または API でユーザーに表示される Edge ノードの構成が認識済みのものと異なります。このアラームの詳細に、ユーザーが NSX Manager の外部で認識済みの Edge ノードに行った変更が表示されます。UI または API で編集すると、認識済みの構成が上書きされます。Edge ノードの設定と vSphere の構成で異なるフィールドがランタイム データに表示されます。{edge_node_settings_and_vsphere_settings_mismatch_reason}」

イベントが解決時：「Edge ノード {entity_id} のノード設定と vSphere の設定が、ポリシー インテントと一致するようになりました。」

この Edge トランスポート ノード {entity_id} のノード設定と vSphere の構成を確認します。アラームを解決するには、以下のいずれかのアクションを実行してください。-
1.API: PUT https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt を使用して、Edge トランスポート ノード設定のポリシー インテントを手動で更新します。
2.Edge トランスポート ノード リゾルバを使用して、この Edge トランスポート ノードのインテント、vSphere で認識済みの Edge ノード構成、または認識済みの Edge ノード構成を受け入れて、このアラートを解決します。
3.更新 API POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode を使用して、Edge ノードの設定と vSphere で認識済みの構成を受け入れて、アラームを解決します。

Edge の vSphere の場所が一致しません。

イベントの検出時：「vMotion で Edge ノード {entity_id} が移行されました。「Edge ノード {entity_id} の vSphere の構成がポリシー インテント構成と一致しません。UI または API でユーザーに表示される Edge ノードの構成が認識済みのものと異なります。このアラームの詳細に、ユーザーが NSX Manager の外部で認識済みの Edge ノードに行った変更が表示されます。Edge ノードで異なるフィールドがランタイム データに表示されます。{edge_vsphere_location_mismatch_reason}」

イベントの解決時：「Edge ノード {entity_id} のノードの vSphere の設定が、ポリシー インテントと一致するようになりました。」

この Edge トランスポート ノード {entity_id} の vSphere 構成を確認してください。アラームを解決するには、以下のいずれかのアクションを実行してください。-
1.更新 API POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode を使用して、Edge ノードの vSphere で認識済みの構成を受け入れて、アラームを解決します。
2.前の場所に戻る場合は、NSX Redeploy API - POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy を使用してください。元のホストへの vMotion はサポートされていません。

NSX インベントリに存在する自動 Edge 仮想マシンが vCenter Server に存在しません。

イベントの検出時：「Edge トランスポート ノード {entity_id} の vSphere の配置パラメータに対応する MoRef ID {vm_moref_id} の仮想マシン {policy_edge_vm_name} が NSX インベントリで見つかりましたが、vCenter Server に存在しません。この仮想マシンが vCenter Server で削除されたか、別の MoRef ID で存在しているかどうか確認してください。

イベントの解決時：「MoRef ID {vm_moref_id} の仮想マシンを含む Edge ノード {entity_id} が、NSX インベントリと vCenter Server の両方に存在します。」

仮想マシンの管理対象オブジェクト参照の MoRef ID の形式は vm-number で、vCenter Server ユーザー インターフェイスで Edge 仮想マシンを選択すると URL に表示されます。たとえば、https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary では vm-12011 が ID です。vCenter Server で、この Edge トランスポート ノード {entity_id} の MoRef ID {vm_moref_id} の仮想マシン {policy_edge_vm_name} を見つけます。Edge 仮想マシンが別の MoRef ID で vCenter Server に存在する場合は、次のアクションを行ってください。JSON 要求ペイロード プロパティ vm_id と vm_deployment_config を指定して、NSX の追加または更新置換 API(POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=addOrUpdatePlacementReferences) を使用し、新しい仮想マシンの MoRef ID と vSphere 展開パラメータを更新します。vCenter Server に名前が {policy_edge_vm_name} の Edge 仮想マシンが存在しない場合は、NSX の再展開 API(POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy) を使用して、Edge ノードに新しい仮想マシンを展開します。

NSX インベントリと vCenter Server の両方に自動 Edge 仮想マシンが存在しません。

イベントの検出時：「Edge トランスポート ノード {entity_id} の vSphere 配置パラメータに対応する MoRef ID {vm_moref_id} の仮想マシン {policy_edge_vm_name} が、NSX インベントリと vCenter Server の両方に存在しません。この Edge トランスポート ノード {entity_id} の vSphere 構成の配置パラメータは、MoRef {vm_moref_id} の仮想マシンを参照しています。」

イベントの解決時：「MoRef ID {vm_moref_id} の仮想マシンを含む Edge ノード {entity_id} が、NSX インベントリと vCenter Server の両方に存在します。」

仮想マシンの管理対象オブジェクト参照の MoRef ID の形式は vm-number で、vCenter Server ユーザー インターフェイスで Edge 仮想マシンを選択すると URL に表示されます。たとえば、https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary では vm-12011 が ID です。vCenter Server で、この Edge トランスポート ノード {entity_id} の MoRef ID {vm_moref_id} の仮想マシン {policy_edge_vm_name} を見つけます。次のアクションを行って、アラームを解決してください。- vSphere で仮想マシンが削除されているかどうか、別の MoRef ID で存在しているかどうか確認します。
1.仮想マシンが vCenter Server にまだ存在する場合は、Edge トランスポート ノードをメンテナンス モードにしてから、vCenter Server の Edge 仮想マシンをパワーオフして削除します。NSX の再展開 API を使用して、Edge ノードの新しい仮想マシンを展開します。Edge 仮想マシンがトラフィックを転送している場合、Edge トランスポート ノードのデータ トラフィックは一定の期間内に中断されます。
2.仮想マシンが vCenter Server に存在しない場合は、再展開 API(POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy) を使用して、Edge ノードに新しい仮想マシンを展開します。

再展開中に、vCenter Server で古い Edge 仮想マシンのパワーオフと削除操作に失敗しました。

イベントの検出時：「再展開操作中に、vCenter Server で Edge ノード {entity_id} の MoRef ID {vm_moref_id} の仮想マシンをパワーオフして削除できませんでした。MoRef ID {new_vm_moref_id} の新しい Edge 仮想マシンが展開されています。この Edge の古い仮想マシンと新しい仮想マシンの両方が同時に機能するため、IP の競合やネットワークの問題が発生する可能性があります。」

イベントの解決時：「MoRef ID {vm_moref_id} の古い仮想マシンを含む Edge ノード{entity_id} が、NSX インベントリと vCenter Server の両方で見つかりませんでした。MoRef ID {new_vm_moref_id} の仮想マシンが NSX インベントリと vCenter Server の両方に新しく展開されています。」

仮想マシンの管理対象オブジェクト参照の MoRef ID の形式は vm-number で、vCenter Server ユーザー インターフェイスで Edge 仮想マシンを選択すると URL に表示されます。たとえば、https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary では vm-12011 が ID です。vCenter Server で、この Edge トランスポート ノード {entity_id} の MoRef ID {vm_moref_id} の仮想マシン {policy_edge_vm_name} を見つけます。vCenter Server で、MoRef ID {vm_moref_id} の古い Edge 仮想マシン {policy_edge_vm_name} をパワーオフして削除します。

Edge ノードのハードウェア バージョンが一致しません。

イベントの検出時：「Edge クラスタ {edge_cluster_name} の Edge ノード {transport_node_name} のハードウェア バージョンは {edge_tn_hw_version} ですが、これは、Edge クラスタのハードウェア バージョン {edge_cluster_highest_hw_version} よりも小さいバージョンです。」

イベントの解決時：「これで、Edge ノード {transport_node_name} のハードウェア バージョンの不一致が解決されました。」

ナレッジベースの記事に従って、Edge ノード {transport_node_name} のハードウェア バージョン不一致アラームを解決してください。

Edge クラスタ メンバーの再配置エラー アラーム

イベントの検出時：「Edge クラスタ {edge_cluster_id} で、すべてのサービス コンテキストを再配置する操作が、トランスポート ノード ID {transport_node_id} の Edge クラスタ メンバー インデックス {member_index_id} で失敗しました。」

イベントの解決時：「Edge ノードで失敗した {transport_node_id} の再配置は、現在解決されています。」

Edge クラスタで使用可能なキャパシティを確認します。さらにキャパシティが必要な場合は、Edge クラスタを拡張します。Edge クラスタ メンバーの再配置操作を再試行してください。

Edge ノードの CPU 使用率が非常に高くなっています。

イベントの検出時：「Edge ノード {entity_id} の CPU 使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値に達しているか、超えています。」

イベントの解決時：「Edge ノード {entity_id} の CPU 使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値を下回っています。」

この Edge ノードの構成、実行中のサービス、サイズを確認します。ワークロードに合わせて Edge アプライアンスのフォーム ファクタのサイズを調整するか、他の Edge ノードの間でサービスのリバランシングを行うことを検討してください。

Edge ノードの CPU 使用率が高くなっています。

イベントの検出時：「Edge ノード {entity_id} の CPU 使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。」

イベントの解決時：「Edge ノード {entity_id} の CPU 使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値を下回っています。」

この Edge ノードの構成、実行中のサービス、サイズを確認します。ワークロードに合わせて Edge アプライアンスのフォーム ファクタのサイズを調整するか、他の Edge ノードの間でサービスのリバランシングを行うことを検討してください。

Edge ノードのメモリ使用率が非常に高くなっています。

イベントの検出時：「Edge ノード {entity_id} のメモリ使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値に達しているか、超えています。」

イベントの解決時：「Edge ノード {entity_id} のメモリ使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値を下回っています。」

この Edge ノードの構成、実行中のサービス、サイズを確認します。ワークロードに合わせて Edge アプライアンスのフォーム ファクタのサイズを調整するか、他の Edge ノードの間でサービスのリバランシングを行うことを検討してください。

Edge ノードのメモリ使用率が高くなっています。

イベントの検出時：「Edge ノード {entity_id} のメモリ使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。」

イベントの解決時：「Edge ノード {entity_id} のメモリ使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値を下回っています。」

この Edge ノードの構成、実行中のサービス、サイズを確認します。ワークロードに合わせて Edge アプライアンスのフォーム ファクタのサイズを調整するか、他の Edge ノードの間でサービスのリバランシングを行うことを検討してください。

Edge ノードのディスク使用率が非常に高くなっています。

イベントの検出時：「Edge ノードのディスク パーティション {disk_partition_name} のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値に達しているか、超えています。」

イベントの解決時：「Edge ノードのディスク パーティション {disk_partition_name} のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値を下回っています。」

使用率の高いパーティションを調べ、削除可能なサイズの大きいファイルがあるか確認します。

Edge ノードのディスク使用率が高くなっています。

イベントの検出時：「Edge ノードのディスク パーティション {disk_partition_name} のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。」

イベントの解決時：「Edge ノードのディスク パーティション {disk_partition_name} のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値を下回っています。」

使用率の高いパーティションを調べ、削除可能なサイズの大きいファイルがあるか確認します。

Edge ノードのデータパスの CPU 使用率が非常に高くなっています。

イベントの検出時：「Edge ノード {entity_id} でデータパスの CPU 使用率が {datapath_resource_usage}% に達しています。超高しきい値に達しているか、超えている状態が少なくとも 2 分間続いています。」

イベントの解決時：「Edge ノード {entity_id} の CPU 使用率が超高しきい値を下回りました。」

NSX CLI コマンド get dataplane cpu stats を呼び出して CPU コアあたりのパケット レートを表示し、Edge ノードの CPU 統計情報を確認します。パケット レートが高いと CPU 使用率が高い可能性があります。Edge アプライアンスのフォーム ファクタのサイズを大きくし、同じクラスタの他の Edge ノードまたは別の Edge クラスタとの間でこの Edge ノードのサービスをリバランシングすることを検討してください。

Edge ノードのデータパスの CPU 使用率が高くなっています。

イベントの検出時：「Edge ノード {entity_id} でデータパスの CPU 使用率が {datapath_resource_usage}% に達しています。高しきい値に達しているか、超えている状態が少なくとも 2 分間続いています。」

イベントの解決時：「Edge ノード {entity_id} の CPU 使用率が高しきい値を下回りました。」

NSX CLI コマンド get dataplane cpu stats を呼び出して CPU コアあたりのパケット レートを表示し、Edge ノードの CPU 統計情報を確認します。パケット レートが高いと CPU 使用率が高い可能性があります。Edge アプライアンスのフォーム ファクタのサイズを大きくし、同じクラスタの他の Edge ノードまたは別の Edge クラスタとの間でこの Edge ノードのサービスをリバランシングすることを検討してください。

Edge ノードのデータパスの構成に失敗しました。

イベントの検出時：「3 回試行しましたが、Edge ノードでデータパスを有効にできませんでした。」

イベントの解決時：「Edge ノードのデータパスが有効になりました。」

マネージャ ノードと Edge ノードの接続が良好であることを確認します。サービスの健全性を確認するには、Edge ノードの NSX CLI から get services を呼び出します。データプレーン サービスが停止している場合は、start service dataplane コマンドを呼び出してサービスを起動します。

Edge ノードの暗号ドライバが停止しています。

イベントの検出時：「Edge ノードの暗号ドライバ {edge_crypto_drv_name} が停止しています。」

イベントの解決時：「Edge ノードの暗号ドライバ {edge_crypto_drv_name} が起動しています。」

必要に応じて、Edge ノードをアップグレードします。

Edge ノードのデータパス メモリプールの使用率が高くなっています。

イベントの検出時：「Edge ノード {entity_id} で {mempool_name} のデータパス メモリプールの使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。」

イベントの解決時：「Edge ノード {entity_id} で {mempool_name} のデータパス メモリプールの使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値を下回っています。」

root ユーザーとしてログインし、edge-appctl -t /var/run/vmware/edge/dpd.ctl mempool/show コマンドと edge-appctl -t /var/run/vmware/edge/dpd.ctl memory/show malloc_heap コマンドを呼び出して、DPDK のメモリ使用率を確認します。

Edge ノードのグローバル ARP テーブルの使用率が高くなっています。

イベントの検出時：「Edge ノード {entity_id} でグローバル ARP テーブルの使用率が {datapath_resource_usage}% に達しています。高しきい値に達しているか、超えている状態が 2 分以上続いています。」

イベントの解決時：「Edge ノード {entity_id} でグローバル ARP テーブルの使用率が高しきい値を下回りました。」

root ユーザーとしてログインし、edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/show コマンドを呼び出して、neigh キャッシュの使用率が正常かどうか確認します。正常な場合は、edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/set_param max_entries コマンドを呼び出し、ARP テーブル サイズを大きくします。

Edge ノードの NIC で RX リング バッファが一時的に不足しています。

イベントの検出時：「Edge ノード {entity_id} で Edge NIC {edge_nic_name} の受信リング バッファが {rx_ring_buffer_overflow_percentage}% オーバーフローしています。失われたパケット数は {rx_misses}、処理されたパケット数は {rx_processed} です。」

イベントの解決時：「Edge ノード {entity_id} で Edge NIC {edge_nic_name} の受信リング バッファのオーバーフローが解決されました。」

Edge ノードで NSX CLI コマンド get dataplane cpu stats を実行して、次のことを行います。
1.CPU 使用率が高い場合（90% を超えている場合）は、`start capture interface &ltinterface-name&gt direction input または start capture interface &ltinterface-name&gt direction input core &ltcore-id&gt` コマンド（使用率が高い特定のコアで入力方向のパケットをキャプチャする場合）を実行して、インターフェイスでパケット キャプチャを行います。次に、キャプチャを分析し、大半が断片化パケットまたは IPsec パケットかどうか確認します。該当する場合、これは想定される動作です。それ以外の場合は、データパスで他の処理が実行されている可能性があります。アラームが 2-3 分以上続く場合は、VMware のサポートに連絡してください。
2.CPU 使用率が高くない場合（90% を下回っている場合）は、get dataplane cpu stats コマンドを実行して、rx pps が高いかどうか確認します（トラフィック レートの増加を確認します）。set dataplane ring-size rx コマンドを実行して、リング サイズを 1024 増やします 。注 - 1024 単位でリング サイズを続けて大きくすると、パフォーマンスの問題が発生することがあります。リング サイズを大きくしても問題が解決しない場合は、トラフィック量に合わせてエッジのフォーム ファクタを大きくする必要があります。
3.アラームがフラッピングを続ける場合（トリガされてすぐに解決する場合）、これはトラフィックの急増が原因で発生しています。この場合は、rx pps が前述のように設定されているかどうか確認します。アラームのアクティブ期間中に高い値を示していない場合は、VMware のサポートにお問い合わせください。pps が高い場合は、トラフィックが急増しています。アラームの抑止を検討してください。注 - 高い pps 値を特定するための特別なベンチマークはありません。これは、インフラストラクチャとトラフィックの種類によって決まります。アラームがアクティブでない時間とアクティブな時間を記録することで比較が可能になります。

Edge ノードの NIC で TX リング バッファが一時的に不足しています。

イベントの検出時：「Edge ノード {entity_id} で Edge NIC {edge_nic_name} の送信リング バッファが {tx_ring_buffer_overflow_percentage}% オーバーフローしています。失われたパケット数は {tx_misses}、処理されたパケット数は {tx_processed} です。」

イベントの解決時：「Edge ノード {entity_id} で Edge NIC {edge_nic_name} の送信リング バッファのオーバーフローが解決されました。」

1.ハイパーバイザーにより Edge と一緒に多くの仮想マシンが格納されていると、Edge 仮想マシンが実行されず、ハイパーバイザーがパケットを取得できないことがあります。これにより、仮想マシンの少ないホストに Edge 仮想マシンが移行される可能性があります。
2.`set dataplane ring-size tx` コマンドを使用してリングサイズを 1024 増やします 。リング サイズを大きくしても問題が解決しない場合は、VMware のサポートにお問い合わせください。ESX 側の転送リング バッファの値が小さい可能性があります。ESX 側に問題がない場合は、トラフィックを処理できるように、エッジをより大きなフォーム ファクタにスケーリングする必要があります。
3.アラームがフラッピングを続ける場合（トリガされてすぐに解決する場合）、これはトラフィックの急増が原因で発生しています。この場合は、 get dataplane cpu stats コマンドを使用して tx pps を確認します。アラームのアクティブ期間中に高い値を示していない場合は、VMware のサポートにお問い合わせください。pps が高い場合は、トラフィックが急増しています。アラームの抑止を検討してください。注 - 高い pps 値を特定するための特別なベンチマークはありません。これは、インフラストラクチャとトラフィックの種類によって決まります。アラームがアクティブでない時間とアクティブな時間を記録することで比較が可能になります。

Edge ノードの NIC リンクが停止しています。

イベントの検出時：「Edge ノードの NIC {edge_nic_name} リンクが停止しています。」

イベントの解決時：「Edge ノードの NIC {edge_nic_name} リンクが稼動しています。」

NSX CLI コマンド get interfaces を呼び出し、Edge ノードで NIC リンクが物理的に停止しているかどうかを確認します。停止している場合は、ケーブル接続を確認します。

Edge ノードのディスクは読み取り専用です。

イベントの検出時：「Edge ノードの次のディスク パーティションは読み取り専用モードです：{disk_partition_name}」

イベントの解決時：「Edge ノードの次のディスク パーティションが読み取り専用モードからリカバリされました：{disk_partition_name}」

再起動で問題が解決されたかどうか読み取り専用パーティションを確認します。問題が解決していない場合は、ディスクの交換が必要になります。詳細については、VMware サポートにお問い合わせください。

Edge ノードのデータパス スレッドがデッドロック状態になっています。

イベントの検出時：「Edge ノードのデータパス スレッド {edge_thread_name} がデッドロックしています。」

イベントの解決時：「Edge ノードのデータパス スレッド {edge_thread_name} のデッドロックが解決されました。」

NSX CLI コマンド restart service dataplane を呼び出して、データプレーン サービスを再起動します。

Edge ノードのデータパスの NIC スループットが非常に高くなっています。

イベントの検出時：「Edge ノード {entity_id} で {edge_nic_name} のデータパス NIC のスループットが {nic_throughput}% に達しています。これは、{nic_throughput_threshold}% の超高しきい値に達しているか、超えています。」

イベントの解決時：「Edge ノード {entity_id} で {edge_nic_name} のデータパス NIC のスループットが {nic_throughput}% に達しています。これは、{nic_throughput_threshold}% の超高しきい値を下回っています。」

NIC のトラフィックのスループット レベルを調べ、構成の変更が必要かどうかを判断します。「get dataplane thoughput &ltseconds&gt」コマンドを使用すると、スループットをモニターできます。

Edge ノード データパスの NIC スループットが高くなっています。

イベントの検出時：「Edge ノード {entity_id} で {edge_nic_name} のデータパス NIC のスループットが {nic_throughput}% に達しています。これは、{nic_throughput_threshold}% の高しきい値に達しているか、超えています。」

イベントの解決時：「Edge ノード {entity_id} で {edge_nic_name} のデータパス NIC のスループットが {nic_throughput}% に達しています。これは、{nic_throughput_threshold}% の高しきい値を下回っています。」

NIC のトラフィックのスループット レベルを調べ、構成の変更が必要かどうかを判断します。「get dataplane thoughput &ltseconds&gt」コマンドを使用すると、スループットをモニターできます。

障害ドメインのすべてのメンバーが停止しています。

イベントの検出時：「障害ドメイン {transport_node_id} のすべてのメンバーが停止しています。」

イベントの解決時：「障害ドメイン {transport_node_id} のすべてのメンバーに到達可能です。」

1.{transport_node_id} で識別される Edge ノードで、NSX CLI コマンド get managers と get controllers を呼び出して、管理プレーンと制御プレーンとの接続を確認します。
2.NSX CLI コマンド get interface eth0 を呼び出して、管理インターフェイスの状態を確認します。
3.CLI get services を呼び出して、dataplane/local-controller/nestdb/router などのコア サービスの状態を確認します。
4./var/log/syslog で、疑わしいエラーを確認します。
5.Edge ノードを再起動します。

micro フローのキャッシュ ヒット率が低下し、データパス CPU が増加しています。

イベントの検出時：「過去 30 分間に、Edge ノード {entity_id} の micro フローのキャッシュ ヒット率がコア {core_id} で指定されたしきい値の {flow_cache_threshold}% を下回り、データパス CPU 使用率が増加しました。」

イベントの解決時：「フローのキャッシュ ヒット率は正常な範囲内にあります。」

過去 30 分間キャッシュ フローのヒット率が低下しています。これは、Edge のパフォーマンスが低下している可能性を示しています。トラフィックが引き続き転送され、問題が発生しない可能性があります。過去 30 分間に Edge {entity_id} コア {core_id} のデータパス CPU 使用率が高くなっているかどうかを確認します。新しいフローの最初のパケットを使用して高速パス処理のフロー キャッシュが設定されるため、新しいフローが継続的に作成されると、Edge のフロー キャッシュ ヒット率が低くなります。Edge アプライアンスのサイズを増やすか、アクティブ/アクティブ ゲートウェイに使用される Edge ノードの数を増やすことができます。

mega フローのキャッシュ ヒット率が低下し、データパス CPU が高くなります。

イベントの検出時：「過去 30 分間に、Edge ノード {entity_id} の mega フローのキャッシュ ヒット率がコア {core_id} で指定されたしきい値の {flow_cache_threshold}% を下回り、データパス CPU 使用率が増加しました。」

イベントの解決時：「フローのキャッシュ ヒット率は正常な範囲内にあります。」

過去 30 分間キャッシュ フローのヒット率が低下しています。これは、Edge のパフォーマンスが低下している可能性を示しています。トラフィックが引き続き転送され、問題が発生しない可能性があります。過去 30 分間に Edge {entity_id} コア {core_id} のデータパス CPU 使用率が高くなっているかどうかを確認します。新しいフローの最初のパケットを使用して高速パス処理のフロー キャッシュが設定されるため、新しいフローが継続的に作成されると、Edge のフロー キャッシュ ヒット率が低くなります。Edge アプライアンスのサイズを増やすか、アクティブ/アクティブ ゲートウェイに使用される Edge ノードの数を増やすことができます。

コンピュート マネージャの ESX Agent Manager (EAM) サービスが停止しています。

イベントの検出時：「コンピュート マネージャ {entity_id} の ESX Agent Manager (EAM) サービスが停止しています。」

イベントの解決時：「コンピュート マネージャ {entity_id} の ESX Agent Manager (EAM) サービスが起動しているか、コンピュート マネージャ {entity_id} が削除されています。」

ESX Agent Manager (EAM) サービスを開始します。SSH で vCenter Server に接続し、service vmware-eam start コマンドを呼び出します。

ホスト モジュールとパートナー サービス仮想マシンの接続が停止しています。

イベントの検出時：「ホスト モジュールとパートナー サービス仮想マシン {entity_id} の接続が停止しています。」

イベントの解決時：「ホスト モジュールとパートナー サービス仮想マシン {entity_id} の接続が開始しています。」

https://kb.vmware.com/s/article/85844 を参照して、パートナー サービス仮想マシン {entity_id} がホスト モジュールに再接続されていることを確認してください。

RTEP BGP ネイバーが停止しています。

イベントの検出時：「送信元 IP {bgp_source_ip} からリモートの場所 {remote_site_name} のネイバー IP {bgp_neighbor_ip} への RTEP（リモート トンネル エンドポイント）BGP セッションが停止しています。原因: {failure_reason}。」

イベントの解決時：「送信元 IP {bgp_source_ip} からリモートの場所 {remote_site_name} のネイバー IP {bgp_neighbor_ip} への RTEP（リモート トンネル エンドポイント）BGP セッションが確立されました。」

1.影響を受ける Edge ノードで NSX CLI コマンド get logical-routers を呼び出します。
2.REMOTE_TUNNEL_VRF コンテキストに切り替えます。
3.NSX CLI コマンド get bgp neighbor summary を呼び出し、BGP ネイバーの状態を確認します。
4.または、NSX API GET /api/v1/transport-nodes/&lttransport-node-id&gt/inter-site/bgp/summary を呼び出して、BGP ネイバーの状態を取得します。
5.NSX CLI コマンド get interfaces を呼び出し、remote-tunnel-endpoint という名前の正しい RTEP IP アドレスがインターフェイスに割り当てられているかどうか確認します。
6.割り当てられた RTEP IP アドレス ({bgp_source_ip}) とリモートの場所 {remote_site_name} のネイバー IP {bgp_neighbor_ip} 間で ping が正常に機能しているかどうかを確認します。
7./var/log/syslog で BGP に関連するエラーがないか確認します。
8.NSX API GET または PUT /api/v1/transport-nodes/&lttransport-node-id&gt を呼び出し、Edge ノードの remote_tunnel_endpoint 構成を取得または更新します。これにより、影響を受ける Edge ノードに割り当てられた RTEP IP アドレスが更新されます。理由が「Edge の準備ができていません」と示されている場合は、Edge ノードが良好な状態でない理由を確認します。
1.NSX CLI コマンド get edge-cluster status を呼び出して、Edge ノードが停止している理由を確認します。
2.NSX CLI コマンド get bfd-config と get bfd-sessions を呼び出して、BFD が正常に実行されているかどうかを確認します。
3.Edge の健全性に関連するアラームをチェックして、詳細を確認します。

リモート サイト間の同期が 3 分以上失敗しています。

イベントの検出時：「{site_name}({site_id}) と {remote_site_name}({remote_site_id}) 間の同期が 3 分以上失敗しています。」

イベントの解決時：「リモートの場所 {site_name}({site_id}) と {remote_site_name}({remote_site_id}) が同期されました。」

1.NSX CLI コマンド get site-replicator remote-sites を呼び出して、リモートの場所間の接続状態を取得します。リモートの場所が接続されていて、同期されていない場合は、その場所でのマスター解決のプロセスが実行中である可能性があります。その場合は、10 秒ほど待ってから、CLI を再度呼び出し、リモートの場所の状態を確認します。場所が切断されている場合は、次の手順を実行します。
2.ping を実行して、場所 {site_name}({site_id}) のローカル マネージャ (LM) から場所 {remote_site_name}({remote_site_id}) の LM への接続状態を確認します。ping できない場合は、WAN 接続が切断されやすいかを確認します。物理ネットワーク接続の問題がない場合は、次の手順を実行します。
3.アラームをトリガした場所 {site_name}({site_id}) のローカル クラスタでマネージャ ノードの /var/log/cloudnet/nsx-ccp.log ファイルをチェックして、サイト間で通信エラーが発生しているかどうか確認します。さらに、/var/log/syslog 内の nsx-appl-proxy サブコンポーネントによってログに記録されたエラーも確認します。

リモート サイト間の同期が 15 分以上失敗しています。

イベントの検出時：「{site_name}({site_id}) と {remote_site_name}({remote_site_id}) 間の同期が 15 分以上失敗しています。」

イベントの解決時：「リモート サイト {site_name}({site_id}) と {remote_site_name}({remote_site_id}) が同期されました。」

1.NSX CLI コマンド get site-replicator remote-sites を呼び出し、リモートの場所間の接続状態を取得します。リモートの場所が接続されていて、同期されていない場合は、その場所でのマスター解決のプロセスが実行中である可能性があります。その場合は、10 秒ほど待ってから、CLI を再度呼び出し、リモートの場所の状態を確認します。場所が切断されている場合は、次の手順を実行します。
2.ping を実行して、場所 {site_name}({site_id}) のローカル マネージャ (LM) から場所 {remote_site_name}({remote_site_id}) の LM への接続状態を確認します。ping できない場合は、WAN 接続が切断されやすいかを確認します。物理ネットワーク接続の問題がない場合は、次の手順を実行します。
3.アラームをトリガした場所 {site_name}({site_id}) のローカル クラスタでマネージャ ノードの /var/log/cloudnet/nsx-ccp.log ファイルをチェックし、サイト間で通信エラーが発生しているかどうか確認します。さらに、/var/log/syslog 内の nsx-appl-proxy サブコンポーネントによってログに記録されたエラーも確認します。

RTEP の場所との接続が切断されました。

イベントの検出時：「Edge ノード {transport_node_name} で、リモートの場所 {remote_site_name} との RTEP（リモート トンネル エンドポイント）接続が失われました。」

イベントの解決時：「Edge ノード {transport_node_name} で、リモートの場所 {remote_site_name} との RTEP（リモート トンネル エンドポイント）接続がリストアされました。」

1.影響を受けた Edge ノード {transport_node_name} で NSX CLI コマンド get logical-routers を呼び出します。
2.REMOTE_TUNNEL_VRF コンテキストに切り替えます。
3.NSX CLI コマンド get bgp neighbor summary を呼び出し、BGP ネイバーの状態を確認します。
4.または、NSX API GET /api/v1/transport-nodes/&lttransport-node-id&gt/inter-site/bgp/summary を呼び出して、BGP ネイバーの状態を取得します。
5.NSX CLI コマンド get interfaces を呼び出して、remote-tunnel-endpoint という名前の正しい RTEP IP アドレスがインターフェイスに割り当てられているかどうか確認します。
6.割り当てられた RTEP IP アドレスとリモートの場所 {remote_site_name} の RTEP IP アドレスの間で ping に成功しているかどうかを確認します。
7./var/log/syslog で BGP に関連するエラーがないか確認します。
8.NSX API GET または PUT /api/v1/transport-nodes/&lttransport-node-id&gt を呼び出して、Edge ノードの remote_tunnel_endpoint 構成を取得または更新します。これにより、影響を受ける Edge ノード {transport_node_name} に割り当てられた RTEP IP が更新されます。

複数のグローバル マネージャ ノードが同時にアクティブになっています。

イベントの検出時：「複数のグローバル マネージャ ノード{active_global_managers} がアクティブになっています。常にアクティブにする必要があるグローバル マネージャ ノードは 1 つだけです。」

イベントの解決時：「現在アクティブなグローバル マネージャ ノードは {active_global_manager} だけです。」

1 つのグローバル マネージャ ノードをアクティブとして構成し、他のグローバル マネージャ ノードはすべてスタンバイとして構成します。

グローバル マネージャ間の遅延が 2 分以上想定レベルを超えています。

イベントの検出時：「グローバル マネージャ {from_gm_path} と {to_gm_path} の間の遅延が想定レベルを超えています。」

イベントの解決時：「グローバル マネージャ {from_gm_path} と {to_gm_path} の間の遅延が想定レベルを下回っています。」

ping を使用して、グローバル マネージャ {from_gm_path}({site_id}) からグローバル マネージャ {to_gm_path}({remote_site_id}) への接続を確認します。ping できない場合は、WAN 接続が切断されやすいかを確認します。

アクティブ グローバル マネージャとスタンバイ グローバル マネージャを同期できません。

イベントの検出時：「アクティブ グローバル マネージャ {from_gm_path} とスタンバイ グローバル マネージャ {to_gm_path} を同期できません。」

イベントの解決時：「アクティブ グローバル マネージャ {from_gm_path} からスタンバイ {to_gm_path} への同期は正常な状態です。」

ping を使用して、グローバル マネージャ {from_gm_path}({site_id}) からグローバル マネージャ {to_gm_path}({remote_site_id}) への接続を確認します。

アクティブ グローバル マネージャとスタンバイ グローバル マネージャが 5 分以上同期されていません

イベントの検出時：「アクティブ グローバル マネージャ {from_gm_path} とスタンバイ グローバル マネージャ {to_gm_path} が 5 分以上同期されていません。」

イベントの解決時：「アクティブ グローバル マネージャ {from_gm_path} からスタンバイ {to_gm_path} への同期は正常な状態です。」

ping を使用して、グローバル マネージャ {from_gm_path}({site_id}) からグローバル マネージャ {to_gm_path}({remote_site_id}) への接続を確認します。

グローバル マネージャ (GM) とローカル マネージャ (LM) 間のデータ同期が失敗しました。

イベントの検出時：「{flow_identifier} で、サイト {site_name}({site_id}) と {remote_site_name}({remote_site_id}) の間のデータ同期に失敗しました。原因: {sync_issue_reason}」

イベントの解決時：「{flow_identifier} でサイト {site_name}({site_id}) と {remote_site_name}({remote_site_id}) が同期されました。」

1.ping を使用して、リモート サイトとローカル サイト間のネットワーク接続を確認します。
2.ローカル サイトとリモート サイト間でポート TCP/1236 のトラフィックが許可されていることを確認します。
3.async-replicator サービスがローカル サイトとリモート サイトの両方で実行されていることを確認します。GET /api/v1/node/services/async_replicator/status NSX API または get service async_replicator NSX CLI コマンドを呼び出し、サービスが実行されているかどうか確認します。実行されていない場合は、POST /api/v1/node/services/async_replicator?action=restart NSX API または restart service async_replicator NSX CLI を呼び出し、サービスを再起動します。
4./var/log/async-replicator/ar.log で、エラーが報告されているかどうか確認します。

グローバル マネージャ (GM) とローカル マネージャ (LM) 間のデータ同期が長期間失敗しています。

イベントの検出時：「{flow_identifier} でサイト {site_name}({site_id}) と {remote_site_name}({remote_site_id}) 間のデータ同期が長時間失敗しています。原因: {sync_issue_reason}。」

イベントの解決時：「{flow_identifier} でサイト {site_name}({site_id}) と {remote_site_name}({remote_site_id}) が同期されました。」

1.ping を使用して、リモート サイトとローカル サイト間のネットワーク接続を確認します。
2.ローカル サイトとリモート サイト間でポート TCP/1236 のトラフィックが許可されていることを確認します。
3.async-replicator サービスがローカル サイトとリモート サイトの両方で実行されていることを確認します。GET /api/v1/node/services/async_replicator/status NSX API または get service async_replicator NSX CLI コマンドを呼び出し、サービスが実行されているかどうか確認します。実行されていない場合は、POST /api/v1/node/services/async_replicator?action=restart NSX API または restart service async_replicator NSX CLI を呼び出して、サービスを再起動します。
4./var/log/async-replicator/ar.log で、エラーが報告されているかどうか確認します。
5.サポート バンドルを収集して、NSX サポート チームに連絡してください。

キュー占有率のサイズしきい値が警告レベルを超えました。

イベントの検出時：「{site_name}({site_id}) と {remote_site_name}({remote_site_id}) のサイト間のデータ同期に使用されるキュー ({queue_name}) のサイズが {queue_size} に達しました。これは、{queue_size_threshold}% の最大しきい値に達しているか、超えています。」

イベントの解決時：「{site_name}({site_id}) と {remote_site_name}({remote_site_id}) のサイト間のデータ同期に使用されるキュー ({queue_name}) のサイズが {queue_size} に達しました。これは、{queue_size_threshold}% の最大しきい値を下回っています。」

リモート サイトまたは過負荷状態のシステムとの通信の問題が原因でキュー サイズがしきい値を超える場合があります。システム パフォーマンスと /var/log/async-replicator/ar.log をチェックして、エラーが報告されていないかどうか確認します。

グローバル マネージャとローカル マネージャ間の遅延が 2 分以上、想定レベルを超えています。

イベントの検出時：「サイト {site_name}({site_id}) と {remote_site_name}({remote_site_id}) 間の遅延が {latency_value} に達しました。これは、{latency_threshold} のしきい値を超えています。」

イベントの解決時：「サイト {site_name}({site_id}) と {remote_site_name}({remote_site_id}) 間の遅延が {latency_value} に達しました。これは、{latency_threshold} のしきい値を下回っています。」

1.ping を使用して、リモート サイトとローカル サイト間のネットワーク接続を確認します。
2.ローカル サイトとリモート サイト間でポート TCP/1236 のトラフィックが許可されていることを確認します。
3./var/log/async-replicator/ar.log で、エラーが報告されているかどうか確認します。

グローバル マネージャで構成のインポート中にローカル マネージャがリストアされました。

イベントの検出時：「{site_name}({site_id}) サイトからの構成のインポートが進行中です。ただし、管理者によってサイト {site_name}({site_id}) がバックアップからリストアされ、不整合な状態になっています。」

イベントの解決時：「サイト {site_name}({site_id}) の構成の不整合が解決されました。」

1.NSX Global Manager アプライアンスの CLI にログインします。
2.root に切り替えます。
3.ローカル モードで NSX API DELETE http://localhost:64440 /gm/api/v1/infra/sites/&ltsite-name&gt/onboarding/status を呼び出します。グローバル マネージャのサイト オンボーディング状態が削除されます。
4.構成のオンボーディングを再度開始します。

IP トラフィックのゲートウェイ ファイアウォール フロー テーブルの使用率が高くなっています。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。

イベントの検出時：「論理ルーター {entity_id} で IP のゲートウェイ ファイアウォール フロー テーブルの使用率が {firewall_ip_flow_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。」

イベントの解決時：「論理ルーター {entity_id} で、IP 以外のフローのゲートウェイ ファイアウォール フロー テーブルの使用率が {system_usage_threshold}% の高しきい値を下回りました。」

Edge ノードに admin ユーザーとしてログインし、適切なインターフェイス UUID を使用して NSX CLI コマンド get firewall &ltLR_INT_UUID&gt interface stats | json を呼び出し、IP フローのフロー テーブルの使用量を確認します。ゲートウェイを通過するトラフィック フローが DOS 攻撃またはアノマリ バーストではないことを確認します。トラフィックが通常の負荷の範囲内に見えても、アラームしきい値に到達した場合は、アラームしきい値を増やすか、新しいトラフィックを別の Edge ノードにルーティングすることを検討します。

IP トラフィックのゲートウェイ ファイアウォール フロー テーブルが、設定されたしきい値を超えました。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。

イベントの検出時：「論理ルーター {entity_id} で IP トラフィックのゲートウェイ ファイアウォール フロー テーブルの使用率が {firewall_ip_flow_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。」

イベントの解決時：「論理ルーター {entity_id} でゲートウェイ ファイアウォール フロー テーブルの使用率が {system_usage_threshold}% の高しきい値を下回りました。」

Edge ノードに admin ユーザーとしてログインし、適切なインターフェイス UUID を使用して NSX CLI コマンド get firewall &ltLR_INT_UUID&gt interface stats | json を呼び出し、IP フローのフロー テーブルの使用量を確認します。ゲートウェイを通過するトラフィック フローが DOS 攻撃またはアノマリ バーストではないことを確認します。トラフィックが通常の負荷の範囲内に見えても、アラームしきい値に到達した場合は、アラームしきい値を増やすか、新しいトラフィックを別の Edge ノードにルーティングすることを検討します。

UDP トラフィックのゲートウェイ ファイアウォール フロー テーブルの使用率が高くなっています。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。

イベントの検出時：「論理ルーター {entity_id} で UDP のゲートウェイ ファイアウォール フロー テーブルの使用率が {firewall_udp_flow_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。」

イベントの解決時：「論理ルーター {entity_id} で UDP のゲートウェイ ファイアウォール フロー テーブルの使用率が高しきい値を下回りました。」

Edge ノードに admin ユーザーとしてログインし、適切なインターフェイス UUID を使用して NSX CLI コマンド get firewall &ltLR_INT_UUID&gt interface stats | json を呼び出し、UDP フローのフロー テーブルの使用量を確認します。ゲートウェイを通過するトラフィック フローが DOS 攻撃またはアノマリ バーストではないことを確認します。トラフィックが通常の負荷の範囲内に見えても、アラームしきい値に到達した場合は、アラームしきい値を増やすか、新しいトラフィックを別の Edge ノードにルーティングすることを検討します。

UDP トラフィックのゲートウェイ ファイアウォール フロー テーブルが、設定されたしきい値を超えました。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。

イベントの検出時：「論理ルーター {entity_id} で UDP トラフィックのゲートウェイ ファイアウォール フロー テーブルの使用率が {firewall_udp_flow_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。」

イベントの解決時：「論理ルーター {entity_id} でゲートウェイ ファイアウォール フロー テーブルの使用率が高しきい値を下回りました。」

Edge ノードに admin ユーザーとしてログインし、適切なインターフェイス UUID を使用して NSX CLI コマンド get firewall &ltLR_INT_UUID&gt interface stats | json を呼び出し、UDP フローのフロー テーブルの使用量を確認します。ゲートウェイを通過するトラフィック フローが DOS 攻撃またはアノマリ バーストではないことを確認します。トラフィックが通常の負荷の範囲内に見えても、アラームしきい値に到達した場合は、アラームしきい値を増やすか、新しいトラフィックを別の Edge ノードにルーティングすることを検討します。

ICMP トラフィックのゲートウェイ ファイアウォール フロー テーブルの使用率が高くなっています。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。

イベントの検出時：「論理ルーター {entity_id} で ICMP のゲートウェイ ファイアウォール フロー テーブルの使用率が {firewall_icmp_flow_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。」

イベントの解決時：「論理ルーター {entity_id} で ICMP のゲートウェイ ファイアウォール フロー テーブルの使用率が {system_usage_threshold}% の高しきい値を下回りました。」

Edge ノードに admin ユーザーとしてログインし、適切なインターフェイス UUID を使用して NSX CLI コマンド get firewall &ltLR_INT_UUID&gt interface stats | json を呼び出し、ICMP フローのフロー テーブルの使用量を確認します。ゲートウェイを通過するトラフィック フローが DOS 攻撃またはアノマリ バーストではないことを確認します。トラフィックが通常の負荷の範囲内に見えても、アラームしきい値に到達した場合は、アラームしきい値を増やすか、新しいトラフィックを別の Edge ノードにルーティングすることを検討します。

ICMP トラフィックのゲートウェイ ファイアウォール フロー テーブルが、設定されたしきい値を超えました。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。

イベントの検出時：「論理ルーター {entity_id} で ICMP トラフィックのゲートウェイ ファイアウォール フロー テーブルの使用率が {firewall_icmp_flow_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。」

イベントの解決時：「論理ルーター {entity_id} でゲートウェイ ファイアウォール フロー テーブルの使用率が {system_usage_threshold}% の高しきい値を下回りました。」

Edge ノードに admin ユーザーとしてログインし、適切なインターフェイス UUID を使用して NSX CLI コマンド get firewall &ltLR_INT_UUID&gt interface stats | json を呼び出し、ICMP フローのフロー テーブルの使用量を確認します。ゲートウェイを通過するトラフィック フローが DOS 攻撃またはアノマリ バーストではないことを確認します。トラフィックが通常の負荷の範囲内に見えても、アラームしきい値に到達した場合は、アラームしきい値を増やすか、新しいトラフィックを別の Edge ノードにルーティングすることを検討します。

TCP ハーフオープン トラフィックのゲートウェイ ファイアウォール フロー テーブルの使用率が高くなっています。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。

イベントの検出時：「論理ルーター {entity_id} で TCP のゲートウェイ ファイアウォール フロー テーブルの使用率が {firewall_halfopen_flow_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。」

イベントの解決時：「論理ルーター {entity_id} で TCP ハーフ オープンのゲートウェイ ファイアウォール フロー テーブルの使用率が {system_usage_threshold}% の高しきい値を下回りました。」

Edge ノードに admin ユーザーとしてログインし、適切なインターフェイス UUID を使用して NSX CLI コマンド get firewall &ltLR_INT_UUID&gt interface stats | json を呼び出し、TCP ハーフオープン フローのフロー テーブルの使用量を確認します。ゲートウェイを通過するトラフィック フローが DOS 攻撃またはアノマリ バーストではないことを確認します。トラフィックが通常の負荷の範囲内に見えても、アラームしきい値に到達した場合は、アラームしきい値を増やすか、新しいトラフィックを別の Edge ノードにルーティングすることを検討します。

TCP ハーフ オープン トラフィックのゲートウェイ ファイアウォール フロー テーブルが、設定されたしきい値を超えました。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。

イベントの検出時：「論理ルーター {entity_id} で TCP ハーフ オープン トラフィックのゲートウェイ ファイアウォール フロー テーブルの使用率が {firewall_halfopen_flow_usage}% になりました。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。使用率が上限に達すると、新しいフローはゲートウェイ ファイアウォールによってドロップされます。」

イベントの解決時：「論理ルーター {entity_id} でゲートウェイ ファイアウォール フロー テーブルの使用率が {system_usage_threshold}% の高しきい値を下回りました。」

Edge ノードに admin ユーザーとしてログインし、適切なインターフェイス UUID を使用して NSX CLI コマンド get firewall &ltLR_INT_UUID&gt interface stats | json を呼び出し、TCP ハーフオープン フローのフロー テーブルの使用量を確認します。ゲートウェイを通過するトラフィック フローが DOS 攻撃またはアノマリ バーストではないことを確認します。トラフィックが通常の負荷の範囲内に見えても、アラームしきい値に到達した場合は、アラームしきい値を増やすか、新しいトラフィックを別の Edge ノードにルーティングすることを検討します。

変換されたグループ要素の合計数が上限を超えました。

イベントの検出時：「グループ {group_id} に {group_size} 以上の変換された要素があります。これは {group_max_number_limit} の最大数に達しているか、それを超えています。このため、処理時間が長くなり、タイムアウトや停止が発生する可能性があります。各要素タイプの現在の値は次のとおりです。IP セット：{ip_count}、MAC セット：{mac_count}、VIFS：{vif_count}、論理スイッチ ポート：{lsp_count}、論理ルーター ポート：{lrp_count}、AdGroup：{sid_count}。」

イベントの解決時：「グループ {group_id} の要素の合計数が上限の {group_max_number_limit} を下回っています。」

1.サイズが大きすぎるグループ {group_id} のグループ要素を調整することを検討してください。
2.サイズが大きすぎるグループ {group_id} を複数の小さなグループに分割し、サイズが大きすぎるグループのメンバーをこれらのグループに分散することを検討してください。

Tier-0 ゲートウェイがフェイルオーバーしました。

イベントの検出時：「Tier-0 ゲートウェイ {entity_id} は、{previous_gateway_state} から {current_gateway_state}、service-router {service_router_id} にフェイルオーバーされます。」

イベントの解決時：「Tier-0 ゲートウェイ {entity_id} が起動しました。」

NSX CLI コマンド get logical-router &ltservice_router_id&gt を呼び出して、tier0 service-router vrf ID を取得します。vrf &ltvrf-id&gt を呼び出して vrf コンテキストに切り替え、get high-availability status を呼び出して、停止しているサービスを確認します。

Tier-1 ゲートウェイがフェイルオーバーしました。

イベントの検出時：「Tier-1 ゲートウェイ {entity_id} は、{previous_gateway_state} から {current_gateway_state}、service-router {service_router_id} にフェイルオーバーされます。」

イベントの解決時：「Tier-1 ゲートウェイ {entity_id} が起動しました。」

NSX CLI コマンド get logical-router &ltservice_router_id&gt を呼び出して、tier1 service-router vrf ID を取得します。vrf &ltvrf-id&gt を呼び出して vrf コンテキストに切り替え、get high-availability status を呼び出して、停止しているサービスを確認します。

サービス グループにアクティブなインスタンスがありません。

イベントの検出時：「サービス グループ クラスタ {entity_id} には、現在アクティブなインスタンスがありません。Edge ノード{transport_node_id} では {ha_state} の状態にあり（0 は停止、1 はスタンバイ、2 はアクティブ）、Edge ノード {transport_node_id2} では {ha_state2} の状態にあります。」

イベントの解決時：「Tier-0 service-group クラスタ {entity_id} で Edge ノード {transport_node_id} に 1 つのアクティブなインスタンスが追加されました。」

NSX CLI コマンド get logical-router &ltservice_router_id&gt service_group を呼び出し、指定された service-router で構成されているすべての service-groups を確認します。出力で、service-groups がアクティブ状態を終了した理由を調べます。

サービス グループにアクティブなインスタンスがありません。

イベントの検出時：「サービス グループ クラスタ {entity_id} には、現在アクティブなインスタンスがありません。Edge ノード{transport_node_id} では {ha_state} の状態にあり（0 は停止、1 はスタンバイ、2 はアクティブ）、Edge ノード {transport_node_id2} では {ha_state2} の状態にあります。」

イベントの解決時：「Tier-1 service-group クラスタ {entity_id} で Edge ノード {transport_node_id} に 1 つのアクティブなインスタンスが追加されました。」

NSX CLI コマンド get logical-router &ltservice_router_id&gt service_group を呼び出し、指定された service-router で構成されているすべての service-groups を確認します。出力で、service-groups がアクティブ状態を終了した理由を調べます。

サービス グループのスタンバイ インスタンスが失敗しました。

イベントの検出時：「Edge ノード {transport_node_id} の Tier-0 service-router {service_router_id} に接続された service-group クラスタ {entity_id} が失敗しました。その結果、現在、service-group クラスタにはスタンバイ インスタンスがありません。」

イベントの解決時：service-group クラスタ {entity_id} は Edge ノード {transport_node_id} で状態 {ha_state} にあり（0 は停止、1 はスタンバイ、2 はアクティブ）、Edge ノード {transport_node_id2} で状態 {ha_state2} にあります。」

NSX CLI コマンド get logical-router &ltservice_router_id&gt service_group を呼び出し、指定された service-router で構成されているすべての service-groups を確認します。出力で、以前のスタンバイ service-group が失敗した理由を調べます。

サービス グループのスタンバイ インスタンスが失敗しました。

イベントの検出時：「Edge ノード {transport_node_id} の Tier-1 service-router {service_router_id} に接続された service-group クラスタ {entity_id} が失敗しました。その結果、現在、service-group クラスタにはスタンバイ インスタンスがありません。」

イベントの解決時：service-group クラスタ {entity_id} は Edge ノード {transport_node_id} で状態 {ha_state} にあり（0 は停止、1 はスタンバイ、2 はアクティブ）、Edge ノード {transport_node_id2} で状態 {ha_state2} にあります。」

NSX CLI コマンド get logical-router &ltservice_router_id&gt service_group を呼び出し、指定された service-router で構成されているすべての service-groups を確認します。出力で、以前のスタンバイ service-group が失敗した理由を調べます。

LDAP サーバとの接続が切断されました。

イベントの検出時：「LDAP サーバ {ldap_server} との接続が切断されました。」

イベントの解決時：「LDAP サーバ {ldap_server} との接続がリストアされました。」

次のことを確認します。
1.NSX ノードから LDAP サーバに到達可能です。
2.NSX で LDAP サーバの詳細が正しく構成されています。
3.LDAP サーバが正常に実行されています。
4.LDAP サーバと NSX ノード間のアクセスをブロックするファイアウォールは存在しません。問題が解決したら、NSX UI からテスト接続を行い、Identity Firewall の Active Directory で接続をテストします。

差分同期の実行中にエラーが発生しました。

イベントの検出時：「{directory_domain} との差分同期の実行中にエラーが発生しました。」

イベントの解決時：「{directory_domain} との差分同期の実行中にエラーは発生していません。」

1.LDAP サーバとの切断を表すアラームがあるかどうか確認します。
2./var/log/syslog でエラーの詳細を確認します。アラームのトリガ時間の近くで「LDAP オブジェクトと同期する際にエラーが発生しました」というテキストを探します。
3.最近 Active Directory に変更を行ったかどうか Active Directory の管理者に確認します。この変更がエラーの原因となっている可能性があります。
4.エラーが解決しない場合は、テクニカル サポート バンドルを収集して VMware テクニカル サポートにお問い合わせください。

Edge ノードのトンネル状態が「停止」になっています。

イベントの検出時：「Edge ノード {entity_id} のトンネルの全体的な状態が「停止」となっています。」

イベントの解決時：「Edge ノード {entity_id} のトンネルがリストアされました。」

NSX CLI コマンド get tunnel-ports を呼び出して、すべてのトンネル ポートを取得します。NSX CLI コマンド get tunnel-port &ltUUID&gt stats を呼び出して、各トンネルの統計情報を取得し、ドロップがあるかどうかを確認します。トンネル関連のエラーが発生している場合は、/var/log/syslog を確認します。

DPU でのサービスの状態が異常です。

イベントの検出時：「DPU {dpu_id} でサービス {service_name} が 10 秒間応答していません。」

イベントの解決時：「DPU {dpu_id} でサービス {service_name} は応答可能な状態になりました。」

/etc/init.d/{service_name} status を呼び出し、DPU {dpu_id} で {service_name} サービスが実行中であることを確認します。サービスが実行中の場合、/etc/init.d/{service_name} restart を使用して再起動が必要になることがあります。status コマンドを再度実行して、サービスが実行中であることを確認します。サービスを再起動しても問題が解決しない場合、または再起動に成功した後に問題が再発した場合は、VMware のサポートにお問い合わせください。

サービスの状態が異常です。

イベントの検出時：「サービス {service_name} が 10 秒間応答していません。」

イベントの解決時：「サービス {service_name} は応答可能な状態になりました。」

/etc/init.d/{service_name} status を呼び出して、{service_name} サービスが実行中であることを確認します。サービスが実行中の場合、/etc/init.d/{service_name} restart を使用して再起動が必要になることがあります。status コマンドを再度実行して、サービスが実行中であることを確認します。スクリプト /etc/init.d/{service_name} が使用できない場合は、systemctl {service_name} status を呼び出し、root 権限で systemctl {service_name} restart を実行して再起動します。サービスを再起動しても問題が解決しない場合、または再起動に成功した後に問題が再発した場合は、VMware のサポートにお問い合わせください。

指定されたターゲットにメトリックを配信できませんでした。

イベントの検出時：「SHA からターゲット {metrics_target_alias}({metrics_target_address}:{metrics_target_port}) へのメトリックの配信に失敗しました。」

イベントの解決時：「ターゲット {metrics_target_alias}({metrics_target_address}:{metrics_target_port}) へのメトリック配信がリカバリされました。」

ユーザーは、障害の原因となっている問題を除外するために、次のチェックを実行する必要があります。1.接続に渡されたターゲット アドレス {metrics_target_address} とポート {metrics_target_port}（ポートが指定されていない場合、デフォルトは 443）が想定されるターゲットであるかどうかを確認します。2./opt/vmware/nsx-nestdb/bin/nestdb-cli --cmd 'put vmware.nsx.nestdb.CommonAgentHostConfigMsg' を使用して証明書が正しいか確認します。3.ターゲット {metrics_target_address} にアクセスできるかどうかを確認します。4.docker ps | grep metrics_manager を使用して、ターゲット {metrics_target_address} のメトリック マネージャが実行されているかどうかを確認します。5.netstat -a | grep {metrics_target_port} を使用して、ターゲットでポート {metrics_target_port} が開いているかどうかを確認します。6.iptables -S OUTPUT | grep {metrics_target_port} (EDGE/UA) または localcli network firewall ruleset list | grep nsx-sha-tsdb (ESX) を使用して、ALLOW ファイアウォール ルールがノードにインストールされているかどうかを確認します。7.SHA デーモンを再起動して、/etc/init.d/netopa restart (ESX)、/etc/init.d/nsx-netopa restart (EDGE)、または /etc/init.d/nsx-sha restart (UA) によって解決できるかどうかを確認します。

Edge サービスが少なくとも 1 分間停止しています。

イベントの検出時：「サービス {edge_service_name} が少なくとも 1 分間停止しています。{service_down_reason}」

イベントの解決時：「サービス {edge_service_name} は起動しています。」

Edge ノードで、/var/log/core ディレクトリにあるコア ファイルをチェックし、エラーが原因でサービスが終了していないことを確認します。また、NSX CLI コマンドget services を呼び出し、サービスが停止しているかどうかを確認します。停止している場合は、start service &ltservice-name&gt を呼び出し、サービスを再起動します。

Edge サービスの状態が変更されました。

イベントの検出時：「サービス {edge_service_name} が {previous_service_state} から {current_service_state} に変更されました。{service_down_reason}」

イベントの解決時：「サービス {edge_service_name} が {previous_service_state} から {current_service_state} に変更されました。」

Edge ノードで、/var/log/core ディレクトリにあるコア ファイルをチェックし、エラーが原因でサービスが終了していないことを確認します。また、NSX CLI コマンドget services を呼び出し、サービスが停止しているかどうかを確認します。停止している場合は、start service &ltservice-name&gt を呼び出し、サービスを再起動します。

アプリケーションがクラッシュし、コア ダンプが生成されました。

イベントの検出時：「NSX ノード {node_display_or_host_name} のアプリケーションがクラッシュしました。見つかったコア ファイルの数は {core_dump_count} です。コア ダンプ ファイルを含むサポート バンドルを収集して、VMware サポート チームにお問い合わせください。」

イベントの解決時：「すべてのコア ダンプ ファイルがシステムから取り出されます。」

NSX Manager UI または API を使用して、NSX ノード {node_display_or_host_name} のサポート バンドルを収集します。ノードのローカル コピーを削除または保持するために、NSX テクニカル サポート バンドルに移動またはコピーするようにコア ダンプを設定できます。VMware サポート チームが問題のトラブルシューティングを行う上で、コア ダンプ ファイルを含むサポート バンドルのコピーは不可欠です。コア ダンプ ファイルを含むテクニカル サポート バンドルの最新のコピーを保存してから、システムからコア ダンプ ファイルを削除することを推奨します。詳細については、ナレッジベースの記事を参照してください。

トランスポート ノードは、Intelligence ノードのメッセージング ブローカから切断されています。データ収集が影響を受けます。

イベントの検出時：「トランスポート ノード {entity_id} のフロー エクスポータが Intelligence ノードのメッセージング ブローカから切断されています。データ収集が影響を受けます。」

イベントの解決時：「トランスポート ノード {entity_id} 上のフロー エクスポータが、Intelligence ノードのメッセージング ブローカに再接続しました。」

Intelligence ノードで実行されていない場合は、メッセージング サービスを再起動します。トランスポート ノードのフロー エクスポータと Intelligence ノード間のネットワーク接続の障害を解決します。

Intelligence ノードの CPU 使用率が非常に高くなっています。

イベントの検出時：「Intelligence ノード {intelligence_node_id} の CPU 使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「Intelligence ノード {intelligence_node_id} の CPU 使用率が {system_usage_threshold}% の超高しきい値を下回っています。」

top コマンドを使用して、CPU 使用率が最も高いプロセスを確認します。次に、/var/log/syslog とこれらのプロセスのローカル ログを確認して、未解決のエラーがないか確認します。

Intelligence ノードの CPU 使用率が高くなっています。

イベントの検出時：「Intelligence ノード {intelligence_node_id} の CPU 使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「Intelligence ノード {intelligence_node_id} の CPU 使用率が {system_usage_threshold}% の高しきい値を下回っています。」

top コマンドを使用して、CPU 使用率が最も高いプロセスを確認します。次に、/var/log/syslog とこれらのプロセスのローカル ログを確認して、未解決のエラーがないか確認します。

Intelligence ノードのメモリ使用率が非常に高くなっています。

イベントの検出時：「Intelligence ノード {intelligence_node_id} のメモリ使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「Intelligence ノード {intelligence_node_id} のメモリ使用率が {system_usage_threshold}% の超高しきい値を下回っています。」

top コマンドを使用して、メモリ使用率が最も高いプロセスを確認します。次に、/var/log/syslog とこれらのプロセスのローカル ログを確認して、未解決のエラーがないか確認します。

Intelligence ノードのメモリ使用率が高くなっています。

イベントの検出時：「Intelligence ノード {intelligence_node_id} のメモリ使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「Intelligence ノード {intelligence_node_id} のメモリ使用率が {system_usage_threshold}% の高しきい値を下回っています。」

top コマンドを使用して、メモリ使用率が最も高いプロセスを確認します。次に、/var/log/syslog とこれらのプロセスのローカル ログを確認して、未解決のエラーがないか確認します。

Intelligence ノードのディスク使用率が非常に高くなっています。

イベントの検出時：「Intelligence ノード {intelligence_node_id} で、ディスク パーティション {disk_partition_name} のディスク使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「Intelligence ノード {intelligence_node_id} で、ディスク パーティション {disk_partition_name} のディスク使用率が {system_usage_threshold}% の超高しきい値を下回っています。」

ディスク パーティション {disk_partition_name} を調べ、削除可能なサイズの大きいファイルがあるか確認します。

Intelligence ノードのディスク使用率が高くなっています。

イベントの検出時：「Intelligence ノード {intelligence_node_id} で、ディスク パーティション {disk_partition_name} のディスク使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「Intelligence ノード {intelligence_node_id} で、ディスク パーティション {disk_partition_name} のディスク使用率が {system_usage_threshold}% の高しきい値を下回りました。」

ディスク パーティション {disk_partition_name} を調べ、削除可能なサイズの大きいファイルがあるか確認します。

Intelligence ノードのデータ ディスク パーティションの使用率が非常に高くなっています。

イベントの検出時：「Intelligence ノード {intelligence_node_id} で、ディスク パーティション /data のディスク使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「Intelligence ノード {intelligence_node_id} で、ディスク パーティション/data のディスク使用率が {system_usage_threshold}% の超高しきい値を下回っています。」

ディスク使用率がしきい値を下回るまで NSX Intelligence のデータ収集を停止します。NSX ユーザー インターフェイスで、[システム] > [アプライアンス] > [NSX Intelligence アプライアンス] の順に移動します。次に、[アクション]、[データ収集の停止] の順にクリックします。

Intelligence ノードのデータ ディスク パーティションの使用率が高くなっています。

イベントの検出時：「Intelligence ノード {intelligence_node_id} で、ディスク パーティション /data のディスク使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「Intelligence ノード {intelligence_node_id} で、ディスク パーティション/data のディスク使用率が {system_usage_threshold}% の高しきい値を下回っています。」

ディスク使用率がしきい値を下回るまで NSX Intelligence のデータ収集を停止します。ディスク パーティション /data を調べ、削除可能なサイズの大きいファイルがあるか確認します。

Intelligence ノードのストレージ遅延が大きくなっています。

イベントの検出時：「Intelligence ノード {intelligence_node_id} で、ディスク パーティション {disk_partition_name} のストレージ遅延が {system_usage_threshold} ミリ秒の高しきい値を超えています。」

イベントの解決時：「Intelligence ノード {intelligence_node_id} で、ディスク パーティション {disk_partition_name} のストレージ遅延が {system_usage_threshold} ミリ秒の高しきい値を下回りました。」

I/O 要求の急増でストレージ遅延が一時的に高くなる可能性があります。ストレージの遅延が 30 分以上続く場合は、低遅延ディスクに NSX Intelligence アプライアンスを展開するか、他の仮想マシンと同じストレージ デバイスを共有しないようにする必要があります。

Intelligence ノードの状態が「劣化」になっています。

イベントの検出時：「Intelligence ノード {intelligence_node_id} の状態が「劣化」になっています。」

イベントの解決時：「Intelligence ノード {intelligence_node_id} は正常に実行されています。」

NSX API GET /napp/api/v1/platform/monitor/category/health を呼び出して、停止している特定のサービスとその理由を確認します。CLI コマンド kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt を呼び出して、劣化しているサービスを再起動します。

IP ブロックの使用率が非常に高くなっています。

イベントの検出時：「{intent_path} の IP ブロック使用率が非常に高くなっています。IP ブロックの合計容量に近づいています。IP ブロックを使用したサブネットの作成が失敗する可能性があります。」

イベントの解決時：「{intent_path} の IP ブロック使用率がしきい値レベルを下回っています。」

IP ブロックの使用状況を確認します。リソースの作成に新しい IP ブロックを使用するか、IP ブロックから未使用の IP サブネットを削除します。IP ブロックで使用されているサブネットを確認するには：NSX UI で [ネットワーク] | [IP アドレス プール] | [IP アドレス プール] タブの順に移動します。IP ブロックが使用されている IP プールを選択します。UI で [サブネット] と [割り当てられた IP] 列を確認します。IP プールで使用されている割り当てがなく、今後使用する予定がない場合は、サブネットまたは IP プールを削除します。次の API を使用して、IP ブロックが IP プールで使用中かどうか確認します。また、IP 割り当てが完了しているかどうかも確認します。IP プールの構成済みサブネットを取得するには、NSX API GET /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-subnets を呼び出します。IP 割り当てを取得するには、NSX API GET /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-allocations を呼び出します。注：IP プール/サブネットの削除は、割り当て済みの IP がなく、今後使用する予定がない場合にのみ行ってください。

IP プールの使用率が非常に高くなっています。

イベントの検出時：「{intent_path} の IP プール使用率が非常に高くなっています。IP プールの合計容量に近づいています。IP プールから割り振られた IP に依存するエンティティ/サービスの作成が失敗する可能性があります。」

イベントの解決時：「現在、{intent_path} の IP プール使用率は正常です。」

IP プールの使用状況を確認します。IP プールから未使用の IP 割り当てを解放するか、新しい IP プールを作成して使用します。NSX UI で [ネットワーク] | [IP アドレス プール] | [IP アドレス プール] タブの順に移動します。IP プールを選択して、[割り当てられた IP] 列を確認します。ここには、IP プールから割り当てられた IP が表示されます。未使用の IP がある場合は、それらの IP を解放できます。未使用の IP 割り当てを解放するには、NSX API DELETE /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-allocations/&ltip-allocation&gt を呼び出します。

ライセンスが期限切れです。

イベントの検出時：「{displayed_license_key} で終わる {license_edition_type} ライセンス キーが期限切れです。」

イベントの解決時：「{displayed_license_key} で終わる期限切れの {license_edition_type} ライセンス キーが削除されたか、有効期限の問題が解決されました。」

NSX UI で [システム] | [ライセンス] の順に移動して、期限切れでない新しいライセンスを追加します。[追加] をクリックして新しいライセンスのキーを指定します。期限切れのライセンスのチェックボックスをオンにして [削除] をクリックし、期限切れライセンスを削除します。

ライセンスがまもなく期限切れになります。

イベントの検出時：「{displayed_license_key} で終わる {license_edition_type} ライセンス キーがまもなく期限切れになります。」

イベントの解決時：「{displayed_license_key} で終わり、有効期限の近い {license_edition_type} ライセンス キーが削除されたか、有効期限の問題が解決されました。」

ライセンスがあと数日で期限切れになります。NSX UI で [システム] | [ライセンス] の順に移動して、有効期限が近くない新しいライセンスを追加します。[追加] をクリックして新しいライセンスのキーを指定します。期限切れのライセンスのチェックボックスをオンにして [削除] をクリックし、期限切れライセンスを削除します。

ロード バランサの CPU 使用率が非常に高くなっています。

イベントの検出時：「ロード バランサ {entity_id} の CPU 使用率が非常に高くなっています。しきい値は {system_usage_threshold}% です。」

イベントの解決時：「ロード バランサ {entity_id} の CPU 使用率が十分に低くなっています。しきい値は {system_usage_threshold}% です。」

ロード バランサの CPU 使用率がシステム使用率のしきい値を超えている場合、このロード バランサのワークロードが高すぎます。ロード バランサのサイズを small から medium または medium から large に変更して、ロードバランサ サービスのサイズを変更します。このロード バランサの CPU 使用率が高い場合は、ワークロードに合わせて Edge アプライアンスのフォーム ファクタのサイズを調整するか、ロード バランサ サービスを他の Edge ノードに移動することを検討してください。

ロード バランサ サービスが劣化しています。

イベントの検出時：「ロード バランサ サービス {entity_id} が劣化しています。」

イベントの解決時：「ロード バランサ サービス {entity_id} は劣化していません。」

中央集中型ロード バランサの場合：スタンバイ Edge ノードで、ロード バランサの状態を確認します。劣化状態の場合、スタンバイ Egde ノードのロード バランサの状態が ready ではありません。スタンバイ Egde ノードで、NSX CLI コマンド get load-balancer &ltlb-uuid&gt status を呼び出します。ロード バランサ サービスの LB-State が not_ready の場合、または何も出力されなかった場合は、Edge ノードをメンテナンス モードに切り替えて、メンテナンス モードを終了します。分散ロード バランサの場合：
1.NSX API GET /policy/api/v1/infra/lb-services/&ltLBService&gt/detailed-status?source=realtime を呼び出して、詳しい状態を確認します。
2.API の出力で、instance_number が 0 以外で、状態が NOT_READY または CONFLICT の ESXi ホストを探します。
3.ESXi ホスト ノードで、NSX CLI コマンド `get load-balancer &ltlb-uuid&gt status` を呼び出します。「Conflict LSP」が報告された場合は、この LSP が他のロード バランサ サービスに接続しているかどうか確認します。また、この競合が許容範囲内かどうかも確認します。「Not Ready LSP」が報告された場合は、NSX CLI コマンド get logical-switch-port status を呼び出して、この LSP の状態を確認します。注：劣化状態は一時的な状態です。5 分以内に自動的に解決される場合は、このアラームを無視してください。

分散ロード バランサ サービスが停止しています。

イベントの検出時：「分散ロード バランサ サービス {entity_id} が停止しています。」

イベントの解決時：「分散ロード バランサ サービス {entity_id} は稼動中です。」

ESXi ホスト ノードで、NSX CLI コマンド `get load-balancer &ltlb-uuid&gt status` を呼び出します。「Conflict LSP」が報告された場合は、この LSP が他のロード バランサ サービスに接続しているかどうか確認します。また、この競合が許容範囲内かどうかも確認します。「Not Ready LSP」が報告された場合は、NSX CLI コマンド get logical-switch-port status を呼び出して、この LSP の状態を確認します。

中央集中型ロード バランサ サービスが停止しています。

イベントの検出時：「中央集中型ロード バランサ サービス {entity_id} が停止しています。」

イベントの解決時：「中央集中型ロード バランサ サービス {entity_id} は稼動中です。」

アクティブな Edge ノードで、NSX CLI コマンド get load-balancer &ltlb-uuid&gt status を呼び出して、ロード バランサの状態を確認します。ロード バランサ サービスの LB-State が not_ready の場合、または何も出力されなかった場合は、Edge ノードをメンテナンス モードに切り替えて、メンテナンス モードを終了します。

ロード バランサの仮想サービスが停止しています。

イベントの検出時：「ロード バランサの仮想サーバ {entity_id} が停止しています。」

イベントの解決時：「ロード バランサの仮想サーバ {entity_id} が起動しています。」

ロード バランサ プールの状態と構成を確認します。正しく設定されていない場合は、再設定を行い、仮想サーバからロード バランサ プールを削除し、仮想サーバに再度追加します。

ロード バランサ プールが停止しています。

イベントの検出時：「ロード バランサ プール {entity_id} の状態が「停止」になっています。」

イベントの解決時：「ロード バランサ プール {entity_id} の状態が「起動中」になっています。

NSX CLI コマンド get load-balancer &ltlb-uuid&gt pool &ltpool-uuid&gt status または NSX API GET /policy/api/v1/infra/lb-services/&ltlb-service-id&gt/lb-pools/&ltlb-pool-id&gt/detailed-status を呼び出して、ロード バランサ プールで停止しているメンバーを確認します。「停止」または「不明」が返された場合は、プール メンバーを確認します。ロード バランサから問題のプール メンバーへのネットワーク接続を確認します。各プール メンバーのアプリケーションの健全性を確認します。また、構成済みのモニターを使用して、各プール メンバーの健全性を確認します。メンバーの健全性が確認されると、モニターの「起動カウント」構成に基づいて、プール メンバーの健全性の状態が更新されます。この問題を修正するには、プール メンバーを再起動するか、Edge ノードをメンテナンス モードに切り替えてメンテナンス モードを終了します。

ロード バランサの使用率が高くなっています。

イベントの検出時：「Edge ノード {entity_id} のロード バランサ サービスの使用率が高くなっています。しきい値は {system_usage_threshold}% です。」

イベントの解決時：「Edge ノード {entity_id} のロード バランサ サービスの使用率が十分に低くなっています。しきい値は {system_usage_threshold}% です。」

この Edge ノードに複数の LB インスタンスが構成されている場合は、新しい Edge ノードを展開して、一部の LB インスタンスをその新しい Edge ノードに移行します。同じサイズ（小規模/中規模など）の Edge ノードに単一の LB インスタンス（小規模/中規模など）のみが構成されている場合は、より大きなサイズの新しい Edge を展開し、LB インスタンスをその新しい Edge ノードに移動します。

ロード バランサのプール メンバーの使用率が非常に高くなっています。

イベントの検出時：「Edge ノード {entity_id} のプール メンバーの使用率が非常に高くなっています。しきい値は {system_usage_threshold}% です。」

イベントの解決時：「Edge ノード {entity_id} のプール メンバーの使用率が十分に低くなっています。しきい値は {system_usage_threshold}% です。」

新しい Edge ノードを展開し、ロード バランサ サービスを既存の Edge ノードから新たに展開した Edge ノードに移動します。

Edge ノードのメモリ使用率が高いため、ロード バランサの構成が認識されません。

イベントの検出時：「Edge ノード {transport_node_id} のメモリ使用率が高いため、ロード バランサの構成 {entity_id} が認識されません。」

イベントの解決時：「{transport_node_id} でロード バランサの構成 {entity_id} が認識されています。」

大規模なロード バランサよりも中小規模のロード バランサの定義を優先します。使用可能な Edge ノード間でロード バランサ サービスを分散します。定義されている仮想サーバの数を減らします。

サービスの状態が「停止」になっています。

イベントの検出時：「サービス {mps_service_name} は {transport_node_name} で実行されていません。」

イベントの解決時：「サービス {mps_service_name} は {transport_node_name} で正常に実行されています。」

1.{nsx_edge_tn_name} で識別される Edge ノードで、NSX CLI get services を呼び出し、{mps_service_name} の状態を確認します。/var/log/syslog を調べて、疑わしいエラーを検出します。
2.{nsx_esx_tn_name} で識別されるホスト ノードで、関連するマルウェア防止サービス仮想マシン {entity_id} にログインし、{mps_service_name} の状態を確認します。関連するマルウェア防止サービス仮想マシン {entity_id} の /var/log/syslog を調べて、疑わしいエラーを検出します。

サービスの状態が「劣化」になっています。

イベントの検出時：「{transport_node_name} でサービス {mps_service_name} が劣化しています。ファイル抽出機能と通信できません。{transport_node_name} 上のすべてのファイル抽出機能が一時停止しています。」

イベントの解決時：「サービス {mps_service_name} は {transport_node_name} で正常に実行されています。」

1.{nsx_edge_tn_name} で識別される Edge ノードで、NSX CLI get ids engine status を呼び出し、file_extraction (IDS) サービスの状態を確認します。/var/log/syslog を調べて、ファイル抽出 (IDS) サービスや {mps_service_name} で疑わしいエラーを検出します。
2.{nsx_esx_tn_name} で識別されるホスト ノードで、関連するマルウェア防止サービス仮想マシン {entity_id} にログインし、ファイル抽出 (NXGI) サービスの状態を確認します。関連するマルウェア防止サービス仮想マシン {entity_id} の /var/log/syslog を調べて、疑わしいエラーを検出します。

サービスの状態が「劣化」になっています。

イベントの検出時：「NSX Application Platform でサービス {mps_service_name} が劣化しています。マルウェア防止データベースと通信できません。」

イベントの解決時：「NSX Application Platform でサービス {mps_service_name} が正常に実行されています。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動して、劣化しているサービスを確認します。NSX API GET /napp/api/v1/platform/monitor/feature/health を呼び出して、停止している特定のサービスとその理由を確認します。CLI コマンド kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt を呼び出して、劣化しているサービスを再起動します。マルウェア防止の Database サービスの状態を判断します。

サービスの状態が「劣化」になっています。

イベントの検出時：「NSX Application Platform でサービス {mps_service_name} が劣化しています。analyst_api サービスと通信できません。検査されたファイルの判定は最新ではない可能性があります。」

イベントの解決時：「NSX Application Platform でサービス {mps_service_name} が正常に実行されています。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動して、劣化しているサービスを確認します。NSX API GET /napp/api/v1/platform/monitor/feature/health を呼び出して、停止している特定のサービスとその理由を確認します。CLI コマンド kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt を呼び出して、劣化しているサービスを再起動します。マルウェア防止の Cloud Connector サービスの状態を判断します。

サービスの状態が「劣化」になっています。

イベントの検出時：「NSX Application Platform でサービス {mps_service_name} が劣化しています。NTICS レピュテーション サービスと通信できません。検査されたファイルのレピュテーションは最新ではない可能性があります。」

イベントの解決時：「NSX Application Platform でサービス {mps_service_name} が正常に実行されています。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動して、劣化しているサービスを確認します。NSX API GET /napp/api/v1/platform/monitor/feature/health を呼び出して、停止している特定のサービスとその理由を確認します。CLI コマンド kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt を呼び出して、劣化しているサービスを再起動します。NTICS サービスへのアクセスが停止しているかどうかを判断します。

マネージャ ノードの CPU 使用率が非常に高くなっています。

イベントの検出時：「マネージャ ノード {entity_id} の CPU 使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値に達しているか、超えています。」

イベントの解決時：「マネージャ ノード {entity_id} の CPU 使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値を下回っています。」

このマネージャ ノードの構成、実行中のサービス、サイズを確認してください。Manager アプライアンスのフォーム ファクタのサイズを調整することを検討してください。

マネージャ ノードの CPU 使用率が高くなっています。

イベントの検出時：「マネージャ ノード {entity_id} の CPU 使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。」

イベントの解決時：「マネージャ ノード {entity_id} の CPU 使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値を下回っています。」

このマネージャ ノードの構成、実行中のサービス、サイズを確認してください。Manager アプライアンスのフォーム ファクタのサイズを調整することを検討してください。

マネージャ ノードのメモリ使用率が非常に高くなっています。

イベントの検出時：「マネージャ ノード {entity_id} のメモリ使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値に達しているか、超えています。」

イベントの解決時：「マネージャ ノード {entity_id} のメモリ使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値を下回っています。」

このマネージャ ノードの構成、実行中のサービス、サイズを確認してください。Manager アプライアンスのフォーム ファクタのサイズを調整することを検討してください。

マネージャ ノードのメモリ使用率が高くなっています。

イベントの検出時：「マネージャ ノード {entity_id} のメモリ使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。」

イベントの解決時：「マネージャ ノード {entity_id} のメモリ使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値を下回っています。」

このマネージャ ノードの構成、実行中のサービス、サイズを確認してください。Manager アプライアンスのフォーム ファクタのサイズを調整することを検討してください。

マネージャ ノードのディスクの使用率が非常に高くなっています。

イベントの検出時：「マネージャ ノードのディスク パーティション {disk_partition_name} のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値に達しているか、超えています。」

イベントの解決時：「マネージャ ノードのディスク パーティション {disk_partition_name} のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値を下回っています。」

使用率の高いパーティションを調べ、削除可能なサイズの大きいファイルがあるか確認します。

マネージャ ノードのディスク使用率が高くなっています。

イベントの検出時：「マネージャ ノードのディスク パーティション {disk_partition_name} のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。」

イベントの解決時：「マネージャ ノードのディスク パーティション {disk_partition_name} のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値を下回っています。」

使用率の高いパーティションを調べ、削除可能なサイズの大きいファイルがあるか確認します。

マネージャ ノードの config ディスクの使用率が非常に高くなっています。

イベントの検出時：「マネージャ ノードのディスク パーティション /config のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値に達しているか、超えています。/config/corfu ディレクトリで NSX Datastore サービスが大量のディスクを使用している可能性があります。」

イベントの解決時：「マネージャ ノードのディスク パーティション /config のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値を下回っています。」

/Opt/vmware/tools/support/inspect_checkpoint_issues.py ツールを実行して問題が報告された場合は、VMware のサポートにお問い合わせください。

マネージャ ノードの config ディスクの使用率が高くなっています。

イベントの検出時：「マネージャ ノードのディスク パーティション /config のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。/config/corfu ディレクトリで NSX Datastore サービスのディスク使用量が増加している可能性があります。」

イベントの解決時：「マネージャ ノードのディスク パーティション /config のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値を下回っています。」

/Opt/vmware/tools/support/inspect_checkpoint_issues.py ツールを実行して問題が報告された場合は、VMware のサポートにお問い合わせください。

マネージャ ノードの nonconfig ディスクの使用率が非常に高くなっています。

イベントの検出時：「マネージャ ノードのディスク パーティション /nonconfig のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値に達しているか、超えています。/nonconfig/corfu ディレクトリで NSX Datastore サービスが大量のディスクを使用している可能性があります。」

イベントの解決時：「マネージャ ノードのディスク パーティション /nonconfig のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の超高しきい値を下回っています。」

/opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig ツールを実行して問題が報告された場合は VMware のサポートにお問い合わせください

マネージャ ノードの nonconfig ディスクの使用率が高くなっています。

イベントの検出時：「マネージャ ノードのディスク パーティション /nonconfig のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値に達しているか、超えています。/nonconfig/corfu ディレクトリで NSX Datastore サービスのディスク使用量が増加している可能性があります。」

イベントの解決時：「マネージャ ノードのディスク パーティション /nonconfig のディスク使用率が {system_resource_usage}% に達しています。これは、{system_usage_threshold}% の高しきい値を下回っています。」

/opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig ツールを実行して問題が報告された場合は VMware のサポートにお問い合わせください

マネージャ ノードの IP アドレスが別のデバイスによって使用されています。

イベントの検出時：「マネージャ ノード {entity_id} の IP アドレス {duplicate_ip_address} は、ネットワーク内の別のデバイスで使用されています。」

イベントの解決時：「マネージャ ノード {entity_id} に割り当てられた IP アドレスを使用しているデバイスは、{duplicate_ip_address} を使用していません。」

1.マネージャの IP アドレスを使用しているデバイスを特定し、デバイスに新しい IP アドレスを割り当てます。注：新しい IP アドレスを使用するようにマネージャを再構成することはできません。
2.静的 IP アドレス プール/DHCP サーバが正しく構成されていることを確認します。
3.デバイスの IP アドレスが手動で割り当てられている場合は、その IP アドレスを修正します。

マネージャ ノードのディスクは読み取り専用です。

イベントの検出時：「マネージャ ノード {entity_id} の次のディスク パーティションは読み取り専用モードです：{disk_partition_name}」

イベントの解決時：「マネージャ ノード {entity_id} の次のディスク パーティションが読み取り専用モードからリカバリしました：{disk_partition_name}」

再起動で問題が解決されたかどうか読み取り専用パーティションを確認します。問題が解決していない場合は、ディスクの交換が必要になります。詳細については、VMware サポートにお問い合わせください。

マネージャの FQDN の DNS エントリがありません。

イベントの検出時：「マネージャ ノード {manager_node_name} ({entity_id}) の DNS 構成が正しくありません。マネージャ ノードはデュアル スタックまたは CA 署名付き API 証明書のいずれかまたは両方で使用されますが、マネージャ ノードの IP アドレスは FQDN に解決されないか、別の FQDN に解決されます。」

イベントの解決時：「マネージャ ノード {manager_node_name} ({entity_id}) の DNS 構成は正しい構成です。マネージャ ノードがデュアル スタックではなく、CA 署名付き API 証明書が使用されなくなったか、マネージャ ノードの IP アドレスが同じ FQDN に解決されたかのいずれかです。」

1.マネージャ ノードで適切な DNS サーバが構成されていることを確認します。
2.DNS サーバで適切な A レコードと PTR レコードが構成されていることを確認します。これにより、マネージャ ノードの IP アドレスの逆引き参照が同じ FQDN を返し、FQDN の正引き参照によってマネージャ ノードのすべての IP アドレスが返されるようにします。
3.または、マネージャ ノードがデュアル スタックでない場合は、API サービス タイプの CA 署名付き証明書を自己署名証明書に置き換えます。

マネージャの VIP の FQDN エントリがありません。

イベントの検出時：「NSX Manager のデュアル スタックまたは CA 署名付き API 証明書の場合、マネージャ ノード {ipv4_address} の仮想 IPv4 アドレス {ipv6_address} と仮想 IPv6 アドレス {entity_id} は同じ FQDN に解決される必要があります。」

イベントの解決時：「マネージャ ノード {entity_id} のデュアル スタック VIP アドレスが同じ FQDN に解決されました。」

VIP アドレスの DNS エントリを調べて、同じ FQDN に解決されるかどうかを確認します。

同じトランスポート ゾーンに接続しているトランスポート ノード間の MTU 構成が一致しません。

イベントの検出時：「同じトランスポート ゾーンに接続されているトランスポート ノード（ESXi、KVM、Edge）間で MTU 構成が一致していません。同じトランスポート ゾーンに接続されているすべてのスイッチの MTU 値が一貫していないと、接続の問題が発生します。」

イベントの解決時：「現在、同じトランスポート ゾーンに接続されているトランスポート ノード間のすべての MTU 値が一貫しています。」

1.NSX UI で [システム]、[ファブリック]、[設定]、[MTU 構成チェック]、[不一致] の順に移動して、不一致の詳細を確認します。
2.要求本文に MTU を指定して NSX API PUT /api/v1/host-switch-profiles/&lthost-switch-profile-id&gt を呼び出すか、要求本文に physical_uplink_mtu を指定して API PUT /api/v1/global-configs/SwitchingGlobalConfig を呼び出すことにより、同じトランスポート ゾーンに接続されたすべてのスイッチに同じ MTU 値を設定します。

グローバル ルーター MTU の構成が、オーバーレイ トランスポート ゾーンの MTU よりも大きくなっています。

イベントの検出時：「グローバル ルーターの MTU 構成が、Tier-0 または Tier-1 に接続するオーバーレイ トランスポート ゾーンのスイッチの MTU より大きくなっています。Geneve カプセル化には 100 の割り当てが必要なため、グローバル ルーターの MTU 値は、すべてのスイッチの MTU 値より少なくとも 100 小さくする必要があります。」

イベントの解決時：「現在、グローバル ルーターの MTU がオーバーレイ トランスポート ゾーンの MTU よりも小さくなっています。」

1.NSX UI で [システム]、[ファブリック]、[設定]、[MTU 構成チェック]、[不一致] の順に移動して、不一致の詳細を確認します。
2.要求本文に MTU を指定して NSX API PUT /api/v1/host-switch-profiles/&lthost-switch-profile-id&gt を呼び出すか、要求本文に physical_uplink_mtu を指定して API PUT /api/v1/global-configs/SwitchingGlobalConfig を呼び出すことにより、スイッチにより大きい MTU 値を設定します。
3.要求本文に logical_uplink_mtu を指定して NSX API PUT /api/v1/global-configs/RoutingGlobalConfig を呼び出すことにより、グローバル ルーター構成により小さい MTU 値を設定します。

ゲートウェイの SNAT ポートの使用率が高くなっています。

イベントの検出時：「SNAT IP {snat_ip_address} で論理ルーター {entity_id} の SNAT ポートの使用率が {system_usage_threshold}% の高しきい値に達しました。使用率が上限に達すると、新しいフローは SNAT で変換されません。」

イベントの解決時：「SNAT IP {snat_ip_address} で論理ルーター {entity_id} の SNAT ポートの使用率が {system_usage_threshold}% の高しきい値を下回りました。」

Edge ノードに admin ユーザーとしてログインし、適切なインターフェイス UUID を使用して NSX CLI コマンド get firewall &ltLR_INT_UUID&gt connection state を呼び出し、SNAT IP {snat_ip_address} の SNAT マッピングを確認します。ゲートウェイを通過するトラフィック フローが DoS 攻撃またはアノマリ バーストではないことを確認します。トラフィックが通常の負荷の範囲内に見えても、アラームしきい値に到達した場合は、SNAT IP アドレスを追加して負荷を分散するか、新しいトラフィックを別の Edge ノードにルーティングすることを検討します。

マネージャ ノードで NCP がダウンしているか、不良な状態になっています。

イベントの検出時：「マネージャ ノードで NCP がダウンしているか、不良な状態になっています。」

イベントの解決時：「マネージャ ノードで NCP が起動しているか、再び良好な状態になっています。」

問題のあるクラスタを見つけるには、NSX UI で [アラーム] 画面に移動します。このアラーム インスタンスのエンティティ名がクラスタ名です。または、NSX API GET /api/v1/systemhealth/container-cluster/ncp/status を呼び出し、すべてのクラスタの状態を取得して、「停止」または「不明」状態を報告するクラスタの名前を確認します。NSX UI で、[インベントリ] | [コンテナ] | [クラスタ] 画面の順に移動して、クラスタを名前で確認し、[ノード] タブをクリックします。ここに、すべての Kubernetes クラスタと PAS クラスタのメンバーが表示されます。Kubernetes クラスタの場合：
1.NCP Pod の稼動状態を確認します。クラスタ メンバーから K8s マスター ノードを探してそのノードにログインします。次に、kubectl コマンド kubectl get pods --all-namespaces を呼び出します。NCP ポッドに問題がある場合は、kubectl logs コマンドを実行して問題を確認し、エラーを修正してください。
2.NCP と Kubernetes API サーバの接続を確認します。NCP ポッド内で NSX CLI を使用してこの接続状態を確認できます。確認するには、マスター仮想マシンからコマンド kubectl exec -it &ltNCP-Pod-Name&gt -n nsx-system bash、nsxcli、get ncp-k8s-api-server status を実行します。接続に問題がある場合は、ネットワークと NCP 構成の両方を確認してください。
3.NCP と NSX Manager の接続を確認します。NCP ポッド内で NSX CLI を使用してこの接続状態を確認できます。確認するには、マスター仮想マシンからコマンド kubectl exec -it &ltNCP-Pod-Name&gt -n nsx-system bash、nsxcli、get ncp-nsx status を実行します。接続に問題がある場合は、ネットワークと NCP 構成の両方を確認してください。PAS クラスタの場合：
1.仮想マシン間のネットワーク接続を確認して、ネットワークの問題を修正します。
2.ノードとサービスの両方の状態を確認して、クラッシュしたノードまたはサービスを修正します。ノードとサービスの状態を確認するには、bosh vms コマンドと bosh instances -p コマンドを呼び出します。

DPU でノード仮想マシン内で実行されているエージェントが停止している可能性があります。

イベントの検出時：「DPU {dpu_id} で、ノード仮想マシン内で実行されているエージェントが停止している可能性があります。」

イベントの解決時：「DPU {dpu_id} でノード仮想マシン内のエージェントが実行されています。」

1.DPU {dpu_id} に Vmk50 がない場合は、ナレッジベースの記事 https://kb.vmware.com/s/article/67432 を参照してください。
2.DPU {dpu_id} に Hyperbus 4094 がない場合は、DPU {dpu_id} で nsx-cfgagent を再起動するか、コンテナ ホスト仮想マシンを再起動すると役に立つ場合があります。
3.コンテナ ホストの VIF がブロックされている場合は、コントローラとの接続をチェックして、すべての構成が送信されていることを確認します。
4.DPU {dpu_id} で nsx-cfg-agent が停止した場合は、DPU {dpu_id} で nsx-cfgagent を再起動します。
5.node-agent パッケージがない場合は、コンテナ ホスト仮想マシンに node-agent パッケージが正常にインストールされているかどうかを確認します。
6.コンテナ ホスト仮想マシンの node-agent のインターフェイスが停止している場合は、コンテナ ホスト仮想マシン内の eth1 インターフェイスの状態を確認します。

ノード仮想マシン内で実行されているエージェントが停止している可能性があります。

イベントの検出時：「ノード仮想マシン内で実行されているエージェントが停止している可能性があります。」

イベントの解決時：「ノード仮想マシン内のエージェントが実行されています。」

ESX の場合：
1.Vmk50 が見つからない場合は、次のナレッジベースの記事 https://kb.vmware.com/s/article/67432 を参照してください。
2.Hyperbus 4094 が見つからない場合は、nsx-cfgagent を再起動するか、コンテナ ホスト仮想マシンを再起動すると、問題が解決する場合があります。
3.コンテナ ホストの VIF がブロックされている場合は、コントローラとの接続をチェックして、すべての構成が送信されていることを確認します。
4.nsx-cfg-agent が停止している場合は、nsx-cfgagent を起動します。KVM の場合：
1.Hyperbus ネームスペースが見つからない場合は、nsx-opsagent を再起動すると、問題が解決する場合があります。
2.Hyperbus ネームスペースに Hyperbus インターフェイスが見つからない場合は、nsx-opsagent を再起動すると、問題が解決する場合があります。
3.nsx-agent が停止している場合は、nsx-agent を再起動します。ESX と KVM の場合：
1.node-agent パッケージがない場合は、コンテナ ホスト仮想マシンに node-agent パッケージが正常にインストールされているかどうかを確認します。
2.コンテナ ホスト仮想マシンの node-agent のインターフェイスが停止している場合は、コンテナ ホスト仮想マシン内の eth1 インターフェイスの状態を確認します。

NSX Application Platform クラスタが NSX 管理クラスタから切断されました。

イベントの検出時：「NSX Application Platform クラスタ {napp_cluster_id} が NSX 管理クラスタから切断されました。」

イベントの解決時：「NSX Application Platform クラスタ {napp_cluster_id} が、NSX 管理クラスタに再接続しました。」

マネージャ クラスタ証明書、マネージャ ノード証明書、kafka 証明書、ingress 証明書が NSX Manager と NSX Application Platform クラスタの両方で一致するかどうかを確認します。これらの証明書の有効期限をチェックして、有効な証明書であることを確認してください。NSX Manager と NSX Application Platform クラスタ間のネットワーク接続を確認し、ネットワークの接続障害を解決してください。

メッセージング トピックの Raw フローでデータ処理が遅くなっています。

イベントの検出時：「メッセージング トピックの Raw フローの保留中メッセージの数が、保留中メッセージのしきい値 {napp_messaging_lag_threshold} を超えています。」

イベントの解決時：「メッセージング トピックの Raw フローの保留中メッセージの数が、保留中メッセージのしきい値 {napp_messaging_lag_threshold} を下回りました。」

ノードを追加し、NSX Application Platform クラスタをスケール アップします。分析サービスなど、特定のサービスがボトルネックになる可能性がある場合は、新しいノードを追加するときに、そのサービスをスケール アップします。

メッセージング トピックのオーバーフローでデータ処理が遅くなっています。

イベントの検出時：「メッセージング トピックのオーバー フローの保留中メッセージの数が、保留中メッセージのしきい値 {napp_messaging_lag_threshold} を超えています。」

イベントの解決時：「メッセージング トピックのオーバー フローの保留中メッセージの数が、保留中メッセージのしきい値 {napp_messaging_lag_threshold} を下回りました。」

ノードを追加し、NSX Application Platform クラスタをスケール アップします。分析サービスなど、特定のサービスがボトルネックになる可能性がある場合は、新しいノードを追加するときに、そのサービスをスケール アップします。

トランスポート ノードが NSX Application Platform クラスタのメッセージング ブローカから切断されています。データ収集が影響を受けます。

イベントの検出時：「トランスポート ノード {entity_id} のフロー エクスポータが NSX Application Platform クラスタのメッセージング ブローカから切断されています。データ収集が影響を受けます。」

イベントの解決時：「トランスポート ノード {entity_id} 上のフロー エクスポータが、NSX Application Platform クラスタのメッセージング ブローカに再接続しました。」

メッセージング サービスが NSX Application Platform クラスタで実行されていない場合は、再起動します。トランスポート ノードのフロー エクスポータと NSX Application Platform クラスタ間のネットワーク接続の障害を解決します。

トランスポート ノードは、Intelligence ノードのメッセージング ブローカから切断されています。DPU でデータ収集が影響を受けます。

イベントの検出時：「トランスポート ノード {entity_id} DPU {dpu_id} のフロー エクスポータが Intelligence ノードのメッセージング ブローカから切断されています。データ収集が影響を受けます。」

イベントの解決時：「トランスポート ノード {entity_id} DPU {dpu_id} 上のフロー エクスポータが、Intelligence ノードのメッセージング ブローカに再接続しました。」

Intelligence ノードで実行されていない場合は、メッセージング サービスを再起動します。トランスポート ノードのフロー エクスポータと Intelligence ノード間のネットワーク接続の障害を解決します。

NSX Application Platform クラスタの CPU 使用率が非常に高くなっています。

イベントの検出時：「NSX Application Platform クラスタ {napp_cluster_id} の CPU 使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「NSX Application Platform クラスタ {napp_cluster_id} の CPU 使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動し、個々のサービスの [システム負荷] フィールドを確認して、負荷の高いサービスを特定します。その負荷を低減できるかどうか確認します。処理能力を増やす必要がある場合は、[スケール アウト] ボタンをクリックして、より多くのリソースを要求します。

NSX Application Platform クラスタの CPU 使用率が高くなっています。

イベントの検出時：「NSX Application Platform クラスタ {napp_cluster_id} の CPU 使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「NSX Application Platform クラスタ {napp_cluster_id} の CPU 使用率が {system_usage_threshold}% の高しきい値を下回りました。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動し、個々のサービスの [システム負荷] フィールドを確認して、負荷の高いサービスを特定します。その負荷を低減できるかどうか確認します。処理能力を増やす必要がある場合は、[スケール アウト] ボタンをクリックして、より多くのリソースを要求します。

NSX Application Platform クラスタのメモリ使用率が非常に高くなっています。

イベントの検出時：「NSX Application Platform クラスタ {napp_cluster_id} のメモリ使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「NSX Application Platform クラスタ {napp_cluster_id} のメモリ使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動し、個々のサービスの [メモリ] フィールドを確認して、負荷の高いサービスを特定します。その負荷を低減できるかどうか確認します。メモリを増やす必要がある場合は、[スケール アウト] ボタンをクリックして、より多くのリソースを要求します。

NSX Application Platform クラスタのメモリ使用率が高くなっています。

イベントの検出時：「NSX Application Platform クラスタ {napp_cluster_id} のメモリ使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「NSX Application Platform クラスタ {napp_cluster_id} のメモリ使用率が {system_usage_threshold}% の高しきい値を下回りました。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動し、個々のサービスの [メモリ] フィールドを確認して、負荷の高いサービスを特定します。その負荷を低減できるかどうか確認します。メモリを増やす必要がある場合は、[スケール アウト] ボタンをクリックして、より多くのリソースを要求します。

NSX Application Platform クラスタのディスク使用率が非常に高くなっています。

イベントの検出時：「NSX Application Platform クラスタ {napp_cluster_id} のディスク使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「NSX Application Platform クラスタ {napp_cluster_id} のディスク使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動し、個々のサービスの [ストレージ] フィールドを確認して、負荷の高いサービスを特定します。その負荷を低減できるかどうか確認します。ディスク ストレージを増やす必要がある場合は、[スケール アウト] ボタンをクリックして、より多くのリソースを要求します。データ ストレージ サービスの負荷が高い場合は、[スケール アップ] ボタンをクリックして、ディスク サイズを大きくする方法もあります。

NSX Application Platform クラスタのディスク使用率が高くなっています。

イベントの検出時：「NSX Application Platform クラスタ {napp_cluster_id} のディスク使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「NSX Application Platform クラスタ {napp_cluster_id} のディスク使用率が {system_usage_threshold}% の高しきい値を下回りました。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動し、個々のサービスの [ストレージ] フィールドを確認して、負荷の高いサービスを特定します。その負荷を低減できるかどうか確認します。ディスク ストレージを増やす必要がある場合は、[スケール アウト] ボタンをクリックして、より多くのリソースを要求します。データ ストレージ サービスの負荷が高い場合は、[スケール アップ] ボタンをクリックして、ディスク サイズを大きくする方法もあります。

NSX Application Platform クラスタ全体の状態が「劣化」になっています。

イベントの検出時：「NSX Application Platform クラスタ {napp_cluster_id} の全体の状態が「劣化」になっています。」

イベントの解決時：「NSX Application Platform クラスタ {napp_cluster_id} は正常に実行されています。」

ノードとサービスのアラームから詳細を取得します。

NSX Application Platform クラスタ全体の状態が「停止」になっています。

イベントの検出時：「NSX Application Platform クラスタ {napp_cluster_id} の全体の状態が「停止」になっています。」

イベントの解決時：「NSX Application Platform クラスタ {napp_cluster_id} は正常に実行されています。」

ノードとサービスのアラームから詳細を取得します。

NSX Application Platform ノードの CPU 使用率が非常に高くなっています。

イベントの検出時：「NSX Application Platform ノード {napp_node_name} の CPU 使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「NSX Application Platform ノード {napp_node_name} の CPU 使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動し、個々のサービスの [システム負荷] フィールドを確認して、負荷の高いサービスを特定します。その負荷を低減できるかどうか確認します。デフォルトでは、CPU 使用率が低いノード数が非常に少ない場合、Kubernetes はサービスのスケジュールを自動的に再設定します。ほとんどのノードで CPU 使用率が高く、負荷を低減できない場合は、[スケール アウト] ボタンをクリックして、より多くのリソースを要求します。

NSX Application Platform ノードの CPU 使用率が高くなっています。

イベントの検出時：「NSX Application Platform ノード {napp_node_name} の CPU 使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「NSX Application Platform ノード {napp_node_name} の CPU 使用率が {system_usage_threshold}% の高しきい値を下回りました。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動し、個々のサービスの [システム負荷] フィールドを確認して、負荷の高いサービスを特定します。その負荷を低減できるかどうか確認します。デフォルトでは、CPU 使用率が低いノード数が非常に少ない場合、Kubernetes はサービスのスケジュールを自動的に再設定します。ほとんどのノードで CPU 使用率が高く、負荷を低減できない場合は、[スケール アウト] ボタンをクリックして、より多くのリソースを要求します。

NSX Application Platform ノードのメモリ使用率が非常に高くなっています。

イベントの検出時：「NSX Application Platform ノード {napp_node_name} のメモリ使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「NSX Application Platform ノード {napp_node_name} のメモリ使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動し、個々のサービスの [メモリ] フィールドを確認して、負荷の高いサービスを特定します。その負荷を低減できるかどうか確認します。デフォルトでは、メモリ使用率が低いノード数が非常に少ない場合、Kubernetes はサービスのスケジュールを自動的に再設定します。ほとんどのノードでメモリ使用率が高く、負荷を低減できない場合は、[スケール アウト] ボタンをクリックして、より多くのリソースを要求します。

NSX Application Platform ノードのメモリ使用率が高くなっています。

イベントの検出時：「NSX Application Platform ノード {napp_node_name} のメモリ使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「NSX Application Platform ノード {napp_node_name} のメモリ使用率が {system_usage_threshold}% の高しきい値を下回りました。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動し、個々のサービスの [メモリ] フィールドを確認して、負荷の高いサービスを特定します。その負荷を低減できるかどうか確認します。デフォルトでは、メモリ使用率が低いノード数が非常に少ない場合、Kubernetes はサービスのスケジュールを自動的に再設定します。ほとんどのノードでメモリ使用率が高く、負荷を低減できない場合は、[スケール アウト] ボタンをクリックして、より多くのリソースを要求します。

NSX Application Platform ノードのディスク使用率が非常に高くなっています。

イベントの検出時：「NSX Application Platform ノード {napp_node_name} のディスク使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「NSX Application Platform ノード {napp_node_name} のディスク使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動し、個々のサービスの [ストレージ] フィールドを確認して、負荷の高いサービスを特定します。未使用のデータまたはログをクリーンアップしてディスク リソースを解放し、負荷を低減できるかどうか確認します。ディスク容量を増やす必要がある場合は、負荷の高いサービスをスケール アウトします。データ ストレージ サービスの負荷が高い場合は、[スケール アップ] ボタンをクリックして、ディスク サイズを大きくする方法もあります。

NSX Application Platform ノードのディスク使用率が高くなっています。

イベントの検出時：「NSX Application Platform ノード {napp_node_name} のディスク使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「NSX Application Platform ノード {napp_node_name} のディスク使用率が {system_usage_threshold}% の高しきい値を下回りました。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動し、個々のサービスの [ストレージ] フィールドを確認して、負荷の高いサービスを特定します。未使用のデータまたはログをクリーンアップしてディスク リソースを解放し、負荷を低減できるかどうか確認します。ディスク容量を増やす必要がある場合は、負荷の高いサービスをスケール アウトします。データ ストレージ サービスの負荷が高い場合は、[スケール アップ] ボタンをクリックして、ディスク サイズを大きくする方法もあります。

NSX Application Platform ノードの状態が「劣化」になっています。

イベントの検出時：「NSX Application Platform ノード {napp_node_name} が劣化しています。」

イベントの解決時：「NSX Application Platform ノード {napp_node_name} は正常に実行されています。」

NSX UI で、[システム] > [NSX Application Platform] > [リソース] の順に移動し、劣化しているノードを確認します。ノードのネットワーク、メモリ、CPU の使用率を確認します。ワーカー ノードの場合は、ノードを再起動します。

NSX Application Platform ノードの状態が「停止」になっています。

イベントの検出時：「NSX Application Platform ノード {napp_node_name} が実行されていません。」

イベントの解決時：「NSX Application Platform ノード {napp_node_name} は正常に実行されています。」

NSX UI で、[システム] > [NSX Application Platform] > [リソース] の順に移動し、停止しているノードを確認します。ノードのネットワーク、メモリ、CPU の使用率を確認します。ワーカー ノードの場合は、ノードを再起動します。

データ ストレージ サービスの CPU 使用率が非常に高くなっています。

イベントの検出時：「データ ストレージ サービスの CPU 使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「データ ストレージ サービスの CPU 使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

すべてのサービスまたはデータ ストレージ サービスをスケール アウトします。

データ ストレージ サービスの CPU 使用率が高くなっています。

イベントの検出時：「データ ストレージ サービスの CPU 使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「データ ストレージ サービスの CPU 使用率が {system_usage_threshold}% の高しきい値を下回りました。」

すべてのサービスまたはデータ ストレージ サービスをスケール アウトします。

メッセージング サービスの CPU 使用率が非常に高くなっています。

イベントの検出時：「メッセージング サービスの CPU 使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「メッセージング サービスの CPU 使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

すべてのサービスまたはメッセージング サービスをスケール アウトします。

メッセージング サービスの CPU 使用率が高くなっています。

イベントの検出時：「メッセージング サービスの CPU 使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「メッセージング サービスの CPU 使用率が {system_usage_threshold}% の高しきい値を下回りました。」

すべてのサービスまたはメッセージング サービスをスケール アウトします。

構成データベース サービスの CPU 使用率が非常に高くなっています。

イベントの検出時：「構成データベース サービスの CPU 使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「構成データベース サービスの CPU 使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

すべてのサービスをスケール アウトします。

構成データベース サービスの CPU 使用率が高くなっています。

イベントの検出時：「構成データベース サービスの CPU 使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「構成データベース サービスの CPU 使用率が {system_usage_threshold}% の高しきい値を下回りました。」

すべてのサービスをスケール アウトします。

メトリック サービスの CPU 使用率が非常に高くなっています。

イベントの検出時：「メトリック サービスの CPU 使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「メトリック サービスの CPU 使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

すべてのサービスをスケール アウトします。

メトリック サービスの CPU 使用率が高くなっています。

イベントの検出時：「メトリック サービスの CPU 使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「メトリック サービスの CPU 使用率が {system_usage_threshold}% の高しきい値を下回りました。」

すべてのサービスをスケール アウトします。

分析サービスの CPU 使用率が非常に高くなっています。

イベントの検出時：「分析サービスの CPU 使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「分析サービスの CPU 使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

すべてのサービスまたは分析サービスをスケール アウトします。

分析サービスの CPU 使用率が高くなっています。

イベントの検出時：「分析サービスの CPU 使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「分析サービスの CPU 使用率が {system_usage_threshold}% の高しきい値を下回りました。」

すべてのサービスまたは分析サービスをスケール アウトします。

Platform Services サービスの CPU 使用率が非常に高くなっています。

イベントの検出時：「Platform Services サービスの CPU 使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「Platform Services サービスの CPU 使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

すべてのサービスをスケール アウトします。

Platform Services サービスの CPU 使用率が高くなっています。

イベントの検出時：「Platform Services サービスの CPU 使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「Platform Services サービスの CPU 使用率が {system_usage_threshold}% の高しきい値を下回りました。」

すべてのサービスをスケール アウトします。

データ ストレージ サービスのメモリ使用率が非常に高くなっています。

イベントの検出時：「データ ストレージ サービスのメモリ使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「データ ストレージ サービスのメモリ使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

すべてのサービスまたはデータ ストレージ サービスをスケール アウトします。

データ ストレージ サービスのメモリ使用率が高くなっています。

イベントの検出時：「データ ストレージ サービスのメモリ使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「データ ストレージ サービスのメモリ使用率が {system_usage_threshold}% の高しきい値を下回りました。」

すべてのサービスまたはデータ ストレージ サービスをスケール アウトします。

メッセージング サービスのメモリ使用率が非常に高くなっています。

イベントの検出時：「メッセージング サービスのメモリ使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「メッセージング サービスのメモリ使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

すべてのサービスまたはメッセージング サービスをスケール アウトします。

メッセージング サービスのメモリ使用率が高くなっています。

イベントの検出時：「メッセージング サービスのメモリ使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「メッセージング サービスのメモリ使用率が {system_usage_threshold}% の高しきい値を下回りました。」

すべてのサービスまたはメッセージング サービスをスケール アウトします。

構成データベース サービスのメモリ使用率が非常に高くなっています。

イベントの検出時：「構成データベース サービスのメモリ使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「構成データベース サービスのメモリ使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

すべてのサービスをスケール アウトします。

構成データベース サービスのメモリ使用率が高くなっています。

イベントの検出時：「構成データベース サービスのメモリ使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「構成データベース サービスのメモリ使用率が {system_usage_threshold}% の高しきい値を下回りました。」

すべてのサービスをスケール アウトします。

メトリック サービスのメモリ使用率が非常に高くなっています。

イベントの検出時：「メトリック サービスのメモリ使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「メトリック サービスのメモリ使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

すべてのサービスをスケール アウトします。

メトリック サービスのメモリ使用率が高くなっています。

イベントの検出時：「メトリック サービスのメモリ使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「メトリック サービスのメモリ使用率が {system_usage_threshold}% の高しきい値を下回りました。」

すべてのサービスをスケール アウトします。

分析サービスのメモリ使用率が非常に高くなっています。

イベントの検出時：「分析サービスのメモリ使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「分析サービスのメモリ使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

すべてのサービスまたは分析サービスをスケール アウトします。

分析サービスのメモリ使用率が高くなっています。

イベントの検出時：「分析サービスのメモリ使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「分析サービスのメモリ使用率が {system_usage_threshold}% の高しきい値を下回りました。」

すべてのサービスまたは分析サービスをスケール アウトします。

Platform Services サービスのメモリ使用率が非常に高くなっています。

イベントの検出時：「Platform Services サービスのメモリ使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「Platform Services サービスのメモリ使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

すべてのサービスをスケール アウトします。

Platform Services サービスのメモリ使用率が高くなっています。

イベントの検出時：「Platform Services サービスのメモリ使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「Platform Services サービスのメモリ使用率が {system_usage_threshold}% の高しきい値を下回りました。」

すべてのサービスをスケール アウトします。

データ ストレージ サービスのディスク使用率が非常に高くなっています。

イベントの検出時：「データ ストレージ サービスのディスク使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「データ ストレージ サービスのディスク使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

データ ストレージ サービスをスケール アウトまたはスケール アップします。

データ ストレージ サービスのディスク使用率が高くなっています。

イベントの検出時：「データ ストレージ サービスのディスク使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「データ ストレージ サービスのディスク使用率が {system_usage_threshold}% の高しきい値を下回りました。」

データ ストレージ サービスをスケール アウトまたはスケール アップします。

メッセージング サービスのディスク使用率が非常に高くなっています。

イベントの検出時：「メッセージング サービスのディスク使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「メッセージング サービスのディスク使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

不要なファイルをクリーンアップします。すべてのサービスまたはメッセージング サービスをスケール アウトします。

メッセージング サービスのディスク使用率が高くなっています。

イベントの検出時：「メッセージング サービスのディスク使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「メッセージング サービスのディスク使用率が {system_usage_threshold}% の高しきい値を下回りました。」

不要なファイルをクリーンアップします。すべてのサービスまたはメッセージング サービスをスケール アウトします。

構成データベース サービスのディスク使用率が非常に高くなっています。

イベントの検出時：「構成データベース サービスのディスク使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「構成データベース サービスのディスク使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

不要なファイルをクリーンアップします。すべてのサービスをスケール アウトします。

構成データベース サービスのディスク使用率が高くなっています。

イベントの検出時：「構成データベース サービスのディスク使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「構成データベース サービスのディスク使用率が {system_usage_threshold}% の高しきい値を下回りました。」

不要なファイルをクリーンアップします。すべてのサービスをスケール アウトします。

メトリック サービスのディスク使用率が非常に高くなっています。

イベントの検出時：「メトリック サービスのディスク使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「メトリック サービスのディスク使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

不要なファイルをクリーンアップします。すべてのサービスをスケール アウトします。

メトリック サービスのディスク使用率が高くなっています。

イベントの検出時：「メトリック サービスのディスク使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「メトリック サービスのディスク使用率が {system_usage_threshold}% の高しきい値を下回りました。」

不要なファイルをクリーンアップします。すべてのサービスをスケール アウトします。

分析サービスのディスク使用率が非常に高くなっています。

イベントの検出時：「分析サービスのディスク使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「分析サービスのディスク使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

不要なファイルをクリーンアップします。すべてのサービスまたは分析サービスをスケール アウトします。

分析サービスのディスク使用率が高くなっています。

イベントの検出時：「分析サービスのディスク使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「分析サービスのディスク使用率が {system_usage_threshold}% の高しきい値を下回りました。」

不要なファイルをクリーンアップします。すべてのサービスまたは分析サービスをスケール アウトします。

Platform Services サービスのディスク使用率が非常に高くなっています。

イベントの検出時：「Platform Services サービスのディスク使用率が {system_usage_threshold}% の超高しきい値を超えています。」

イベントの解決時：「Platform Services サービスのディスク使用率が {system_usage_threshold}% の超高しきい値を下回りました。」

不要なファイルをクリーンアップします。すべてのサービスをスケール アウトします。

Platform Services サービスのディスク使用率が高くなっています。

イベントの検出時：「Platform Services サービスのディスク使用率が {system_usage_threshold}% の高しきい値を超えています。」

イベントの解決時：「Platform Services サービスのディスク使用率が {system_usage_threshold}% の高しきい値を下回りました。」

不要なファイルをクリーンアップします。すべてのサービスをスケール アウトします。

サービスの状態が「劣化」になっています。

イベントの検出時：「サービス {napp_service_name} が劣化しています。このサービスはまだクォーラムに到達する可能性がありますが、{napp_service_name} に関連付けられているポッドの一部が安定していません。これらの不安定なポッドが消費しているリソースが解放される可能性があります。」

イベントの解決時：「サービス {napp_service_name} は正常に実行されています。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動して、劣化しているサービスを確認します。NSX API GET /napp/api/v1/platform/monitor/feature/health を呼び出して、劣化している特定のサービスとその理由を確認します。必要であれば、CLI コマンド kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt を呼び出し、劣化しているサービスを再起動します。劣化しているサービスが正常に動作する場合もありますが、パフォーマンスは最適化されていません。

サービスの状態が「停止」になっています。

イベントの検出時：「サービス {napp_service_name} は実行されていません。」

イベントの解決時：「サービス {napp_service_name} は正常に実行されています。」

NSX UI で、[システム] > [NSX Application Platform] > [コア サービス] の順に移動して、劣化しているサービスを確認します。NSX API GET /napp/api/v1/platform/monitor/feature/health を呼び出して、停止している特定のサービスとその理由を確認します。CLI コマンド kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt を呼び出して、劣化しているサービスを再起動します。

サービスが劣化しました。

イベントの検出時：「サービス {nsxaas_service_name} が劣化しています。現在の状態では、サービスの効率が低下し、お客様のワークロードに影響を及ぼす可能性があります。{service_down_reason}」

イベントの解決時：「サービス {nsxaas_service_name} は劣化状態でなくなりました。」

サービスを識別するアラームの説明に含まれるデータ、サービスの展開場所、健全性モニタリング サービスによってキャプチャされた追加データを確認します。また、メトリック サービスまたは Wavefront によって記録された履歴データも必要に応じて確認します。

サービスが停止しました。

イベントの検出時：「サービス {nsxaas_service_name} が停止しています。{service_down_reason}」

イベントの解決時：「サービス {nsxaas_service_name} が再び使用可能になりました。」

サービスを識別するアラームの説明に含まれるデータ、サービスの展開場所、健全性モニタリング サービスによってキャプチャされた追加データを確認します。また、メトリック サービスまたは Wavefront によって記録された履歴データも必要に応じて確認します。

ユーザー パスワードが期限切れです。

イベントの検出時：「ユーザー {username} のパスワードは期限切れになっています。」

イベントの解決時：「ユーザー {username} のパスワードが正常に変更されたか、有効期限の問題が解決されています。あるいは、ユーザーがアクティブでない可能性もあります。」

システムにアクセスするには、ユーザー {username} のパスワードを今すぐ変更する必要があります。たとえば、ユーザーに新しいパスワードを適用するには、要求の本文に有効なパスワードを指定して次の NSX API を呼び出します。PUT /api/v1/node/users/&ltuserid&gt。&ltuserid&gt はユーザーの ID です。admin ユーザー（&ltuserid&gt が 10000）のパスワードが期限切れになっている場合は、管理者が SSH（有効な場合）またはコンソールからシステムにログインして、パスワードを変更する必要があります。期限切れのパスワードを入力すると、新しいパスワードを入力するように求められます。

ユーザー パスワードがまもなく期限切れになります。

イベントの検出時：「ユーザー {username} のパスワードはあと {password_expiration_days} 日で期限切れになります。」

イベントの解決時：「ユーザー {username} のパスワードが正常に変更されたか、有効期限の問題が解決されています。あるいは、ユーザーがアクティブでない可能性もあります。」

ユーザー {username} のパスワードをすぐに変更してください。たとえば、ユーザーに新しいパスワードを適用するには、要求の本文に有効なパスワードを指定して次の NSX API を呼び出します。PUT /api/v1/node/users/&ltuserid&gt。&ltuserid&gt はユーザーの ID です。

ユーザー パスワードの期限切れが近づいています。

イベントの検出時：ユーザー {username} のパスワードは、あと {password_expiration_days} 日で期限切れになります。」

イベントの解決時：「ユーザー {username} のパスワードが正常に変更されたか、有効期限の問題が解決されています。あるいは、ユーザーがアクティブでない可能性もあります。」

ユーザー {username} のパスワードはすぐに変更する必要があります。たとえば、ユーザーに新しいパスワードを適用するには、要求の本文に有効なパスワードを指定して次の NSX API を呼び出します。PUT /api/v1/node/users/&ltuserid&gt。&ltuserid&gt はユーザーの ID です。

物理サーバ (BMS) のインストールに失敗しました。

イベントの検出時：「物理サーバ {transport_node_name} ({entity_id}) のインストールに失敗しました。」

イベントの解決時：「物理サーバ {transport_node_name} ({entity_id}) のインストールが完了しました。」

[システム] > [ファブリック] > [ノード] > [ホスト トランスポート ノード] の順に移動して、ノードのエラーを解決します。

物理サーバ (BMS) のアップグレードに失敗しました。

イベントの検出時：「物理サーバ {transport_node_name} ({entity_id}) のアップグレードに失敗しました。」

イベントの解決時：「物理サーバ {transport_node_name} ({entity_id}) のアップグレードが完了しました。」

[システム] > [アップグレード] の順に移動してエラーを解決し、アップグレードを再度トリガします。

物理サーバ (BMS) のアンインストールに失敗しました。

イベントの検出時：「物理サーバ {transport_node_name} ({entity_id}) のアンインストールに失敗しました。」

イベントの解決時：「物理サーバ {transport_node_name} ({entity_id}) のアンインストールが完了しました。」

[システム] > [ファブリック] > [ノード] > [ホスト トランスポート ノード] の順に移動して、ノードのエラーを解決します。

エンティティ数がポリシー制約の上限に達しました。

イベントの検出時：「現在、{constraint_type_path} のタイプ {constraint_type} のエンティティ数は {current_count} です。これは上限の {constraint_limit} に達しています。」

イベントの解決時：「{constraint_type} の数がしきい値を下回っています。」

{constraint_type} の使用量を確認します。制約を更新して制限を増やすか、未使用の {constraint_type} を削除します。

BFD セッションが停止しています。

イベントの検出時：「ルーター {lr_id} で、ピア {peer_address} の BFD セッションが停止しています。」

イベントの解決時：「ルーター {lr_id} で、ピア {peer_address} の BFD セッションが起動しています。」

1.NSX CLI コマンド get logical-routers を呼び出します。
2.サービス ルーター {sr_id} に切り替えます。
3.NSX CLI コマンド ping {peer_address} を呼び出して、接続を確認します。

スタティック ルートが削除されました。

イベントの検出時：「ルーター {lr_id} で BFD が停止しているため、スタティック ルート {entity_id} ({static_address}) が削除されました。」

イベントの解決時：「BFD がリカバリされたため、ルーター {lr_id} でスタティック ルート {entity_id} ({static_address}) が再度追加されました。」

BFD セッションが停止しているため、スタティック ルーティングのエントリが削除されています。
1.NSX CLI コマンド get logical-routers を呼び出します。
2.サービス ルーター {sr_id} に切り替えます。
3.NSX CLI コマンド ping &ltBFD peer IP address&gt を呼び出して接続を確認します。また、NSX と BFD ピアの両方の構成を調べて、タイマーが変更されていないことを確認します。

BGP ネイバーが停止しています。

イベントの検出時：「ルーター {lr_id} で、BGP ネイバー {entity_id} ({bgp_neighbor_ip}) が停止しています。原因: {failure_reason}。」

イベントの解決時：「ルーター {lr_id} で、BGP ネイバー {entity_id} ({bgp_neighbor_ip}) が稼動中です。」

1.NSX CLI コマンド get logical-routers を呼び出します。
2.サービス ルーター {sr_id} に切り替えます。理由がネットワークまたは構成エラーを示している場合 -
3.NSX CLI コマンド get bgp neighbor summary を呼び出し、BGP ネイバーの状態を確認します。理由が「Edge の準備ができていません」と示されている場合は、Edge ノードが良好な状態でない理由を確認します。
4.NSX CLI コマンド get edge-cluster status を呼び出して、Edge ノードが停止している理由を確認します。
5.NSX CLI コマンド get bfd-config と get bfd-sessions を呼び出し、BFD が正常に実行されているかどうかを確認します。
6.Edge の健全性に関連するアラームをチェックして、詳細を確認します。/var/log/syslog で、BGP 接続関連のエラーが報告されているかどうか確認します。

サービス IP にプロキシ ARP が構成されていません。

イベントの検出時：「ルーター {lr_id} の lrPort {lrport_id} のサブネットを持つサービス IP の重複で生成された ARP プロキシのエントリ数が許容しきい値の上限 (16384) を超えているため、サービス IP {service_ip} とサービス エンティティ {entity_id} のプロキシ ARP が構成されていません。」

イベントの解決時：「ルーター {lr_id} の lrPort {lrport_id} のサブネットを持つサービス IP の重複で生成されたエントリ数が許容しきい値の上限 (16384) 内のため、サービス エンティティ {entity_id} のプロキシ ARP が正常に生成されました。」

サービス IP と lrport サブネット間の重複で生成されるプロキシ ARP エントリの数が許容しきい値の上限 (16384) を下回るように、サービス エンティティ {entity_id} のサービス IP {service_ip} を再構成するか、ルーター {lr_id} の lrport {lrport_id} のサブネットを変更します。

すべての BGP/BFD セッションが停止しています。

イベントの検出時：「すべての BGP/BFD セッションが停止しています。」

イベントの解決時：「1 つ以上の BGP/BFD セッションが起動しています。」

NSX CLI コマンド get logical-routers を呼び出して Tier-0 サービス ルーターを取得します。この VRF に切り替えて、次の NSX CLI コマンドを呼び出します。
1. ping &ltBFD peer IP address&gt を実行して、接続を確認します。
2. get bfd-config と get bfd-sessions を実行して、BFD が正常に稼動していることを確認します。
3. get bgp neighbor summary を実行して、BGP が正常に稼動しているかどうか確認します。また、/var/log/syslog を参照して、BGP 接続関連のエラーが発生しているかどうか確認します。

OSPF ネイバーが「完全」から別の状態に移行しました。

イベントの検出時：「OSPF ネイバー {peer_address} が「完全」から別の状態に移行しました。」

イベントの解決時：「OSPF ネイバー {peer_address} が「完全」の状態に移行しました。」

1.NSX CLI コマンド get logical-routers を呼び出して、vrf ID を取得し、Tier-0 サービス ルーターに切り替えます。
2.get ospf neighbor を実行して、このネイバーの現在の状態を確認します。ネイバーが出力にリストされていない場合は、ネイバーが停止しているか、ネットワークから切断されています。
3.NSX CLI コマンド ping &ltOSPF neighbor IP address&gt を呼び出して接続を確認します。
4.また、NSX とピア ルーターの両方の構成を検証して、タイマーとエリア ID が一致することを確認します。
5./var/log/syslog で、接続関連のエラーが報告されているかどうか確認します。

Edge ノードで IPv4 ルート数の上限に近づいています。

イベントの検出時：「Edge ノード {edge_node} のすべての Tier-0 ゲートウェイと Tier-0 VRF で、IPv4 ルートの制限が {route_limit_threshold} に達しています。」

イベントの解決時：「IPv4 ルートは、Edge ノード {edge_node} 上のすべての Tier-0 ゲートウェイと Tier-0 VRF で {route_limit_threshold} の制限内にあります。」

1.すべての外部ピアから受信したルート再配分ポリシーとルートを確認します。
2.ルーティング ポリシーとフィルタを適切に適用して、ルートの数を減らすことを検討します。

Edge ノードで IPv6 ルート数が上限に近づいています。

イベントの検出時：「Edge ノード {edge_node} のすべての Tier-0 ゲートウェイと Tier-0 VRF で、IPv6 ルートの制限が {route_limit_threshold} に達しています。」

イベントの解決時：「IPv6 ルートは、Edge ノード {edge_node} 上のすべての Tier-0 ゲートウェイと Tier-0 VRF で {route_limit_threshold} の制限内にあります。」

1.すべての外部ピアから受信したルート再配分ポリシーとルートを確認します。
2.ルーティング ポリシーとフィルタを適切に適用して、ルートの数を減らすことを検討します。

Edge ノードで IPv4 ルート数の上限を超えています。

イベントの検出時：「Edge ノード {edge_node} のすべての Tier-0 ゲートウェイと Tier-0 VRF で、IPv4 ルートが {route_limit_maximum} の上限を超えています。」

イベントの解決時：「IPv4 ルートは、Edge ノード {edge_node} 上のすべての Tier-0 ゲートウェイと Tier-0 VRF で {route_limit_maximum} の制限内にあります。」

1.すべての外部ピアから受信したルート再配分ポリシーとルートを確認します。
2.ルーティング ポリシーとフィルタを適切に適用して、ルートの数を減らすことを検討します。

Edge ノードで IPv6 ルート数の上限を超えています。

イベントの検出時：「Edge ノード {edge_node} のすべての Tier-0 ゲートウェイと Tier-0 VRF で、IPv6 ルートが {route_limit_maximum} の上限を超えています。」

イベントの解決時：「IPv6 ルートは、Edge ノード {edge_node} 上のすべての Tier-0 ゲートウェイと Tier-0 VRF で {route_limit_maximum} の制限内にあります。」

1.すべての外部ピアから受信したルート再配分ポリシーとルートを確認します。
2.ルーティング ポリシーとフィルタを適切に適用して、ルートの数を減らすことを検討します。

BGP ネイバーから受信される IPv4 プレフィックス数が最大数に近づいています。

イベントの検出時：「{bgp_neighbor_ip} から受信した IPv4 {subsequent_address_family} プレフィックスの数が {prefixes_count_threshold} に達します。このピアに定義されている上限は {prefixes_count_max} です。」

イベントの解決時：「{bgp_neighbor_ip} から受信した IPv4 {subsequent_address_family} プレフィックスの数は制限 {prefixes_count_threshold} 内です。」

1.外部ルーターの BGP ルーティング ポリシーを確認します。
2.ルーティング ポリシーとフィルタを外部ルーターに適用して、BGP ピアによってアドバタイズされるルートの数を減らすことを検討します。
3.必要に応じて、[BGP ネイバーの構成] セクションで最大プレフィックスの設定値を大きくします。

BGP ネイバーから受信される IPv6 プレフィックス数が最大数に近づいています。

イベントの検出時：「{bgp_neighbor_ip} から受信した IPv6 {subsequent_address_family} プレフィックスの数が {prefixes_count_threshold} に達します。このピアに定義されている上限は {prefixes_count_max} です。」

イベントの解決時：「{bgp_neighbor_ip} から受信した IPv6 {subsequent_address_family} プレフィックスの数は制限 {prefixes_count_threshold} 内です。」

1.外部ルーターの BGP ルーティング ポリシーを確認します。
2.ルーティング ポリシーとフィルタを外部ルーターに適用して、BGP ピアによってアドバタイズされるルートの数を減らすことを検討します。
3.必要に応じて、[BGP ネイバーの構成] セクションで最大プレフィックスの設定値を大きくします。

BGP ネイバーから受信される IPv4 プレフィックス数が最大数を超えています。

イベントの検出時：「{bgp_neighbor_ip} から受信した IPv4 {subsequent_address_family} プレフィックスの数が、このピアに定義されている上限 {prefixes_count_max} を超えました。」

イベントの解決時：「{bgp_neighbor_ip} から受信した IPv4 {subsequent_address_family} プレフィックスの数は制限 {prefixes_count_max} 内です。」

1.外部ルーターの BGP ルーティング ポリシーを確認します。
2.ルーティング ポリシーとフィルタを外部ルーターに適用して、BGP ピアによってアドバタイズされるルートの数を減らすことを検討します。
3.必要に応じて、[BGP ネイバーの構成] セクションで最大プレフィックスの設定値を大きくします。

BGP ネイバーから受信される IPv6 プレフィックス数が最大数を超えました。

イベントの検出時：「{bgp_neighbor_ip} から受信した IPv6 {subsequent_address_family} プレフィックスの数が、このピアに定義されている上限 {prefixes_count_max} を超えました。」

イベントの解決時：「{bgp_neighbor_ip} から受信した IPv6 {subsequent_address_family} プレフィックスの数は制限 {prefixes_count_max} 内です。」

1.外部ルーターの BGP ルーティング ポリシーを確認します。
2.ルーティング ポリシーとフィルタを外部ルーターに適用して、BGP ピアによってアドバタイズされるルートの数を減らすことを検討します。
3.必要に応じて、[BGP ネイバーの構成] セクションで最大プレフィックスの設定値を大きくします。

NSX セキュリティ状態が NDcPP を遵守していません。

イベントの検出時：「NDcPP コンプライアンス要件の 1 つに違反しています。これは、NSX の状態が現在 NDcPP を遵守していないことを意味します。」

イベントの解決時：「NDcPP コンプライアンスの問題はすべて解決されました。」

ユーザー インターフェイスの [ホーム] > [モニタリング ダッシュボード] > [コンプライアンス レポート] メニューからコンプライアンス レポートを実行して、NDcPP コンプライアンス名でマークされているすべての問題を解決します。

NSX セキュリティ状態が EAL4+ を遵守していません。

イベントの検出時：「EAL4+ コンプライアンス要件の 1 つに違反しています。これは、NSX の状態が現在 EAL4+ を遵守していないことを意味します。」

イベントの解決時：「EAL4+ コンプライアンスの問題はすべて解決されました。」

ユーザー インターフェイスの [ホーム] > [モニタリング ダッシュボード] > [コンプライアンス レポート] メニューからコンプライアンス レポートを実行して、EAL4+ コンプライアンス名でマークされているすべての問題を解決します。

NSX セキュリティ構成が NDcPP を遵守していません。

イベントの検出時：「NDcPP コンプライアンス要件の 1 つに違反しています。これは、NSX 構成が現在 NDcPP を遵守していないことを意味します。」

イベントの解決時：「NDcPP コンプライアンスの問題はすべて解決されました。」

ユーザー インターフェイスの [ホーム] > [モニタリング ダッシュボード] > [コンプライアンス レポート] メニューからコンプライアンス レポートを実行して、NDcPP コンプライアンス名でマークされているすべての問題を解決します。

NSX セキュリティ構成が EAL4+ を遵守していません。

イベントの検出時：「EAL4+ コンプライアンス要件の 1 つに違反しています。これは、NSX 構成が現在 EAL4+ を遵守していないことを意味します。」

イベントの解決時：「EAL4+ コンプライアンスの問題はすべて解決されました。」

ユーザー インターフェイスの [ホーム] > [モニタリング ダッシュボード] > [コンプライアンス レポート] メニューからコンプライアンス レポートを実行して、EAL4+ コンプライアンス名でマークされているすべての問題を解決します。

サービスの展開に成功しました。

イベントの検出時：「クラスタ {vcenter_cluster_id} のサービス {service_name} のサービス展開 {entity_id} が成功しました。」

イベントの解決時：「クラスタ {vcenter_cluster_id} でサービス展開 {entity_id} は成功しました。必要な操作はありません。」

必要な操作はありません。

サービス展開に失敗しました。

イベントの検出時：「クラスタ {vcenter_cluster_id} のサービス {service_name} のサービス展開 {entity_id} に失敗しました。理由：{failure_reason}」

イベントの解決時：「失敗したサービス展開 {entity_id} が削除されました。」

NSX ユーザー インターフェイスまたは API を使用して、サービス展開を削除します。ナレッジ ベースから修正措置を実行し、サービス展開を再試行します。

サービス展開の削除に成功しました。

イベントの検出時：「クラスタ {vcenter_cluster_id} のサービス {service_name} のサービス展開 {entity_id} の削除が成功しました。」

イベントの解決時：「クラスタ {vcenter_cluster_id} でサービス展開 {entity_id} の削除に成功しました。必要な操作はありません。」

必要な操作はありません。

サービス展開の削除に失敗しました。

イベントの検出時：クラスタ {vcenter_cluster_id} のサービス {service_name} のサービス展開 {entity_id} の削除に失敗しました。理由：{failure_reason}」

イベントの解決時：「失敗したサービス展開名 {entity_id} が削除されました。」

NSX ユーザー インターフェイスまたは API を使用して、サービス展開を削除します。ナレッジベースに記述の修正措置を行い、サービス展開の削除を再試行します。すべての仮想マシンとオブジェクトが削除されていることを確認した後、アラームを手動で解決してください。

サービスでサービス仮想マシンは正常に機能しています。

イベントの検出時：「サービス {service_name} のサービス仮想マシン {entity_id} の健全性チェックが {hostname_or_ip_address_with_port} で正常に機能しています。」

イベントの解決時：「サービス仮想マシン {entity_id} は正常に動作しています。必要な操作はありません。」

必要な操作はありません。

サービスでサービス仮想マシンが機能していません。

イベントの検出時：「サービス {service_name} のサービス仮想マシン {entity_id} の健全性チェックが {hostname_or_ip_address_with_port} で正常に機能していません。理由：{failure_reason}。」

イベントの解決時：「状態が正しくないサービス仮想マシン {entity_id} が削除されました。」

NSX ユーザー インターフェイスまたは API を使用して、サービス展開を削除します。ナレッジベースから修正措置を実行し、必要に応じてサービス展開を再試行します。

サービス挿入インフラストラクチャが停止状態で、ホストで有効になっていません。

イベントの検出時：「ホスト {transport_node_id} のポート レベルで SPF が有効になっていないため、「停止」状態になっています。理由：{failure_reason}。」

イベントの解決時：「サービス挿入インフラストラクチャの状態が「稼動中」で、ホストで有効になっています。」

ナレッジベースに記述の修正措置を行い、状態が「稼動中」かどうかを確認します。状態を確認した後、アラームを手動で解決します。

サービス仮想マシンの稼動状態が「停止」になっています。

イベントの検出時：「{entity_id} でサービス仮想マシンの稼動状態が「停止」になり、トラフィック フローが影響を受けています。」

イベントの解決時：「サービス仮想マシンの稼動状態が「稼動中」で、想定どおりに構成されています。」

ナレッジベースに記述の修正措置を行い、状態が「稼動中」かどうかを確認します。

サービス チェーン パスが停止しています。

イベントの検出時：「サービス チェーンのパスが {entity_id} で停止し、トラフィック フローが影響を受けています。」

イベントの解決時：「サービス チェーン パスは稼動中で、想定どおりに構成されています。」

ナレッジベースに記述の修正措置を行い、状態が「稼動中」かどうかを確認します。

クラスタに新しいホストが追加されました。

イベントの検出時：「クラスタ {vcenter_cluster_id} に新しいホストが追加され、サービス仮想マシンが展開されます。」

イベントの解決時：「新しいホストが正常に追加されました。」

仮想マシンの展開状態を確認し、パワーオンするまで待機します。

TEP が不良です。

イベントの検出時：「トランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name}。この TEP を使用するオーバーレイ ワークロードでは、ネットワークが停止します。原因: {vtep_fault_reason}。」

イベントの解決時：「トランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name} は良好です。」

1.TEP に有効な IP アドレスがあるか、またはその他のアンダーレイ接続の問題があるかを確認します。
2.TEP HA を有効にして、ワークロードを他の健全な TEP にフェイルオーバーします。

TEP HA が有効化されました。

イベントの検出時：「トランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TE：{vtep_name} に対して TEP HA が有効になりました。」

イベントの解決時：「トランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name} の TEP HA がクリアされました。」

「トランスポート ノード：{transport_node_id} の VDS：{dvs_name} で、TEP：{vtep_name} の自動リカバリを有効にするか、手動リカバリを呼び出します。

自動リカバリに成功しました。

イベントの検出時：「トランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name} の自動リカバリに成功しました。」

イベントの解決時：「トランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name} の自動リカバリはクリアされます。」

なし。

自動リカバリに失敗しました。

イベントの検出時：「トランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name} の自動リカバリに失敗しました。この TEP を使用するオーバーレイ ワークロードは、他の健全な TEP にフェイルオーバーします。他に健全な TEP がない場合、オーバーレイ ワークロードでは、ネットワークが停止します。」

イベントの解決時：「トランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name} の自動リカバリはクリアされます。」

TEP に有効な IP アドレスがあるか、またはその他のアンダーレイ接続の問題があるかを確認します。

DPU 上の TEP が不良です。

イベントの検出時：「DPU {dpu_id} 上のトランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name}。この TEP を使用するオーバーレイ ワークロードでは、ネットワークが停止します。原因: {vtep_fault_reason}。」

イベントの解決時：「DPU {dpu_id} 上のトランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name} は良好です。」

1.TEP に有効な IP アドレスがあるか、またはその他のアンダーレイ接続の問題があるかを確認します。
2.TEP HA を有効にして、ワークロードを他の健全な TEP にフェイルオーバーします。

DPU 上で TEP HA が有効化されました。

イベントの検出時：「DPU {dpu_id} 上のトランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name} に対して TEP HA が有効になりました。」

イベントの解決時：「DPU {dpu_id} 上のトランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name} の TEP HA がクリアされました。」

DPU {dpu_id} のトランスポート ノード：{transport_node_id} で、VDS：{dvs_name} の TEP：{vtep_name} の自動リカバリを有効にするか、手動リカバリを呼び出します。

DPU で自動リカバリに成功しました。

イベントの検出時：「DPU {dpu_id} 上のトランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name} の自動リカバリに成功しました。」

イベントの解決時：「DPU {dpu_id} 上のトランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name} の自動リカバリはクリアされます。」

なし。

DPU で自動リカバリに失敗しました。

イベントの検出時：「DPU {dpu_id} 上のトランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name} の自動リカバリに失敗しました。この TEP を使用するオーバーレイ ワークロードは、他の健全な TEP にフェイルオーバーします。他に健全な TEP がない場合、オーバーレイ ワークロードでは、ネットワークが停止します。」

イベントの解決時：「DPU {dpu_id} 上のトランスポート ノード：{transport_node_id} の VDS：{dvs_name} の TEP：{vtep_name} の自動リカバリはクリアされます。」

TEP に有効な IP アドレスがあるか、またはその他のアンダーレイ接続の問題があるかを確認します。

DPU でアップリンクが停止しています。

イベントの検出時：「DPU {dpu_id} でアップリンクが停止しています。」

イベントの解決時：「DPU {dpu_id} でアップリンクが起動しています。」

DPU {dpu_id} でホストのアップリンクの物理 NIC の状態を確認します。ホストで、この物理 NIC にマッピングしている名前を確認し、UI をチェックします。
1.NSX UI で、[ファブリック] | [ノード] | [トランスポート ノード] | [ホスト トランスポート ノード] の順に移動します。
2.[ホスト トランスポート ノード] リストで、[ノードの状態] 列を確認します。ノードの状態が劣化か停止のトランスポート ノードを特定します。
3.&ltトランスポート ノード&gt | [モニター] の順に選択します。劣化または停止が報告されているボンディング（アップリンク）の状態を確認します。劣化状態を回避するには、使用中かどうかにかかわらず、すべてのアップリンク インターフェイスが接続され、稼動状態になっている必要があります。

DPU で LACP レポーティング メンバーが停止しています。

イベントの検出時：「DPU {dpu_id} で LACP レポート メンバーが停止しています。」

イベントの解決時：「DPU {dpu_id} で LACP レポート メンバーが起動しています。」

DPU {dpu_id} で LAG メンバーの接続状態を確認します。ホスト上の関連する物理 NIC のマッピングされた名前を確認し、UI でチェックします。
1.NSX UI で、[ファブリック] | [ノード] | [トランスポート ノード] | [ホスト トランスポート ノード] の順に移動します。
2.[ホスト トランスポート ノード] リストで、[ノードの状態] 列を確認します。ノードの状態が劣化か停止のトランスポート ノードを特定します。
3.&ltトランスポート ノード&gt | [モニター] の順に選択します。劣化または停止が報告されているボンディング（アップリンク）を確認します。
4.失敗した DPU {dpu_id} にログインし、esxcli network vswitch dvs vmware lacp status get を呼び出して、LACP メンバーの状態の詳細を確認します。

アップリンクが停止しています。

イベントの検出時：「アップリンクが停止しています。」

イベントの解決時：「アップリンクが起動しています。」

ホストのアップリンクの物理 NIC の状態を確認します。
1.NSX UI で、[ファブリック] | [ノード] | [トランスポート ノード] | [ホスト トランスポート ノード] の順に移動します。
2.[ホスト トランスポート ノード] リストで、[ノードの状態] 列を確認します。ノードの状態が劣化か停止のトランスポート ノードを特定します。
3.&ltトランスポート ノード&gt | [モニター] の順に選択します。劣化または停止が報告されているボンディング（アップリンク）の状態を確認します。劣化状態を回避するには、使用中かどうかにかかわらず、すべてのアップリンク インターフェイスが接続され、稼動状態になっている必要があります。

アップリンクが停止しています。

イベントの検出時：「アップリンクが停止しています。」

イベントの解決時：「アップリンクが起動しています。」

ホストのアップリンクの物理 NIC の状態を確認します。
1.NSX UI で、[ファブリック] | [ノード] | [トランスポート ノード] | [ホスト トランスポート ノード] の順に移動します。
2.[ホスト トランスポート ノード] リストで、[ノードの状態] 列を確認します。ノードの状態が劣化か停止のトランスポート ノードを特定します。
3.&ltトランスポート ノード&gt | [モニター] の順に選択します。劣化または停止が報告されているボンディング（アップリンク）の状態を確認します。劣化状態を回避するには、使用中かどうかにかかわらず、すべてのアップリンク インターフェイスが接続され、稼動状態になっている必要があります。

LACP レポーティング メンバーが停止しています。

イベントの検出時：「LACP レポーティング メンバーが停止しています。」

イベントの解決時：「LACP レポーティング メンバーが起動しています。」

ホストの LAG メンバーの接続状態を確認します。
1.NSX UI で、[ファブリック] | [ノード] | [トランスポート ノード] | [ホスト トランスポート ノード] の順に移動します。
2.[ホスト トランスポート ノード] リストで、[ノードの状態] 列を確認します。ノードの状態が劣化か停止のトランスポート ノードを特定します。
3.&ltトランスポート ノード&gt | [モニター] の順に選択します。劣化または停止が報告されているボンディング（アップリンク）を確認します。
4.障害の発生したホストにログインして、ESXi ホストで esxcli network vswitch dvs vmware lacp status get を呼び出すか KVM ホストで ovs-appctl bond/show と ovs-appctl lacp/show を呼び出し、LACP メンバーの状態を確認します。

中継接続が完全に認識されません。

イベントの検出時：「中継接続関連の構成が完全には認識されていません。考えられる問題としては、プロバイダ情報の取得に失敗したか、一時的なプロバイダ通信エラーが発生している可能性があります。」

イベントの解決時：「中継接続の障害が修正されました。」

このアラームが 10 分以内に自動的に解決しない場合は、要求に関連する最後の中継接続を再試行してください。たとえば、TGW 接続 API 要求がこのアラームをトリガした場合、TGW 接続 API 要求をもう一度再試行します。再試行後もアラームが解決しない場合は、次の手順を試みてください。
1.タスクが失敗を繰り返しているか、タスクがリカバリされているかを確認します。a) リーダー マネージャ ノードを特定します。いずれかのノードにログインして次のコマンドを実行します。 - su admin - get cluster status verbose これにより、リーダー マネージャ ノードが表示されます。b) NSX リーダー マネージャ ノードにログインします。NSX リーダー マネージャ ノードの vmc-app.log を確認します。- tail -f /var/log/policy/vmc-app.log c) ログで次の出力を確認します。 - 次のエラー メッセージが 2 分ごとに記録されている場合、タスクが失敗を繰り返しています。- [] TGW ルート テーブルを取得できませんでした。エラー： [] - ルート テーブル [] の接続 [] の TGW ルートを取得できませんでした。エラー - [] の TGW 接続 VPC ID を取得できません。エラー： [] - [] の TGW 接続リソース ID を取得できません。エラー： 不明なリソース タイプ - TGW [] の TGW 接続を取得できませんでした。エラー： [] - ローカル TGW 接続 [] を取得できませんでした。エラー： [] - AWS の正しい TgwAttachment 状態を確認できませんでした。状態：[]。TGW ルート更新タスクをスキップします - TGW 接続 [] はどのルート テーブルにも関連付けられていません - [] にローカル TGW SDDC 接続はありません
2.リーダー マネージャ ノードで、NSX Manager からのすべての AWS 呼び出しが失敗しているかどうか確認します。次のコマンドを実行します。- export HTTP_PROXY=http://&ltpop ip&gt:3128 - export HTTPS_PROXY=http://&ltpop ip&gt:3128 - export NO_PROXY=169.254.169.254 - aws ec2 describe-instances --region aws コマンドがエラーで失敗した場合は、システムの POP の HTTP リバース プロキシ構成に問題があるか、AWS サービス側で問題が発生しています。
3.AWS に TGW 接続がまだ存在しているかどうか確認します。 a) 次のコマンドで TGW 接続 ID を確認します。GET cloud-service/api/v1/infra/associated-groups - aws ec2 describe-transit-gateway-attachments --region --transit-gateway-attachment-id &ltTGW attachment ID&gt TGW 接続が削除されている場合は、VMware のサポートに連絡して、SDDC ID と TGW 接続 ID を伝えてください。VMware のサポート チームが問題を確認した後、必要であれば、残っているオブジェクトを削除します。b) この TGW 接続が AWS コンソールに表示されているかどうか確認します。c) あるいは、NSX Manager にログインして次の aws コマンドを実行し、TGW 接続の状態を確認します。- aws ec2 describe-transit-gateway-attachments --region --transit-gateway-attachment-id &ltTGW attachment ID&gt

IPsec サービスが停止しています。

イベントの検出時：「IPsec サービス {entity_id} が停止しています。原因: {service_down_reason}。」

イベントの解決時：「IPsec サービス {entity_id} は起動しています。」

1.NSX Manager UI から IPsec サービスを無効にして有効にします。
2.問題が解決しない場合は、Syslog でエラー ログを確認し、VMware のサポートにお問い合わせください。

ポリシー ベース IPsec VPN セッションが停止しています。

イベントの検出時：「ポリシー ベース IPsec VPN セッション {entity_id} が停止しています。原因: {session_down_reason}。」

イベントの解決時：「ポリシー ベース IPsec VPN セッション {entity_id} が起動しています。」

IPsec VPN セッションの構成を確認し、セッション停止の理由に応じてエラーを解決します。

ルート ベース IPsec VPN セッションが停止しています。

イベントの検出時：「ルート ベース IPsec VPN セッション {entity_id} が停止しています。原因: {session_down_reason}。」

イベントの解決時：「ルート ベース IPsec VPN セッション {entity_id} が起動しています。」

IPsec VPN セッションの構成を確認し、セッション停止の理由に応じてエラーを解決します。

ポリシー ベース IPsec VPN トンネルが停止しています。

イベントの検出時：「セッション {entity_id} で、1 つ以上のポリシー ベース IPsec VPN トンネルが停止しています。」

イベントの解決時：「セッション {entity_id} で、すべてのポリシー ベース IPsec VPN トンネルが起動しています。」

IPsec VPN セッションの構成を確認し、トンネル停止の理由に応じてエラーを解決します。

ルート ベース IPsec VPN トンネルが停止しています。

イベントの検出時：「セッション {entity_id} でルート ベース IPsec VPN トンネルが停止しています。原因: {tunnel_down_reason}。」

イベントの解決時：「セッション {entity_id} でルート ベース IPsec VPN トンネルが起動しています。」

IPsec VPN セッションの構成を確認し、トンネル停止の理由に応じてエラーを解決します。

L2VPN セッションが停止しています。

イベントの検出時：「L2 VPN セッション {entity_id} が停止しています。」

イベントの解決時：「L2 VPN セッション {entity_id} が起動しています。」

L2VPN セッションの状態を確認してセッション停止の理由を特定し、それに基づいてエラーを解決します。