警示服務已超載。

偵測到事件時：「由於報告的警示數量過大，警示服務發生暫時超載的狀況。NSX UI 和 GET /api/v1/alarms NSX API 已停止報告新的警示；但 Syslog 項目和 SNMP 設陷 (如果已啟用) 仍會持續發出，以報告基礎事件詳細資料。當造成大量警示的基礎問題獲得解決後，警示服務就會重新開始報告新的警示。」

事件解決後：「目前已無大量警示，並已重新開始報告新的警示。」

請使用 NSX UI 中的 [警示] 頁面，或使用 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 中的 [警示] 頁面或使用 GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED NSX API，來檢閱 {event_id} 類型的所有作用中警示。對於每個作用中的警示，請透過依據建議的警示動作調查其根本原因。解決夠多的警示後，警示服務就會重新開始報告新的 {event_id} 警示。

至少有一個監控的記錄檔無法寫入。

偵測到事件時：「在管理程式、全域管理程式、Edge、公用雲端閘道、KVM 或 Linux 實體伺服器節點上，至少有一個受監控記錄檔具有唯讀權限或具有不正確的使用者/群組擁有權。或者，Windows 實體伺服器節點中的記錄資料夾遺失。或是管理程式、全域管理程式、Edge 或公用雲端閘道節點上遺失 rsyslog.log。」

事件解決後：「所有受監控的記錄檔在管理程式、全域管理程式、Edge、公用雲端閘道、KVM 或 Linux 實體伺服器節點上都有正確的檔案權限和擁有權。並且記錄資料夾存在於 Windows 實體伺服器節點上。同時，rsyslog.log 存在於管理程式、全域管理程式、Edge 或公用雲端閘道節點上。」

1.在管理程式和全域管理程式節點、Edge 和公用雲端閘道節點上，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 和公用雲端閘道節點上，確定 /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 或公用雲端閘道節點上遺失 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，從 NSX 應用裝置解析 FQDN。如果無法解析，請確認已指定正確的 FQDN，並且網路 DNS 伺服器具有 FQDN 的必要項目。
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 UI 中的容量頁面，並檢閱目前使用量與臨界值限制。如果目前使用量正常，請考慮增加最小臨界值。如果目前使用量異常，請檢閱設定的網路原則，讓使用量減少至最小臨界值或以下。

已違反容量臨界值上限。

偵測到事件時：「系統中為 {capacity_display_name} 定義的物件數目已達到 {capacity_usage_count}，這高於容量臨界值上限 {max_capacity_threshold}%。」

事件解決後：「系統中為 {capacity_display_name} 定義的物件數目已達到 {capacity_usage_count}，並且等於或低於容量臨界值上限 {max_capacity_threshold}%。」

導覽至 NSX UI 中的容量頁面，並檢閱目前使用量與臨界值限制。如果目前使用量正常，請考慮增加最大臨界值。如果目前使用量異常，請檢閱設定的網路原則，讓使用量減少至最大臨界值或以下。

已違反容量上限。

偵測到事件時：「系統中為 {capacity_display_name} 定義的物件數目已達到 {capacity_usage_count}，這高於最大支援計數 {max_supported_capacity_count}。」

事件解決後：「系統中為 {capacity_display_name} 定義的物件數目已達到 {capacity_usage_count}，並且等於或低於最大支援計數 {max_supported_capacity_count}。」

請確定所建立的 NSX 物件數在 NSX 支援的限制範圍內。如果有任何未使用的物件，請使用各自的 NSX UI 或 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 或 get service &ltservice_name&gt NSX CLI 命令，以判斷服務是否正在執行。如果不在執行中，請叫用 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 或 get service &ltservice_name&gt NSX CLI 命令，以判斷服務是否正在執行。如果不在執行中，請叫用 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 透過指定 DVS 上的 vmknic 進行連線。

偵測到事件時：「{vertical_name} 收集器 {collector_ip} 無法在 DPU {dpu_id} 透過 DVS {dvs_alias} 上的 vmknic (堆疊 {stack_alias}) 進行連線，但可以在其他 DVS 上透過的 vmknic (堆疊 {stack_alias}) 進行連線。」

事件解決後：「{vertical_name} 收集器 {collector_ip} 可在 DPU {dpu_id} 透過 DVS {dvs_alias} 上的 vmknic (堆疊 {stack_alias}) 進行連線，或者完全無法連線 {vertical_name} 收集器 {collector_ip}。」

如果發出警告，不表示收集器無法連線。根據 DVS {dvs_alias}，垂直產生的匯出流量仍可在 DVS (除了 DVS {dvs_alias}) 透過 vmknic 連線到收集器 {collector_ip}。如果無法接受此情況，使用者可以嘗試在 DVS {dvs_alias} 上建立具有堆疊 {stack_alias} 的 vmknic，並使用適當的 IPv4(6) 位址對其進行設定，然後檢查是否可在 DPU {dpu_id} 透過新建立的 vmknic 來連線至 {vertical_name} 收集器 {collector_ip}，方法是在啟用「透過 ESXi 使用 SSH 來連線至 DPU」的情況下，叫用 vmkping {collector_ip} -S {stack_alias} -I vmkX。

指定的收集器無法在 DPU 透過的現有 vmknic 進行連線。

偵測到事件時：「{vertical_name} 收集器 {collector_ip} 無法在 DPU {dpu_id} 上透過任何 DVS 上的現有 vmknic (堆疊 {stack_alias}) 進行連線。」

事件解決後：「{vertical_name} 收集器 {collector_ip} 現在可以在 DPU {dpu_id} 上使用現有 vmknic (堆疊 {stack_alias}) 進行連線。」

若要讓收集器可在 DVS 上垂直指定以進行連線，使用者必須確定建立具有預期堆疊 {stack_alias} 的 vmknic 並設定適當的 IPv4(6) 位址，並且與 {vertical_name} 收集器 {collector_ip} 的網路連線也正常。因此，使用者必須在 DPU {dpu_id} 執行檢查，並執行所需組態以確保符合條件。最後，如果在啟用「透過 ESXi 使用 SSH 來連線至 DPU」的情況下叫用 vmkping {collector_ip} -S {stack_alias} 成功，則表示問題已不存在。

管理程式節點之間的平均網路延遲高。

偵測到事件時：「在過去 5 分鐘內，管理程式節點 {manager_node_id} ({appliance_address}) 與 {remote_manager_node_id} ({remote_appliance_address}) 之間的平均網路延遲超過 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} 介面的連線。如果偵測不到，請檢查網路連線的穩定性。
2.檢查是否已使用 netstat 輸出建立 TCP 連線，以查看管理程式節點 {appliance_address} 上的控制器服務是否接聽連接埠 1235 上的連線。如果不是，請檢查防火牆 (或) 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} 介面的連線。如果偵測不到，請檢查網路連線的穩定性。
2.檢查是否已使用 netstat 輸出建立 TCP 連線，以查看管理程式節點 {appliance_address} 上的控制器服務是否接聽連接埠 1235 上的連線。如果不是，請檢查防火牆 (或) 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 設定維護模式時，傳輸節點將不會連線至控制器服務。當主機升級進行中時，通常會發生此情況。請等待幾分鐘，然後再次檢查連線。附註：此警示並不嚴重且應該能夠解決。此警示的通知不需要與 GSS 取得聯繫，除非該警示在很長的時間內仍未解決。

對傳輸節點連線的控制器服務已關閉。

偵測到事件時：「從控制器服務的觀點來看，管理程式節點 {appliance_address} ({central_control_plane_id}) 上對傳輸節點 {transport_node_name} ({entity_id}) 的控制器服務已關閉至少三分鐘。」

事件解決後：「管理程式節點 {appliance_address} ({central_control_plane_id}) 上的控制器服務會還原與傳輸節點 {entity_id} 的連線。」

1.透過 Ping 和 traceroute 檢查控制器服務 {central_control_plane_id} 與傳輸節點 {entity_id} 介面之間的連線。NSX Manager 節點 admin CLI 上可以執行此工作。Ping 測試不應發現捨棄，且應有一致的延遲值。VMware 建議的延遲值為 150 毫秒或更短。
2.在 NSX UI 上導覽至 [系統] | [網狀架構] | [節點] | [傳輸節點 {entity_id}]，以檢查管理程式節點 {appliance_address} ({central_control_plane_id}) 上的控制器服務與傳輸節點 {entity_id} 之間是否已建立 TCP 連線。如果沒有，請檢查網路和主機上的防火牆規則，以確認連接埠 1235 是否封鎖了傳輸節點 {entity_id} 連線要求。確保底層中沒有主機防火牆或網路防火牆封鎖管理程式節點和傳輸節點之間所需的 IP 連接埠。這項資料會記錄在我們的連接埠和通訊協定工具中，網址為：https://ports.vmware.com/。

控制器服務與傳輸節點的連線關閉時間過長。

偵測到事件時：「從控制器服務的觀點來看，管理程式節點 {appliance_address} ({central_control_plane_id}) 上對傳輸節點 {transport_node_name} ({entity_id}) 的控制器服務已關閉至少 15 分鐘。」

事件解決後：「管理程式節點 {appliance_address} ({central_control_plane_id}) 上的控制器服務會還原與傳輸節點 {entity_id} 的連線。」

1.透過 Ping 和 traceroute 檢查控制器服務 {central_control_plane_id} 與傳輸節點 {entity_id} 介面之間的連線。NSX Manager 節點 admin CLI 上可以執行此工作。Ping 測試不應發現捨棄，且應有一致的延遲值。VMware 建議的延遲值為 150 毫秒或更短。
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}) 上，叫用 get service applianceproxy NSX CLI 命令，以定期檢查服務狀態 60 分鐘。
2.如果服務未執行超過 60 分鐘，請叫用 restart service applianceproxy NSX CLI 命令，然後重新檢查狀態。如果服務仍為關閉狀態，請連絡 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.或者，透過叫用 PUT /api/v1/configs/management NSX API，並在要求本文中將 publish_fqdns 設為 false，來停用 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.或者，透過叫用 PUT /api/v1/configs/management NSX API，並在要求本文中將 publish_fqdns 設為 false，來停用 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}) 之間的平均網路延遲超過 150 毫秒，持續 5 分鐘。」

事件解決後：「管理程式節點和主機 {transport_node_name} ({transport_node_address}) 之間的平均網路延遲正常。」

1.請等待 5 分鐘，查看是否已自動解決警示。
2.從管理程式節點對 NSX 傳輸節點執行 Ping 動作。Ping 測試不應發現捨棄，且應有一致的延遲值。VMware 建議的延遲值為 150 毫秒或更短。
3.檢查任何其他實體網路層問題。如果問題仍在，請連絡 VMware 支援。

IP 集區中的 IP 位址已用盡。

偵測到事件時：「DHCP 伺服器 {dhcp_server_id} 的 IP 集區 {entity_id} 中的位址已用盡。前一次的 DHCP 要求失敗，且未來的要求將會失敗。」

事件解決後：「DHCP 伺服器 {dhcp_server_id} 的 IP 集區 {entity_id} 不再是用盡狀態。已成功將租用配置給上一個 DHCP 要求。」

透過叫用 NSX CLI 命令 get dhcp ip-pool，在 NSX UI 或執行 DHCP 伺服器所在的 Edge 節點上檢閱 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 CLI 命令 get dhcp ip-pool，在 NSX UI 或執行 DHCP 伺服器所在的 Edge 節點上檢閱 DHCP 集區組態。同時，透過叫用 NSX CLI 命令 get dhcp lease，來檢閱 Edge 節點上目前作用中的租用。將租用與作用中虛擬機器的數目比較。如果虛擬機器的數目相較於作用中租用的數目低，請考慮在 DHCP 伺服器組態上減少租用時間。另外，請造訪 NSX UI 中的 [網路] | [區段] | [區段] 頁面，以考慮擴充 DHCP 伺服器的集區範圍。

DFW CPU 使用率非常高。

偵測到事件時：「傳輸節點 {entity_id} 上的 DFW CPU 使用率已達到 {system_resource_usage}%，這等於或高於極高臨界值 {system_usage_threshold}%。」

事件解決後：「傳輸節點 {system_usage_threshold} 上的 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 UI 手動重新推送 DFW 組態。要重新推送的 DFW 原則可透過 DFW 篩選器 {entity_id} 來追蹤。此外，請一併考量尋找要連結 DFW 篩選器的虛擬機器，並將其重新啟動。

DFW 洪泛限制已達到警告層級。

偵測到事件時：「主機 {transport_node_name} 上 DFW 篩選器 {entity_id} 的 DFW 洪泛限制已達到通訊協定 {protocol_name} 所設定限制的 80% 警告層級。」

事件解決後：「針對通訊協定 {protocol_name}，主機 {transport_node_name} 上 DFW 篩選器 {entity_id} 的警告洪泛限制條件已清除。」

在 NSX Manager 中檢查主機上的虛擬機器，檢查為通訊協定 {protocol_name} 設定的 DFW 篩選器 {entity_id} 的洪泛警告層級。

DFW 洪泛限制已達到嚴重層級。

偵測到事件時：「主機 {transport_node_name} 上 DFW 篩選器 {entity_id} 的 DFW 洪泛限制已達到通訊協定 {protocol_name} 所設定限制的 98% 嚴重層級。」

事件解決後：「針對通訊協定 {protocol_name}，主機 {transport_node_name} 上 DFW 篩選器 {entity_id} 的嚴重洪泛限制條件已清除。」

在 NSX Manager 中檢查主機上的虛擬機器，檢查為通訊協定 {protocol_name} 設定的 DFW 篩選器 {entity_id} 的洪泛嚴重層級。

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} 設定的規則數目。

每個主機的 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 設定的規則數目。

每個主機的 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 IDPS 已透過 NSX 原則啟用，且 IDPS 規則已設定，但 NSX-IDPS 引擎已關閉。

偵測到事件時：「NSX IDPS 已透過 NSX 原則啟用，且 IDPS 規則已設定，但 NSX-IDPS 引擎已關閉。」

事件解決後：「NSX IDPS 處於以下任一情況。1.NSX IDPS 已透過 NSX 原則停用。2.NSX IDPS 引擎已啟用，NSX-IDPS 引擎和 vdpi 已啟動，且 NSX IDPS 已啟用，IDPS 規則已透過 NSX 原則進行設定。」

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 IDPS 已透過 NSX 原則啟用，且 IDPS 規則已設定，但 DPU 上的 NSX-IDPS 引擎已關閉。

偵測到事件時：「NSX IDPS 已透過 NSX 原則啟用，且 IDPS 規則已設定，但 DPU {dpu_id} 上的 NSX-IDPS 引擎已關閉。」

事件解決後：「DPU {dpu_id} 上的 NSX IDPS 處於以下任一情況。1.NSX IDPS 已透過 NSX 原則停用。2.NSX IDPS 引擎已啟用，NSX-IDPS 引擎和 vdpi 已啟動，且 NSX IDPS 已啟用，IDPS 規則已透過 NSX 原則進行設定。」

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 轉寄站，它不應處於已停用狀態。

一個 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 傳回連線逾時回應，則可能會發生網路錯誤或上游伺服器問題。檢查 DSN 查閱無法連線至上游伺服器的原因，或上游伺服器未傳回回應的原因。如果 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 來手動更新 Edge 傳輸節點設定原則意圖：PUT https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt。
2.透過 Edge 傳輸節點解析程式，接受此 Edge 傳輸節點的意圖或實現的 Edge 節點設定，以解決此警示。
3.使用下列重新整理 API 以接受 Edge 節點設定組態，來解決警示：POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode。

Edge 虛擬機器 vSphere 設定不相符。

偵測到事件時：「vSphere 上的 Edge 節點 {entity_id} 組態與原則意圖組態不相符。使用者在 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 以接受 Edge 節點 vSphere 實現組態，來解決警示：POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode。

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，來手動更新 Edge 傳輸節點設定原則意圖：PUT https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt。
2.透過 Edge 傳輸節點解析程式，接受此 Edge 傳輸節點的意圖或 vSphere 實現的 Edge 節點組態或實現的 Edge 節點設定，以解決此警示。
3.使用下列重新整理 API 以接受 Edge 節點設定和 vSphere 實現組態，來解決警示：POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode。

Edge vSphere 位置不相符。

偵測到事件時：「Edge 節點 {entity_id} 已使用 vMotion 進行移動。vSphere 上的 Edge 節點 {entity_id} 組態與原則意圖組態不相符。使用者在 UI 或 API 上可見的 Edge 節點組態與實現的不同。由 NSX Manager 外部使用者實現的 Edge 節點變更，會顯示在此警示的詳細資料中。Edge 節點的不同欄位會列在執行階段資料中 {edge_vsphere_location_mismatch_reason}」

事件解決後：「Edge 節點 {entity_id} 節點 vSphere 設定現在與原則意圖一致。」

檢閱此 Edge 傳輸節點 {entity_id} 的 vSphere 組態。遵循下列其中一個動作來解決警示 -
1.使用下列重新整理 API 以接受 Edge 節點 vSphere 實現組態，來解決警示：POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode。
2. 若要返回先前的位置，請使用 NSX 重新部署 API - POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy。不支援使用 vMotion 來返回原始主機。

自動 Edge 虛擬機器存在於 NSX 詳細目錄中，但不存在於 vCenter 中。

偵測到事件時：「在 NSX 詳細目錄中找到與 Edge 傳輸節點 {entity_id} vSphere 放置參數對應且 moref 識別碼為 {vm_moref_id} 的虛擬機器 {policy_edge_vm_name}，但不存在於 vCenter 中。檢查是否已在 vCenter 中移除該虛擬機器，或者是否存在具有不同虛擬機器 moref 識別碼的虛擬機器。」

事件解決後：「NSX 詳細目錄和 vCenter 中均存在具有虛擬機器 moref 識別碼 {vm_moref_id} 的 Edge 節點 {entity_id}。」

虛擬機器之受管理的物件參考 moref 識別碼具有表單 vm-number，在 vCenter UI 中選取 Edge 虛擬機器時，其會顯示在 URL 中。範例 vm-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary。針對此 Edge 傳輸節點 {entity_id}，在 vCenter 中尋找具有 moref 識別碼 {vm_moref_id} 的虛擬機器 {policy_edge_vm_name}。如果 Edge 虛擬機器存在於 vCenter 中，但具有不同的 moref 識別碼，請執行以下動作。使用 NSX 新增或更新具有 JSON 要求裝載內容 vm_id 和 vm_deployment_config 的放置 API，以更新新的虛擬機器 moref 識別碼和 vSphere 部署參數。POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=addOrUpdatePlacementReferences.如果名稱為 {policy_edge_vm_name} 的 Edge 虛擬機器不存在於 vCenter 中，請使用 NSX 重新部署 API 為 Edge 節點部署新的虛擬機器。POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy。

自動 Edge 虛擬機器不存在於 NSX 詳細目錄和 vCenter 中。

偵測到事件時：「在 NSX 詳細目錄和 vCenter 中均找不到與 Edge 傳輸節點 {entity_id} vSphere 放置參數對應且 moref 識別碼為 {vm_moref_id} 的虛擬機器 {policy_edge_vm_name}。此 Edge 傳輸節點 {entity_id} 之 vSphere 組態中的放置參數參考 moref 為 {vm_moref_id} 的虛擬機器。」

事件解決後：「NSX 詳細目錄和 vCenter 中均存在具有虛擬機器 moref 識別碼 {vm_moref_id} 的 Edge 節點 {entity_id}。」

虛擬機器之受管理的物件參考 moref 識別碼具有表單 vm-number，在 vCenter UI 中選取 Edge 虛擬機器時，其會顯示在 URL 中。範例 vm-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary。針對此 Edge 傳輸節點 {entity_id}，在 vCenter 中尋找具有 moref 識別碼 {vm_moref_id} 的虛擬機器 {policy_edge_vm_name}。遵循下方動作來解決警示 - 檢查虛擬機器是否已在 vSphere 中刪除，或存在但具有不同的 moref 識別碼。
1.如果該虛擬機器仍存在於 vCenter 中，請將 Edge 傳輸節點置於維護模式，然後在 vCenter 中關閉 Edge 虛擬機器的電源並將其刪除。使用 NSX 重新部署 API 為 Edge 節點部署新的虛擬機器。如果 Edge 虛擬機器正在轉送流量，Edge 傳輸節點的資料流量將在過渡期間中斷。
2.如果虛擬機器不存在於 vCenter 中，請使用重新部署 API 為 Edge 節點部署新的虛擬機器。POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy。

在重新部署期間，針對 vCenter 中舊 Edge 虛擬機器的關閉電源和刪除作業失敗。

偵測到事件時：「在重新部署作業期間，無法在 vCenter 中關閉 moref 識別碼為 {vm_moref_id} 之 Edge 節點 {entity_id} 虛擬機器的電源並將其刪除。已部署 moref 識別碼為 {new_vm_moref_id} 的新 Edge 虛擬機器。此 Edge 的舊虛擬機器和新虛擬機器同時運作，且可能會導致 IP 衝突和網路問題。」

事件解決後：「NSX 詳細目錄和 vCenter 中均無法再找到具有失效虛擬機器 moref 識別碼 {vm_moref_id} 的 Edge 節點 {entity_id}。NSX 詳細目錄和 vCenter 中均存在具有虛擬機器 moref 識別碼 {new_vm_moref_id} 的新部署虛擬機器。」

虛擬機器之受管理的物件參考 moref 識別碼具有表單 vm-number，在 vCenter UI 中選取 Edge 虛擬機器時，其會顯示在 URL 中。範例 vm-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary。針對此 Edge 傳輸節點 {entity_id}，在 vCenter 中尋找具有 moref 識別碼 {vm_moref_id} 的虛擬機器 {policy_edge_vm_name}。在 vCenter 中關閉 moref 識別碼為 {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} 上使用傳輸節點識別碼 {transport_node_id} 重新放置 Edge 叢集成員索引 {member_index_id} 之所有服務內容的作業失敗」

事件解決後：「目前已解決發生 {transport_node_id} 重新放置失敗的 Edge 節點。」

請檢閱 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 節點資料路徑組態失敗。

偵測到事件時：「在三次嘗試後，無法在 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 倍，可能會導致某些效能問題。如果在增加循環大小後，問題仍存在，則表示 Edge 需要更大的機器尺寸部署才能容納流量。
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.如果 Hypervisor 隨著 Edge 容納大量虛擬機器，則 Edge 虛擬機器可能不會有時間執行，為此，Hypervisor 可能不會擷取任何封包。如此可將 Edge 虛擬機器移轉至具有較少虛擬機器的主機。
2.使用「set dataplane ring-size tx」命令，將循環大小增加到 1024 倍 。如果在增加循環大小之後，問題仍存在，則請連絡 VMware 支援，因為 ESX 端傳輸循環緩衝區可能為較低的值。如果 ESX 端沒有任何問題，則表示 Edge 需要擴充至較大的機器尺寸部署，才能容納該流量。
3.如果警示持續進行變動，即觸發警示並很快解決，則這是由於突發流量導致。在此情況下，請使用 get dataplane cpu stats 命令，以檢查 tx pps。如果它在警示作用中期間不高，則連絡 VMware 支援。如果 PPS 偏高，則可確認突發流量。請考慮隱藏該警示。附註：沒有特定基準可決定何者可被視為高 pps 值。這取決於基礎架構和流量類型。記下警示何時處於非作用中和何時處於作用中，即可進行比較。

Edge 節點 NIC 連結已關閉。

偵測到事件時：「Edge 節點 NIC {edge_nic_name} 連結已關閉。」

事件解決後：「Edge 節點 NIC {edge_nic_name} 連結已啟動。」

在 Edge 節點上，透過叫用 NSX CLI 命令 get interfaces，來確認 NIC 連結是否已實際關閉。如果已關閉，請確認纜線連線。

Edge 節點磁碟為唯讀。

偵測到事件時：「Edge 節點上的下列磁碟分割處於唯讀模式：{disk_partition_name}」

事件解決後：「Edge 節點上的下列磁碟分割已從唯讀模式復原：{disk_partition_name}」

檢查唯讀磁碟分割，以查看重新開機是否可解決此問題，或是需要更換磁碟。如需詳細資訊，請連絡 GSS。

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 節點重新開機。

微流量快取叫用率降低，且資料路徑 CPU 偏高。

偵測到事件時：「Edge 節點 {entity_id} 上的微流量快取叫用率已低於核心 {core_id} 的指定臨界值 {flow_cache_threshold}%，且資料路徑 CPU 使用率已在過去 30 分鐘內增加。」

事件解決後：「流量快取叫用率在一般範圍內。」

過去 30 分鐘快取流量叫用率已減少，這表示 Edge 效能可能會降低。流量將繼續轉送，您可能不會遇到任何問題。如果過去 30 分鐘內 Edge {entity_id} 核心 {core_id} 較高，請檢查它的資料路徑 CPU 使用率。當持續建立新流量時，Edge 將具有低流量快取叫用率，因為任何新流量的第一個封包將用於設定為流量快取以進行快速路徑處理。您可能想要增加 Edge 應用裝置大小，或增加用於作用中/作用中閘道的 Edge 節點數目。

超大流量快取叫用率降低，且資料路徑 CPU 偏高。

偵測到事件時：「Edge 節點 {entity_id} 上的超大流量快取叫用率已低於核心 {core_id} 的指定臨界值 {flow_cache_threshold}%，且資料路徑 CPU 使用率已在過去 30 分鐘內增加。」

事件解決後：「流量快取叫用率在一般範圍內。」

過去 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，並叫用 service vmware-eam start 命令。

主機模組和合作夥伴 SVM 連線已關閉。

偵測到事件時：「主機模組與合作夥伴 SVM {entity_id} 之間的連線已關閉。」

事件解決後：「主機模組與合作夥伴 SVM {entity_id} 之間的連線已啟動。」

請參閱 https://kb.vmware.com/s/article/85844，並確定合作夥伴 SVM {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，並檢查是否已將正確的 RTEP IP 位址指派給名稱為 remote-tunnel-endpoint 的介面。
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 is not ready)，請檢查 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，並檢查是否已將正確的 RTEP IP 位址指派給名稱為 remote-tunnel-endpoint 的介面。
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}。在任何時候，只能有一個全域管理程式節點處於作用中。」

事件解決後：「全域管理程式節點 {active_global_manager} 是目前唯一的作用中全域管理程式節點。」

僅將一個全域管理程式節點設定為作用中狀態，並將所有其他全域管理程式節點設定為待命。

全域管理程式之間的延遲高於預期超過 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) 之間的資料同步失敗。

偵測到事件時：「站台 {site_name}({site_id}) 與 {remote_site_name}({remote_site_id}) 之間的 {flow_identifier} 資料同步失敗。原因：{sync_issue_reason}」

事件解決後：「站台 {site_name}({site_id}) 與 {remote_site_name}({remote_site_id}) 的 {flow_identifier} 現已同步。」

1.透過 Ping 檢查遠端站台本與機站台之間的網路連線。
2.確定本機站台與遠端站台之間允許連接埠 TCP/1236 流量。
3.確定本機站台和遠端站台均執行非同步複寫器服務。叫用 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) 之間的資料同步長時間失敗。

偵測到事件時：「站台 {site_name}({site_id}) 與 {remote_site_name}({remote_site_id}) 之間的 {flow_identifier} 資料同步長時間失敗。原因：{sync_issue_reason}。」

事件解決後：「站台 {site_name}({site_id}) 與 {remote_site_name}({remote_site_id}) 的 {flow_identifier} 現已同步。」

1.透過 Ping 檢查遠端站台本與機站台之間的網路連線。
2.確定本機站台與遠端站台之間允許連接埠 TCP/1236 流量。
3.確定本機站台和遠端站台均執行非同步複寫器服務。叫用 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 全域管理程式應用裝置 CLI。
2.切換到根目錄。
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} 個、AD 群組：{sid_count} 個。」

事件解決後：「群組 {group_id} 中的元素總數低於 {group_max_number_limit} 的上限。」

1.考慮調整過大群組 {group_id} 中的群組元素。
2.考慮將過大的群組 {group_id} 分割為多個較小的群組，並將過大群組的成員分散到這些群組。

第 0 層閘道已進行容錯移轉。

偵測到事件時：「第 0 層閘道 {entity_id} 從 {previous_gateway_state} 容錯移轉到 {current_gateway_state}，服務路由器為 {service_router_id}」

事件解決後：「第 0 層閘道 {entity_id} 現在已啟動。」

叫用 NSX CLI 命令 get logical-router &ltservice_router_id&gt，以識別第 0 層服務路由器 VRF 識別碼。透過叫用 vrf &ltvrf-id&gt 切換至 VRF 內容，然後叫用 get high-availability status，以判斷已關閉的服務。

第 1 層閘道已進行容錯移轉。

偵測到事件時：「第 1 層閘道 {entity_id} 從 {previous_gateway_state} 容錯移轉到 {current_gateway_state}，服務路由器為 {service_router_id}」

事件解決後：「第 1 層閘道 {entity_id} 現在已啟動。」

叫用 NSX CLI 命令 get logical-router &ltservice_router_id&gt，以識別第 1 層服務路由器 VRF 識別碼。透過叫用 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} 狀態。」

事件解決後：「第 0 層服務群組叢集 {entity_id} 現在於 Edge 節點 {transport_node_id} 上有一個作用中執行個體。」

叫用 NSX CLI 命令 get logical-router &ltservice_router_id&gt service_group，以檢查在指定服務路由器下設定的所有服務群組。檢查輸出服務群組離開作用中狀態的原因。

服務群組沒有作用中的執行個體。

偵測到事件時：「服務群組叢集 {entity_id} 目前沒有作用中的執行個體。其在 Edge 節點 {transport_node_id} 上處於 {ha_state} 狀態 (其中 0 為關閉，1 為待命，以及 2 為作用中)，且在 Edge 節點 {transport_node_id2} 上處於 {ha_state2} 狀態。」

事件解決後：「第 1 層服務群組叢集 {entity_id} 現在於 Edge 節點 {transport_node_id} 上有一個作用中執行個體。」

叫用 NSX CLI 命令 get logical-router &ltservice_router_id&gt service_group，以檢查在指定服務路由器下設定的所有服務群組。檢查輸出服務群組離開作用中狀態的原因。

服務群組中的待命執行個體失敗。

偵測到事件時：「Edge 節點 {transport_node_id} 上連結至第 0 層服務路由器 {service_router_id} 的服務群組叢集 {entity_id} 失敗。因此，服務群組叢集目前沒有待命執行個體。」

事件解決後：「服務群組叢集 {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，以檢查在指定服務路由器下設定的所有服務群組。檢查輸出先前待命服務群組失敗的原因。

服務群組中的待命執行個體失敗。

偵測到事件時：「Edge 節點 {transport_node_id} 上連結至第 1 層服務路由器 {service_router_id} 的服務群組叢集 {entity_id} 失敗。因此，服務群組叢集目前沒有待命執行個體。」

事件解決後：「服務群組叢集 {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，以檢查在指定服務路由器下設定的所有服務群組。檢查輸出先前待命服務群組失敗的原因。

與 LDAP 伺服器的連線中斷。

偵測到事件時：「與 LDAP 伺服器 {ldap_server} 的連線中斷。」

事件解決後：「與 LDAP 伺服器 {ldap_server} 的連線已還原。」

檢查以下各項：
1.LDAP 伺服器可從 NSX 節點進行連線。
2.LDAP 伺服器詳細資料已在 NSX 中已正確設定。
3.LDAP 伺服器已正確執行。
4.沒有防火牆會封鎖 LDAP 伺服器和 NSX 節點之間的存取。修正問題之後，請在 [身分識別防火牆 AD] 下方使用 NSX UI 中的 [測試連線]，來測試連線。

執行差異同步時發生錯誤。

偵測到事件時：「與 {directory_domain} 執行差異同步時發生錯誤。」

事件解決後：「與 {directory_domain} 執行差異同步時未發生任何錯誤。」

1.檢查是否有任何遺失 LDAP 伺服器連線的警示。
2.在 /var/log/syslog 中尋找錯誤詳細資料。在警示觸發時間前後，搜尋文字：Error happened when synchronize LDAP objects (同步 LDAP 物件時發生錯誤)。
3.詢問 AD 管理員是否有任何最近的 AD 變更可能會導致錯誤。
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，並使用根權限執行 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)，檢查是否在節點上安裝「允許」防火牆規則，7.叫用 /etc/init.d/netopa restart (ESX)、/etc/init.d/nsx-netopa restart (EDGE) 或 /etc/init.d/nsx-sha restart (UA)，以重新啟動 SHA 精靈，從而確定問題是否可以解決。

Edge 服務已關閉，時間已持續至少一分鐘。

偵測到事件時：「服務 {edge_service_name} 已關閉至少一分鐘。{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 支援團隊疑難排解此問題至關重要，建議最好先儲存最新技術支援服務包的複本，包括核心傾印檔案，然後再從系統移除核心傾印檔案。如需更多詳細資料，請參閱知識庫文章。

傳輸節點已與其智慧節點的訊息代理中斷連線。資料收集受到影響。

偵測到事件時：「傳輸節點 {entity_id} 上的流量匯出工具與智慧節點的訊息代理中斷連線。資料收集受到影響。」

事件解決後：「傳輸節點 {entity_id} 上的流量匯出工具已重新連線至智慧節點的訊息代理。」

如果未在智慧節點中執行，請重新啟動傳訊服務。解決傳輸節點流量匯出工具與智慧節點之間的網路連線失敗問題。

智慧節點 CPU 使用率非常高。

偵測到事件時：「智慧節點 {intelligence_node_id} 上的 CPU 使用率高於極高臨界值 {system_usage_threshold}%。」

事件解決後：「智慧節點 {intelligence_node_id} 上的 CPU 使用率低於極高臨界值 {system_usage_threshold}%。」

使用 top 命令來檢查哪些程序具有最多 CPU 使用率，然後檢查 /var/log/syslog 和這些程序的本機記錄，以查看是否有要解決的任何未完成的錯誤。

智慧節點 CPU 使用率偏高。

偵測到事件時：「智慧節點 {intelligence_node_id} 上的 CPU 使用率高於高臨界值 {system_usage_threshold}%。」

事件解決後：「智慧節點 {intelligence_node_id} 上的 CPU 使用率低於高臨界值 {system_usage_threshold}%。」

使用 top 命令來檢查哪些程序具有最多 CPU 使用率，然後檢查 /var/log/syslog 和這些程序的本機記錄，以查看是否有要解決的任何未完成的錯誤。

智慧節點記憶體使用量非常高。

偵測到事件時：「智慧節點 {intelligence_node_id} 上的記憶體使用量高於極高臨界值 {system_usage_threshold}%。」

事件解決後：「智慧節點 {intelligence_node_id} 上的記憶體使用量低於極高臨界值 {system_usage_threshold}%。」

使用 top 命令來檢查哪些程序具有最多記憶體使用量，然後檢查 /var/log/syslog 和這些程序的本機記錄，以查看是否有要解決的任何未完成的錯誤。

智慧節點記憶體使用量偏高。

偵測到事件時：「智慧節點 {intelligence_node_id} 上的記憶體使用量高於高臨界值 {system_usage_threshold}%。」

事件解決後：「智慧節點 {intelligence_node_id} 上的記憶體使用量低於高臨界值 {system_usage_threshold}%。」

使用 top 命令來檢查哪些程序具有最多記憶體使用量，然後檢查 /var/log/syslog 和這些程序的本機記錄，以查看是否有要解決的任何未完成的錯誤。

智慧節點磁碟使用量非常高。

偵測到事件時：「智慧節點 {intelligence_node_id} 上磁碟分割 {disk_partition_name} 的磁碟使用量高於極高臨界值 {system_usage_threshold}%。」

事件解決後：「智慧節點 {intelligence_node_id} 上磁碟分割 {disk_partition_name} 的磁碟使用量低於極高臨界值 {system_usage_threshold}%。」

檢查磁碟分割 {disk_partition_name}，並查看是否有任何非預期的大型檔案可移除。

智慧節點磁碟使用量偏高。

偵測到事件時：「智慧節點 {intelligence_node_id} 上磁碟分割 {disk_partition_name} 的磁碟使用量高於高臨界值 {system_usage_threshold}%。」

事件解決後：「智慧節點 {intelligence_node_id} 上磁碟分割 {disk_partition_name} 的磁碟使用量低於高臨界值 {system_usage_threshold}%。」

檢查磁碟分割 {disk_partition_name}，並查看是否有任何非預期的大型檔案可移除。

智慧節點資料磁碟分割使用率非常高。

偵測到事件時：「智慧節點 {intelligence_node_id} 上磁碟分割 /data 的磁碟使用量高於極高臨界值 {system_usage_threshold}%。」

事件解決後：「智慧節點 {intelligence_node_id} 上磁碟分割 /data 的磁碟使用量低於極高臨界值 {system_usage_threshold}%。」

停止 NSX Intelligence 資料收集，直到磁碟使用量低於臨界值。在 NSX UI 中，導覽至 [系統] | [應用裝置] | [NSX Intelligence 應用裝置]。然後按一下 [動作]，並選取 [停止收集資料]。

智慧節點資料磁碟分割使用率偏高。

偵測到事件時：「智慧節點 {intelligence_node_id} 上磁碟分割 /data 的磁碟使用量高於高臨界值 {system_usage_threshold}%。」

事件解決後：「智慧節點 {intelligence_node_id} 上磁碟分割 /data 的磁碟使用量低於高臨界值 {system_usage_threshold}%。」

停止 NSX Intelligence 資料收集，直到磁碟使用量低於臨界值。檢查磁碟分割 /data，並查看是否有任何非預期的大型檔案可移除。

智慧節點記憶體儲存區延遲偏高。

偵測到事件時：「智慧節點 {intelligence_node_id} 上的磁碟分割 {disk_partition_name} 的儲存區延遲高於高臨界值 {system_usage_threshold} 毫秒。」

事件解決後：「智慧節點 {intelligence_node_id} 上的磁碟分割 {disk_partition_name} 的儲存區延遲低於高臨界值 {system_usage_threshold} 毫秒。」

由於 I/O 要求激增，可能會發生儲存區延遲暫時性偏高的狀況。如果儲存空間延遲持續偏高達 30 分鐘以上，請考慮在延遲較低的磁碟中部署 NSX Intelligence 應用裝置，或不與其他虛擬機器共用相同的儲存裝置。

智慧節點狀態為已降級。

偵測到事件時：「智慧節點 {intelligence_node_id} 已降級。」

事件解決後：「智慧節點 {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 使用率高於系統使用率臨界值，則工作負載對此負載平衡器來說過高。將負載平衡器的大小從小型變更為中型或從中型變更為大型，以重新調整負載平衡器服務。如果此負載平衡器的 CPU 使用率仍然很高，請考慮調整 Edge 應用裝置機器尺寸大小，或將負載平衡器服務移至其他 Edge 節點，以獲得適當的工作負載。

負載平衡器服務已降級。

偵測到事件時：負載平衡器服務 {entity_id} 已降級。」

事件解決後：負載平衡器服務 {entity_id} 未降級。」

針對集中式負載平衡器：在待命 Edge 節點上檢查負載平衡器的狀態，因為降級狀態表示待命 Edge 節點上負載平衡器的狀態為未就緒。在待命 Edge 節點上，叫用 NSX CLI 命令 get load-balancer &ltlb-uuid&gt status。如果負載平衡器服務的 LB 狀態是「not_ready」，或沒有任何輸出，請讓 Edge 節點進入維護模式，然後結束維護模式。針對分散式負載平衡器：
1.叫用 NSX API GET /policy/api/v1/infra/lb-services/&ltLBService&gt/detailed-status?source=realtime，以取得詳細狀態
2.從 API 輸出中，尋找報告狀態為 NOT_READY 或 CONFLICT 之非零 instance_number 的 ESXi 主機。
3.在 ESXi 主機節點上，叫用 NSX CLI 命令「get load-balancer &ltlb-uuid&gt status」。如果報告了「衝突 LSP」，請檢查此 LSP 是否已連結至任何其他負載平衡器服務。檢查該衝突是否可以接受。如果報告了「未就緒 LSP」，請叫用 NSX CLI 命令 get logical-switch-port status，來檢查此 LSP 的狀態。附註：如果警示可以在 5 分鐘內自動解決，請略過該警示，因為降級狀態可能是暫時性狀態。

分散式負載平衡器服務已關閉。

偵測到事件時：「分散式負載平衡器服務 {entity_id} 已關閉。」

事件解決後：「分散式負載平衡器服務 {entity_id} 已啟動。」

在 ESXi 主機節點上，叫用 NSX CLI 命令「get load-balancer &ltlb-uuid&gt status」。如果報告了「衝突 LSP」，請檢查此 LSP 是否已連結至任何其他負載平衡器服務。檢查該衝突是否可以接受。如果報告了「未就緒 LSP」，請叫用 NSX CLI 命令 get logical-switch-port status，來檢查此 LSP 的狀態。

集中式負載平衡器服務已關閉。

偵測到事件時：「集中式負載平衡器服務 {entity_id} 已關閉。」

事件解決後：「集中式負載平衡器服務 {entity_id} 已啟動。」

在作用中的 Edge 節點上，叫用 NSX CLI 命令 get load-balancer &ltlb-uuid&gt status，來檢查負載平衡器狀態。如果負載平衡器服務的 LB 狀態是「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，來查閱負載平衡器集區，以判斷哪些成員已關閉。如果報告 [關閉] 或 [未知]，請驗證集區成員。檢查從負載平衡器到受影響集區成員的網路連線。驗證每個集區成員的應用程式健全狀況。此外，使用設定的監控，來驗證每個集區成員的健全狀況。當建立成員的健全狀況時，集區成員狀態會根據監視器中的「Rise Count」組態更新為狀況良好。將集區成員重新開機或讓 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} 未實現。」

事件解決後：負載平衡器組態 {entity_id} 已於 {transport_node_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，以尋找任何可疑錯誤。

服務狀態為已降級。

偵測到事件時：「服務 {mps_service_name} 在 {transport_node_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} 已降級。無法與惡意程式碼防護資料庫通訊。」

事件解決後：「服務 {mps_service_name} 在 NSX Application Platform 上正常執行。」

在 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 判斷惡意程式碼防護資料庫服務的狀態。

服務狀態為已降級。

偵測到事件時：「NSX Application Platform 上的服務 {mps_service_name} 已降級。無法與 analyst_api 服務通訊。檢查的檔案判定可能不是最新的。」

事件解決後：「服務 {mps_service_name} 在 NSX Application Platform 上正常執行。」

在 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 判斷惡意程式碼防護雲端連接器服務的狀態。

服務狀態為已降級。

偵測到事件時：「NSX Application Platform 上的服務 {mps_service_name} 已降級。無法與 NTICS 信譽服務通訊。檢查的檔案信譽可能不是最新的。」

事件解決後：「服務 {mps_service_name} 在 NSX Application Platform 上正常執行。」

在 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}%。」

檢閱此管理程式節點的組態、執行中服務和大小調整。考慮調整管理程式應用裝置機器尺寸大小。

管理程式節點 CPU 使用率偏高。

偵測到事件時：「管理程式節點 {entity_id} 上的 CPU 使用率已達到 {system_resource_usage}%，這等於或高於高臨界值 {system_usage_threshold}%。」

事件解決後：「管理程式節點 {entity_id} 上的 CPU 使用率已達到 {system_resource_usage}%，這低於高臨界值 {system_usage_threshold}%。」

檢閱此管理程式節點的組態、執行中服務和大小調整。考慮調整管理程式應用裝置機器尺寸大小。

管理程式節點記憶體使用量非常高。

偵測到事件時：「管理程式節點 {entity_id} 上的記憶體使用量已達到 {system_resource_usage}%，這等於或高於極高臨界值 {system_usage_threshold}%。」

事件解決後：「管理程式節點 {entity_id} 上的記憶體使用量已達到 {system_resource_usage}%，這低於極高臨界值 {system_usage_threshold}%。」

檢閱此管理程式節點的組態、執行中服務和大小調整。考慮調整管理程式應用裝置機器尺寸大小。

管理程式節點記憶體使用量偏高。

偵測到事件時：「管理程式節點 {entity_id} 上的記憶體使用量已達到 {system_resource_usage}%，這等於或高於高臨界值 {system_usage_threshold}%。」

事件解決後：「管理程式節點 {entity_id} 上的記憶體使用量已達到 {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}%。」

事件解決後：「管理程式節點磁碟分割 {disk_partition_name} 的磁碟使用量已達到 {system_resource_usage}%，這低於高臨界值 {system_usage_threshold}%。」

檢查具有高使用量的磁碟分割，並查看是否有任何可移除未預期的大型檔案。

管理程式節點組態磁碟使用量非常高。

偵測到事件時：「管理程式節點磁碟分割 /config 的磁碟使用量已達到 {system_resource_usage}%，這等於或高於極高臨界值 {system_usage_threshold}%。這可能表示 NSX 資料存放區服務在 /config/corfu 目錄下的磁碟使用量過高。」

事件解決後：「管理程式節點磁碟分割 /config 的磁碟使用量已達到 {system_resource_usage}%，這低於極高臨界值 {system_usage_threshold}%。」

如果報告了問題，請執行下列工具，並連絡 GSS：/opt/vmware/tools/support/inspect_checkpoint_issues.py

管理程式節點組態磁碟使用量偏高。

偵測到事件時：「管理程式節點磁碟分割 /config 的磁碟使用量已達到 {system_resource_usage}%，這等於或高於高臨界值 {system_usage_threshold}%。這可能表示 NSX 資料存放區服務在 /config/corfu 目錄下的磁碟使用量正在上升。」

事件解決後：「管理程式節點磁碟分割 /config 的磁碟使用量已達到 {system_resource_usage}%，這低於高臨界值 {system_usage_threshold}%。」

如果報告了問題，請執行下列工具，並連絡 GSS：/opt/vmware/tools/support/inspect_checkpoint_issues.py

管理程式節點 nonconfig 磁碟使用量極高。

偵測到事件時：「管理程式節點磁碟分割 /nonconfig 的磁碟使用量已達到 {system_resource_usage}%，這等於或高於極高臨界值 {system_usage_threshold}%。這可能表示 NSX 資料存放區服務在 /nonconfig/corfu 目錄下的磁碟使用量過高。」

事件解決後：「管理程式節點磁碟分割 /nonconfig 的磁碟使用量已達到 {system_resource_usage}%，這低於極高臨界值 {system_usage_threshold}%。」

如果報告了問題，請執行下列工具，並連絡 GSS：/opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig

管理程式節點 nonconfig 磁碟使用量偏高。

偵測到事件時：「管理程式節點磁碟分割 /nonconfig 的磁碟使用量已達到 {system_resource_usage}%，這等於或高於高臨界值 {system_usage_threshold}%。這可能表示 NSX 資料存放區服務在 /nonconfig/corfu 目錄下的磁碟使用量正在上升。」

事件解決後：「管理程式節點磁碟分割 /nonconfig 的磁碟使用量已達到 {system_resource_usage}%，這低於高臨界值 {system_usage_threshold}%。」

如果報告了問題，請執行下列工具，並連絡 GSS：/opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig

管理程式節點的 IP 位址由其他裝置使用中。

偵測到事件時：「管理程式節點 {entity_id} 的 IP 位址 {duplicate_ip_address} 目前由網路中的其他裝置使用中。」

事件解決後：使用指派給管理程式節點 {entity_id} 的 IP 位址的裝置似乎已不再使用 {duplicate_ip_address}。」

1.判定哪個裝置使用管理程式的 IP 位址，並為該裝置指派新的 IP 位址。請注意，不支援將管理程式重新設定為使用新的 IP 位址。
2.確定靜態 IP 位址集區/DHCP 伺服器已正確設定。
3.如果已手動指派裝置的 IP 位址，請更正該位址。

管理程式節點磁碟為唯讀。

偵測到事件時：「管理程式節點 {entity_id} 上的下列磁碟分割處於唯讀模式：{disk_partition_name}」

事件解決後：「管理程式節點 {entity_id} 上的下列磁碟分割已從唯讀模式復原：{disk_partition_name}」

檢查唯讀磁碟分割，以查看重新開機是否可解決此問題，或是需要更換磁碟。如需詳細資訊，請連絡 GSS。

遺失管理程式 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 簽署憑證取代為自我簽署憑證。

遺失 Manager VIP 的 FQDN 項目。

偵測到事件時：「如果是雙堆疊或 NSX Manager 的 CA 簽署的 API 憑證，管理程式節點 {entity_id} 的虛擬 IPv4 位址 {ipv4_address} 和虛擬 IPv6 位址 {ipv6_address} 應解析為相同的 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 組態大於連線至第 0 層或第 1 層之覆疊傳輸區域中的交換器 MTU。全域路由器 MTU 值應小於所有交換器 MTU 值至少 100，因為我們的 Geneve 封裝需要 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.或者，叫用 NSX API：PUT /api/v1/global-configs/RoutingGlobalConfig 並在要求本文中包含 logical_uplink_mtu，以便為全域路由器組態設定較小的 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 對應。檢查通過閘道的流量並非拒絕服務攻擊或異常高載。如果流量看起來在正常負載內，但仍達到警示臨界值，請考慮新增更多 SNAT IP 位址以分散負載，或將新流量路由至其他 Edge 節點。

管理程式節點偵測到 NCP 已關閉或狀況不良。

偵測到事件時：「管理程式節點偵測到 NCP 已關閉或狀況不良。」

事件解決後：「管理程式節點偵測到 NCP 已再次啟動或狀況良好。」

若要找出有問題的叢集，請使用 NSX UI 並導覽至 [警示] 頁面。此警示執行個體的實體名稱值可識別叢集名稱。或者，叫用 NSX API GET /api/v1/systemhealth/container-cluster/ncp/status，來擷取所有叢集狀態，並判斷任何報告 [關閉] 或 [未知] 之叢集的名稱。然後在 [NSX UI 詳細目錄] | [容器] | [叢集] 頁面上根據名稱尋找叢集，接著按一下 [節點] 索引標籤以列出所有 Kubernetes 和 PAS 叢集成員。對於 Kubernetes 叢集：
1.尋找來自所有叢集成員的 K8s 主節點，並登入主節點，以檢查 NCP 網繭活躍性。然後叫用 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 管理叢集重新連線。」

檢查 NSX Manager 和 NSX Application Platform 叢集上的管理程式叢集憑證、管理程式節點憑證、kafka 憑證和入口憑證是否相符。檢查上述憑證的到期日期以確保其有效。檢查 NSX Manager 和 NSX Application Platform 叢集上的網路連線，並解決任何網路連線失敗。

在傳訊主題原始流量中偵測到資料處理緩慢。

偵測到事件時：「傳訊主題原始流量的擱置中訊息數目高於 {napp_messaging_lag_threshold} 的擱置中訊息臨界值。」

事件解決後：「傳訊主題原始流量的擱置中訊息數目低於 {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 叢集之間的網路連線失敗問題。

傳輸節點已與其智慧節點的訊息代理中斷連線。DPU 上的資料收集受到影響。

偵測到事件時：「傳輸節點 {entity_id} DPU {dpu_id} 上的流量匯出工具與智慧節點的訊息代理中斷連線。資料收集受到影響。」

事件解決後：「傳輸節點 {entity_id} DPU {dpu_id} 上的流量匯出工具已重新連線至智慧節點的訊息代理。」

如果未在智慧節點中執行，請重新啟動傳訊服務。解決傳輸節點流量匯出工具與智慧節點之間的網路連線失敗問題。

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_id} 的 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_id} 的 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_id} 的記憶體使用量低於極高臨界值 {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_id} 的記憶體使用量低於高臨界值 {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_id} 的磁碟使用量低於極高臨界值 {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_id} 的磁碟使用量低於高臨界值 {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}%。」

擴充所有服務或分析服務。

平台服務 CPU 使用率非常高。

偵測到事件時：「平台服務的 CPU 使用率高於極高臨界值 {system_usage_threshold}%。」

事件解決後：「平台服務的 CPU 使用率低於極高臨界值 {system_usage_threshold}%。」

擴充所有服務。

平台服務 CPU 使用率偏高。

偵測到事件時：「平台服務的 CPU 使用率高於高臨界值 {system_usage_threshold}%。」

事件解決後：「平台服務的 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}%。」

擴充所有服務或分析服務。

平台服務記憶體使用量非常高。

偵測到事件時：「平台服務的記憶體使用量高於極高臨界值 {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}%。」

事件解決後：「分析服務的磁碟使用量低於極高臨界值 {system_usage_threshold}%。」

清理不需要的檔案。擴充所有服務或分析服務。

分析服務磁碟使用量偏高。

偵測到事件時：「分析服務的磁碟使用量高於高臨界值 {system_usage_threshold}%。」

事件解決後：「分析服務的磁碟使用量低於高臨界值 {system_usage_threshold}%。」

清理不需要的檔案。擴充所有服務或分析服務。

平台服務磁碟使用量非常高。

偵測到事件時：「平台服務的磁碟使用量高於極高臨界值 {system_usage_threshold}%。」

事件解決後：「平台服務的磁碟使用量低於極高臨界值 {system_usage_threshold}%。」

清理不需要的檔案。擴充所有服務。

平台服務磁碟使用量偏高。

偵測到事件時：「平台服務的磁碟使用量高於高臨界值 {system_usage_threshold}%。」

事件解決後：「平台服務的磁碟使用量低於高臨界值 {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 是該使用者的識別碼。如果 admin 使用者 (使用 &ltuserid&gt 10000) 密碼已到期，則 admin 必須透過 SSH (如果已啟用) 或主控台登入系統，才能變更密碼。輸入目前的已到期密碼時，系統會提示 admin 輸入新密碼。

使用者密碼即將到期。

偵測到事件時：「使用者 {username} 的密碼即將在 {password_expiration_days} 天後到期。」

事件解決後：「使用者 {username} 的密碼已成功變更，或密碼不再到期，或使用者不再為作用中。」

確定使用者 {username} 的密碼會立即變更。例如，若要將新密碼套用至使用者，請在要求本文中使用有效密碼叫用下列 NSX API：PUT /api/v1/node/users/&ltuserid&gt，其中 &ltuserid&gt 是該使用者的識別碼。

使用者密碼接近到期日。

偵測到事件時：「使用者 {username} 的密碼即將在 {password_expiration_days} 天後到期。」

事件解決後：「使用者 {username} 的密碼已成功變更，或密碼不再到期，或使用者不再為作用中。」

使用者 {username} 的密碼需要盡快變更。例如，若要將新密碼套用至使用者，請在要求本文中使用有效密碼叫用下列 NSX API：PUT /api/v1/node/users/&ltuserid&gt，其中 &ltuserid&gt 是該使用者的識別碼。

實體伺服器 (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} 中，靜態路由 {entity_id} ({static_address}) 已移除，因為 BFD 已關閉。」

事件解決後：「在路由器 {lr_id} 中，靜態路由 {entity_id} ({static_address}) 已在 BFD 復原時重新新增。」

由於 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 is not ready)，請檢查 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 設定 Proxy ARP。

偵測到事件時：「由於服務 IP 與路由器 {lr_id} 上 LRPort {lrport_id} 的子網路重疊已超過允許的臨界值限制 16384 而產生的 ARP Proxy 項目數，未設定服務 IP {service_ip} 和服務實體 {entity_id} 的 Proxy ARP。」

事件解決後：「由於服務 IP 與路由器 {lr_id} 上 LRPort {lrport_id} 的子網路重疊未超過允許的 16384 個項目數限制，已成功產生服務實體 {entity_id} 的 Proxy ARP。」

重新設定服務實體 {entity_id} 的服務 IP {service_ip}，或變更路由器 {lr_id} 上 LRPort {lrport_id} 的子網路，使得由於服務 IP 與 LRPort 的子網路重疊而產生的 Proxy ARP 項目數小於允許的臨界值限制 16384。

所有 BGP/BFD 工作階段已關閉。

偵測到事件時：「所有 BGP/BFD 工作階段已關閉。」

事件解決後：「至少一個 BGP/BFD 工作階段已啟動。」

叫用 NSX CLI 命令 get logical-routers，以取得第 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 識別碼並切換至第 0 層服務路由器。
2.執行 get ospf neighbor，以檢查此芳鄰的目前狀態。如果輸出中未列出芳鄰，表示芳鄰已關閉或不在網路中。
3.叫用 NSX CLI 命令 ping &ltOSPF neighbor IP address&gt，以驗證連線。
4.此外，確認 NSX 和對等路由器的組態，以確定計時器和區域識別碼相符。
5.檢查 /var/log/syslog，以查看是否有與連線相關的任何錯誤。

接近 Edge 節點的 IPv4 路由數目上限。

偵測到事件時：「第 0 層閘道以及 Edge 節點 {edge_node} 上所有第 0 層 VRF 的 IPv4 路由限制已達到 {route_limit_threshold}。」

事件解決後：「第 0 層閘道以及 Edge 節點 {edge_node} 上所有第 0 層 VRF 的 IPv4 路由位於 {route_limit_threshold} 的限制內。」

1.檢查從所有外部對等接收的路由重新分配原則和路由。
2.考慮透過相應地套用路由原則和篩選器來減少路由數目。

接近 Edge 節點的 IPv6 路由數目上限。

偵測到事件時：「第 0 層閘道以及 Edge 節點 {edge_node} 上所有第 0 層 VRF 的 IPv6 路由限制已達到 {route_limit_threshold}。」

事件解決後：「第 0 層閘道以及 Edge 節點 {edge_node} 上所有第 0 層 VRF 的 IPv6 路由位於 {route_limit_threshold} 的限制內。」

1.檢查從所有外部對等接收的路由重新分配原則和路由。
2.考慮透過相應地套用路由原則和篩選器來減少路由數目。

已超過 Edge 節點的 IPv4 路由上限。

偵測到事件時：「第 0 層閘道以及 Edge 節點 {edge_node} 上所有第 0 層 VRF 的 IPv4 路由已超出 {route_limit_maximum} 限制。」

事件解決後：「第 0 層閘道以及 Edge 節點 {edge_node} 上所有第 0 層 VRF 的 IPv4 路由位於 {route_limit_maximum} 的限制內。」

1.檢查從所有外部對等接收的路由重新分配原則和路由。
2.考慮透過相應地套用路由原則和篩選器來減少路由數目。

已超過 Edge 節點的 IPv6 路由上限。

偵測到事件時：「第 0 層閘道以及 Edge 節點 {edge_node} 上所有第 0 層 VRF 的 IPv6 路由已超出 {route_limit_maximum} 限制。」

事件解決後：「第 0 層閘道以及 Edge 節點 {edge_node} 上所有第 0 層 VRF 的 IPv6 路由位於 {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 合規性需求。這表示 NSX 狀態目前與 NDcPP 不相容。」

事件解決後：「NDcPP 合規性問題已全部解決。」

從 UI 首頁 - 監控和儀表板 - 符合性報告功能表執行符合性報告，並解決所有標記有 NDcPP 合規性名稱的問題。

NSX 安全性狀態不符合 EAL4+ 標準。

偵測到事件時：「違反其中一個 EAL4+ 合規性需求。這表示在 EAL4+ 方面，NSX 狀態目前不符合標準。」

事件解決後：「EAL4+ 合規性問題已全部解決。」

從 UI 首頁 - 監控和儀表板 - 合規性報告功能表執行符合性報告，並解決所有標記有 EAL4+ 合規性名稱的問題。

NSX 安全性組態不符合 NDcPP 標準。

偵測到事件時：「違反其中一個 NDcPP 合規性需求。這表示 NSX 組態目前與 NDcPP 不相容。」

事件解決後：「NDcPP 合規性問題已全部解決。」

從 UI 首頁 - 監控和儀表板 - 符合性報告功能表執行符合性報告，並解決所有標記有 NDcPP 合規性名稱的問題。

NSX 安全性組態不符合 EAL4+ 標準。

偵測到事件時：「違反其中一個 EAL4+ 合規性需求。這表示在 EAL4+ 方面，NSX 組態目前不符合標準。」

事件解決後：「EAL4+ 合規性問題已全部解決。」

從 UI 首頁 - 監控和儀表板 - 合規性報告功能表執行符合性報告，並解決所有標記有 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 UI 或 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 UI 或 API 刪除服務部署。執行知識庫的任何更正動作，並再次重試刪除服務部署。在檢查是否已刪除所有虛擬機器和物件後，手動解決警示。

SVM 正在服務中運作。

偵測到事件時：「服務 {service_name} 的 SVM {entity_id} 健全狀況檢查正在 {hostname_or_ip_address_with_port} 上正常運作。」

事件解決後：「SVM {entity_id} 正常運作，無需執行任何動作。」

無需執行任何動作。

SVM 未在服務中運作。

偵測到事件時：「服務 {service_name} 的 SVM {entity_id} 健全狀況檢查無法在 {hostname_or_ip_address_with_port} 上正常運作。原因：{failure_reason}。」

事件解決後：「已移除狀態錯誤的 SVM {entity_id}。」

使用 NSX UI 或 API 刪除服務部署。執行知識庫的任何更正動作，並視需要再次重試服務部署。

主機上的服務插入基礎結構狀態已關閉且未啟用。

偵測到事件時：「主機 {transport_node_id} 上的連接埠層級未啟用 SPF，且狀態為關閉。原因：{failure_reason}。」

事件解決後：「服務插入基礎結構狀態已啟動，且已在主機上正確啟用。」

執行知識庫的任何更正動作，並檢查狀態是否為開啟。在檢查狀態後，手動解決警示。

SVM 活躍度狀態關閉。

偵測到事件時：「{entity_id} 上的 SVM 活躍度狀態為關閉，且流量受到影響。」

事件解決後：「SVM 活躍度狀態已開啟，並如預期進行設定。」

執行知識庫的任何更正動作，並檢查狀態是否為開啟。

服務鏈結路徑關閉。

偵測到事件時：「{entity_id} 上的服務鏈結路徑已關閉，且流量受到影響。」

事件解決後：「服務鏈結路徑已啟動且如預期般進行設定。」

執行知識庫的任何更正動作，並檢查狀態是否為開啟。

已在叢集中新增主機。

偵測到事件時：「已在叢集 {vcenter_cluster_id} 中新增主機，且將部署 SVM。」

事件解決後：「新主機新增成功。」

檢查虛擬機器部署狀態並等待其開啟電源。

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} 的 TEP {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.選取 [&lttransport node&gt] | [監控]。尋找報告為降級或關閉的繫結 (上行) 的狀態詳細資料。若要避免發生降級狀態，無論是否正在使用中，請確保上行介面均已連線並開啟。

DPU 上的 LACP 報告成員關閉。

偵測到事件時：「DPU {dpu_id} 上的 LACP 報告成員關閉。」

事件解決後：「DPU {dpu_id} 上的 LACP 報告成員啟動。」

檢查 DPU {dpu_id} 上 LAG 成員的連線狀態。在主機上找到相關實體 NIC 的對應名稱，然後在 UI 上執行檢查。
1.在 NSX UI 中，導覽至 [網狀架構] | [節點] | [傳輸節點] | [主機傳輸節點]。
2.在 [主機傳輸節點] 清單中，檢查 [節點狀態] 資料行。尋找 [節點狀態] 為降級或關閉的傳輸節點。
3.選取 [&lttransport node&gt] | [監控]。尋找報告為降級或關閉的繫結 (上行)。
4.透過登入失敗的 DPU {dpu_id} 並叫用 esxcli network vswitch dvs vmware lacp status get，來檢查 LACP 成員狀態詳細資料。

上行即將關閉。

偵測到事件時：「上行即將關閉。」

事件解決後：「上行即將啟動。」

檢查主機上上行的實體 NIC 狀態。
1.在 NSX UI 中，導覽至 [網狀架構] | [節點] | [傳輸節點] | [主機傳輸節點]。
2.在 [主機傳輸節點] 清單中，檢查 [節點狀態] 資料行。尋找 [節點狀態] 為降級或關閉的傳輸節點。
3.選取 [&lttransport node&gt] | [監控]。尋找報告為降級或關閉的繫結 (上行) 的狀態詳細資料。若要避免發生降級狀態，無論是否正在使用中，請確保上行介面均已連線並開啟。

上行即將關閉。

偵測到事件時：「上行即將關閉。」

事件解決後：「上行即將啟動。」

檢查主機上上行的實體 NIC 狀態。
1.在 NSX UI 中，導覽至 [網狀架構] | [節點] | [傳輸節點] | [主機傳輸節點]。
2.在 [主機傳輸節點] 清單中，檢查 [節點狀態] 資料行。尋找 [節點狀態] 為降級或關閉的傳輸節點。
3.選取 [&lttransport node&gt] | [監控]。尋找報告為降級或關閉的繫結 (上行) 的狀態詳細資料。若要避免發生降級狀態，無論是否正在使用中，請確保上行介面均已連線並開啟。

LACP 報告成員已關閉。

偵測到事件時：「LACP 報告成員已關閉。」

事件解決後：「LACP 報告成員已啟動。」

檢查主機上 LAG 成員的連線狀態。
1.在 NSX UI 中，導覽至 [網狀架構] | [節點] | [傳輸節點] | [主機傳輸節點]。
2.在 [主機傳輸節點] 清單中，檢查 [節點狀態] 資料行。尋找 [節點狀態] 為降級或關閉的傳輸節點。
3.選取 [&lttransport node&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) 檢查記錄是否有下列列印內容 - 如果這些錯誤訊息持續每兩分鐘顯示一次，則表示工作持續失敗。- 無法取得 [] 的 TGW 路由表。錯誤：[] - 無法取得路由表 [] 中連結 [] 的 TGW 路由。錯誤 - 無法取得 [] 的 TGW 連結 VPC 識別碼。錯誤：[] - 無法取得 [] 的 TGW 連結資源識別碼。錯誤：未知的資源類型 - 無法取得 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 反向 Proxy 組態中可能存在系統問題，或存在 AWS 服務端問題。
3.檢查 AWS 中是否仍存在 TGW 連結。a) TGW 連結識別碼可以透過 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 識別碼和 TGW 連結識別碼。VMware 支援小組發現此問題後，請視需要手動刪除遺留的物件。b) 檢查 AWS 主控台上是否存在此 TGW 連結。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} 中一或多個以原則為基礎的 IPSec VPN 通道已關閉。」

事件解決後：「工作階段 {entity_id} 中所有以原則為基礎的 IPSec VPN 通道均已啟動。」

檢查 IPSec VPN 工作階段組態，並根據通道關閉的原因解決錯誤。

以路由為基礎的 IPSec VPN 通道已關閉。

偵測到事件時：「工作階段 {entity_id} 中以路由為基礎的 IPSec VPN 通道已關閉。原因：{tunnel_down_reason}。」

事件解決後：「工作階段 {entity_id} 中以路由為基礎的 IPSec VPN 通道已啟動。」

檢查 IPSec VPN 工作階段組態，並根據通道關閉的原因解決錯誤。

L2VPN 工作階段已關閉。

偵測到事件時：「L2VPN 工作階段 {entity_id} 已關閉。」

事件解決後：「L2VPN 工作階段 {entity_id} 已啟動。」

檢查 L2VPN 工作階段狀態以瞭解工作階段關閉的原因，並根據原因解決錯誤。