警报服务已过载。

检测到事件时：“由于报告的警报数量过大，导致警报服务暂时过载。NSX UI 和 NSX API GET /api/v1/alarms 已停止报告新的警报；但是，仍会发出 syslog 条目和 SNMP 陷阱 (如果已启用)，以报告底层事件的详细信息。在解决了导致警报大量出现的底层问题后，警报服务将重新开始报告新的警报。”

事件解决后：“警报过量的情况已缓解，将再次报告新的警报。”

使用 NSX UI 中的“警报”页面或使用 NSX API：GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED 来查看所有活动警报。对于每个活动警报，请遵循针对该警报的建议操作来调查根本原因。解决了足够数量的警报后，警报服务将再次开始报告新的警报。

检测到特定警报类型的数量过大。

检测到事件时：“由于 {event_id} 警报数量过大，导致警报服务暂时停止报告此类警报。NSX UI 和 NSX API GET /api/v1/alarms 将不会报告这些警报的新实例；但是，仍会发出 syslog 条目和 SNMP 陷阱 (如果已启用)，以报告底层事件的详细信息。在解决了导致 {event_id} 警报大量出现的底层问题后，当再次检测到新的问题时，警报服务将重新开始报告新的 {event_id} 警报。”

事件解决后：“{event_id} 警报过量的情况已缓解，将再次报告此类新警报。”

使用 NSX UI 中的“警报”页面或使用 NSX API：GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED 来查看 {event_id} 类型的所有活动警报。对于每个活动警报，请遵循针对该警报的建议操作来调查根本原因。解决了足够数量的警报后，警报服务将再次开始报告新的 {event_id} 警报。

至少有一个受监控的日志文件无法写入。

检测到事件时：“在管理器、全局管理器、Edge、公有云网关、KVM 或 Linux 物理服务器节点上，至少有一个受监控的日志文件具有只读权限或具有不正确的用户/组所有权。或者，Windows 物理服务器节点上缺少日志文件夹。或者，管理器、全局管理器、Edge 或公有云网关节点上缺少 rsyslog.log。”

事件解决后：“在管理器、全局管理器、Edge、公有云网关、KVM 或 Linux 物理服务器节点上，所有受监控的日志文件均具有正确的文件权限和所有权。而且，Windows 物理服务器节点上存在日志文件夹。同时，管理器、全局管理器、Edge 或公有云网关节点上存在 rsyslog.log。”

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} 已被移除或不再为‘已过期’状态。”

确保当前使用该证书的服务已更新为使用未过期的新证书。一旦不再使用过期的证书，就应通过调用 NSX API：DELETE {api_collection_path}{entity_id} 来将其删除。如果 NAPP Platform 使用过期的证书，则 NSX 与 NAPP Platform 之间的连接将断开。请查看 NAPP Platform 故障排除文档，以使用自签名 NAPP CA 证书恢复连接。

证书就要过期。

检测到事件时：“证书 {entity_id} 就要过期。”

事件解决后：“即将过期的证书 {entity_id} 已被移除或不再为‘就要过期’状态。”

确保当前使用该证书的服务已更新为使用非即将过期的新证书。一旦不再使用即将过期的证书，就应通过调用 NSX API：DELETE {api_collection_path}{entity_id} 来将其删除。

证书即将过期。

检测到事件时：“证书 {entity_id} 即将过期。”

事件解决后：“即将过期的证书 {entity_id} 已被移除或不再为‘即将过期’状态。”

确保当前使用该证书的服务已更新为使用非即将过期的新证书。一旦不再使用即将过期的证书，就应通过调用 NSX API：DELETE {api_collection_path}{entity_id} 来将其删除。

推荐更新受信任的 CA 包。

检测到事件时：“在超过 {ca_bundle_age_threshold} 天前更新了受信任的 CA 包 {entity_id}。推荐更新该受信任的 CA 包。”

事件解决后：“受信任的 CA 包 {entity_id} 已移除、已更新或不再使用。”

确保当前使用该受信任 CA 包的服务已更新为使用最近更新的受信任 CA 包。除非是由系统提供的包，否则可以使用 NSX API：PUT /policy/api/v1/infra/cabundles/{entity_id} 更新包。一旦不再使用过期的包，就应通过调用 NSX API：DELETE /policy/api/v1/infra/cabundles/{entity_id} 来将其删除（如果不是由系统提供）。

建议更新受信任的 CA 包。

检测到事件时：“在超过 {ca_bundle_age_threshold} 天前更新了受信任的 CA 包 {entity_id}。建议更新该受信任的 CA 包。”

事件解决后：“受信任的 CA 包 {entity_id} 已移除、已更新或不再使用。”

确保当前使用该受信任 CA 包的服务已更新为使用最近更新的受信任 CA 包。除非是由系统提供的包，否则可以使用 NSX API：PUT /policy/api/v1/infra/cabundles/{entity_id} 更新包。一旦不再使用过期的包，就应通过调用 NSX API：DELETE /policy/api/v1/infra/cabundles/{entity_id} 来将其删除（如果不是由系统提供）。

证书已过期。

检测到事件时：“传输节点 {entity_id} 的证书已过期。”

事件解决后：“传输节点 {entity_id} 的过期证书已替换或不再为‘已过期’状态。”

将传输节点 {entity_id} 证书替换为未过期的证书。应通过调用 NSX API：POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id} 来替换过期的证书。如果传输节点使用的是过期证书，则传输节点和管理器节点之间的连接将断开。

证书就要过期。

检测到事件时：“传输节点 {entity_id} 的证书就要过期。”

事件解决后：“传输节点 {entity_id} 的即将过期的证书已被移除或不再为‘就要过期’状态。”

将传输节点 {entity_id} 证书替换为未过期的证书。应通过调用 NSX API：POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id} 来替换过期的证书。如果未替换证书，则在证书过期后，传输节点和管理器节点之间的连接会断开。

证书即将过期。

检测到事件时：“传输节点 {entity_id} 的证书即将过期。”

事件解决后：“传输节点 {entity_id} 的即将过期的证书已被移除或不再为‘即将过期’状态。”

将传输节点 {entity_id} 证书替换为未过期的证书。应通过调用 NSX API：POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id} 来替换过期的证书。如果未替换证书，则在证书过期后，传输节点和管理器节点之间的连接会断开。

组成员已关闭。

检测到事件时：“服务 {group_type} 的组成员 {manager_node_id} 已关闭。”

事件解决后：“{group_type} 的组成员 {manager_node_id} 已启动。”

1.调用 NSX CLI 命令“get cluster status”以查看集群中组成员的状态。
2.确保节点上正在运行 {group_type} 服务。调用 NSX CLI: GET /api/v1/node/services/&ltservice_name&gt/status 或 NSX CLI 命令 get service &ltservice_name&gt 以确定该服务是否正在运行。如果未在运行，请调用 NSX API：POST /api/v1/node/services/&ltservice_name&gt?action=restart 或 NSX CLI 命令 restart service &ltservice_name&gt 以重新启动该服务。
3.检查 {group_type} 服务的 /var/log/ 以查看是否报告了错误。

服务的所有组成员均已关闭。

检测到事件时：“服务 {group_type} 的所有组成员 {manager_node_ids} 均已关闭。”

事件解决后：“服务 {group_type} 的所有组成员 {manager_node_ids} 均已启动。”

1.确保节点上正在运行 {group_type} 服务。调用 NSX CLI: GET /api/v1/node/services/&ltservice_name&gt/status 或 NSX CLI 命令 get service &ltservice_name&gt 以确定该服务是否正在运行。如果未在运行，请调用 NSX API：POST /api/v1/node/services/&ltservice_name&gt?action=restart 或 NSX CLI 命令 restart service &ltservice_name&gt 以重新启动该服务。
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 访问给定收集器。

检测到事件时：“在 DPU {dpu_id} 上，无法通过 DVS {dvs_alias} 上的 vmknic (堆栈 {stack_alias}) 访问 {vertical_name} 收集器 {collector_ip}，但可通过其他 DVS 上的 vmknic (堆栈 {stack_alias}) 进行访问。”

事件解决后：“在 DPU {dpu_id} 上，可通过 DVS {dvs_alias} 上的 vmknic (堆栈 {stack_alias}) 访问 {vertical_name} 收集器 {collector_ip}，或者完全无法访问 {vertical_name} 收集器 {collector_ip}。”

如果发出警告，这并不意味着收集器无法访问。由基于 DVS {dvs_alias} 的垂直项生成的导出流量仍然可以通过 DVS {dvs_alias} 以外的其他 DVS 上的 vmknic 访问收集器 {collector_ip}。如果无法接受此行为，用户可以尝试在 DVS {dvs_alias} 上创建包含堆栈 {stack_alias} 的 vmknic，并为其配置相应的 IPv4(6) 地址，然后在启用“通过 ESXi 使用 SSH 访问 DPU”的情况下调用 vmkping {collector_ip} -S {stack_alias} -I vmkX，以检查是否可以在 DPU {dpu_id} 上通过新创建的 vmknic 访问 {vertical_name} 收集器 {collector_ip}。

在 DPU 上，根本无法通过现有 vmknic 访问给定收集器。

检测到事件时：“在 DPU {dpu_id} 上，无法通过任何 DVS 上的现有 vmknic (堆栈 {stack_alias}) 访问 {vertical_name} 收集器 {collector_ip}。”

事件解决后：“在 DPU {dpu_id} 上，现在可通过现有 vmknic (堆栈 {stack_alias}) 访问 {vertical_name} 收集器 {collector_ip}。”

要使 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} 接口的连接。如果无法 ping 通，请检查网络连接问题。
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} 接口的连接。如果无法 ping 通，请检查网络连接问题。
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}) 的连接至少已关闭 3 分钟。”

事件解决后：“管理器节点 {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 上导航到“系统”|“Fabric”|“节点”|“传输节点 {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 上导航到“系统”|“Fabric”|“节点”|“传输节点 {entity_id}”，以检查是否在管理器节点 {appliance_address} ({central_control_plane_id}) 上的控制器服务和传输节点 {entity_id} 之间建立了 TCP 连接。如果没有，请检查网络和主机上的防火墙规则，以确定端口 1235 是否阻止传输节点 {entity_id} 连接请求。确保底层网络中没有任何主机防火墙或网络防火墙阻止管理器节点和传输节点之间所需的 IP 端口。在我们的端口和协议工具中描述了该问题，网址为 https://ports.vmware.com/。

管理器至控制器通道已关闭。

检测到事件时：“管理功能与控制功能之间的通信在管理器节点 {manager_node_name} ({appliance_address}) 上失败。”

事件解决后：“管理功能与控制功能之间的通信已在管理器节点 {manager_node_name} ({appliance_address}) 上还原。”

1.在管理器节点 {manager_node_name} ({appliance_address}) 上，请调用 NSX CLI 命令 get service applianceproxy，以定期检查 60 分钟内的服务状态。
2.如果服务运行时间未超过 60 分钟，请调用 NSX CLI 命令 restart service applianceproxy，并重新检查状态。如果服务仍处于关闭状态，请联系 VMware 技术支持团队。

至传输节点的管理通道已关闭。

检测到事件时：“至传输节点 {transport_node_name} ({transport_node_address}) 的管理通道已关闭 5 分钟。”

事件解决后：“至传输节点 {transport_node_name} ({transport_node_address}) 的管理通道已启动。”

确保管理器节点和传输节点 {transport_node_name} ({transport_node_address}) 之间存在网络连接，并且没有防火墙阻止节点之间的流量。在 Windows 传输节点上，通过在 Windows PowerShell 中调用命令 C:\NSX\nsx-proxy\nsx-proxy.ps1 status，确保在传输节点上正在运行 nsx-proxy 服务。如果未运行，请通过调用命令 C:\NSX\nsx-proxy\nsx-proxy.ps1 restart 重新启动该服务。在所有其他传输节点上，通过调用命令 /etc/init.d/nsx-proxy status，确保在传输节点上正在运行 nsx-proxy 服务。如果未运行，请通过调用命令 /etc/init.d/nsx-proxy restart 重新启动该服务。

至传输节点的管理通道已关闭太长时间。

检测到事件时：“至传输节点 {transport_node_name} ({transport_node_address}) 的管理通道已关闭 15 分钟。”

事件解决后：“至传输节点 {transport_node_name} ({transport_node_address}) 的管理通道已启动。”

确保管理器节点和传输节点 {transport_node_name} ({transport_node_address}) 之间存在网络连接，并且没有防火墙阻止节点之间的流量。在 Windows 传输节点上，通过在 Windows PowerShell 中调用命令 C:\NSX\nsx-proxy\nsx-proxy.ps1 status，确保在传输节点上正在运行 nsx-proxy 服务。如果未运行，请通过调用命令 C:\NSX\nsx-proxy\nsx-proxy.ps1 restart 重新启动该服务。在所有其他传输节点上，通过调用命令 /etc/init.d/nsx-proxy status，确保在传输节点上正在运行 nsx-proxy 服务。如果未运行，请通过调用命令 /etc/init.d/nsx-proxy restart 重新启动该服务。

管理器节点 FQDN 的 DNS 查找失败。

检测到事件时：“FQDN 为 {appliance_fqdn} 并且已设置 publish_fqdns 标记的管理器节点 {entity_id} 的 DNS 查找失败。”

事件解决后：“FQDN 为 {appliance_fqdn} 或已清除 publish_fqdns 标记的管理器节点 {entity_id} 的 FQDN 查找成功。”

1.将正确的 FQDN 分配给所有管理器节点，并确认 DNS 配置准确无误，以便能够成功查找所有管理器节点的 FQDN。
2.或者，通过调用 NSX API：PUT /api/v1/configs/management，并在请求正文中将 publish_fqdns 设置为 False 来禁用 FQDN。此后，该集群中从传输节点进行的调用以及从联合节点到管理器节点的调用将仅使用 IP 地址。

管理器节点 IP 地址的反向 DNS 查找失败。

检测到事件时：“IP 地址为 {appliance_address} 并且已设置 publish_fqdns 标记的管理器节点 {entity_id} 的反向 DNS 查找失败。”

事件解决后：“IP 地址为 {appliance_address} 或已清除 publish_fqdns 标记的管理器节点 {entity_id} 的反向 DNS 查找成功。”

1.将正确的 FQDN 分配给所有管理器节点，并确认 DNS 配置准确无误，以便能够成功反向查找管理器节点的 IP 地址。
2.或者，通过调用 NSX API：PUT /api/v1/configs/management，并在请求正文中将 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}) 之间的平均网络延迟在 5 分钟内超过 150 毫秒。”

事件解决后：“管理器节点与主机 {transport_node_name} ({transport_node_address}) 之间的平均网络延迟正常。”

1.等待 5 分钟，以查看警报是否自动解决。
2.从管理器节点 ping NSX 传输节点。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}%。”

事件解决后：“传输节点 {entity_id} 上的 DFW CPU 使用率已达到 {system_resource_usage}%，该值低于极高阈值 {system_usage_threshold}%。”

请考虑将此主机上的虚拟机工作负载重新均衡到其他主机。请查看安全设计以进行优化。例如，如果规则不适用于整个数据中心，请使用“应用到”配置。

DPU 上的 DFW CPU 使用率非常高。

检测到事件时：“在 DPU {dpu_id} 上，传输节点 {entity_id} 上的 DFW CPU 使用率已达到 {system_resource_usage}%，该值等于或高于极高阈值 {system_usage_threshold}%。”

事件解决后：“在 DPU {dpu_id} 上，传输节点 {entity_id} 上的 DFW CPU 使用率已达到 {system_resource_usage}%，该值低于极高阈值 {system_usage_threshold}%。”

请考虑将此主机上的虚拟机工作负载重新均衡到其他主机。请查看安全设计以进行优化。例如，如果规则不适用于整个数据中心，请使用“应用到”配置。

DFW 内存使用率非常高。

检测到事件时：“传输节点 {entity_id} 上的 DFW 内存使用率 {heap_type} 已达到 {system_resource_usage}%，该值等于或高于极高阈值 {system_usage_threshold}%。”

事件解决后：“传输节点 {entity_id} 上的 DFW 内存使用率 {heap_type} 已达到 {system_resource_usage}%，该值低于极高阈值 {system_usage_threshold}%。”

通过在主机上调用 NSX CLI 命令 get firewall thresholds，查看当前的 DFW 内存使用率。请考虑将此主机上的工作负载重新均衡到其他主机。

DPU 上的 DFW 内存使用率非常高。

检测到事件时：“在 DPU {dpu_id} 上，传输节点 {entity_id} 上的 DFW 内存使用率 {heap_type} 已达到 {system_resource_usage}%，该值等于或高于极高阈值 {system_usage_threshold}%。”

事件解决后：“在 DPU {dpu_id} 上，传输节点 {entity_id} 上的 DFW 内存使用率 {heap_type} 已达到 {system_resource_usage}%，该值低于极高阈值 {system_usage_threshold}%。”

通过在 DPU 上调用 NSX CLI 命令 get firewall thresholds，查看当前的 DFW 内存使用率。请考虑将此主机上的工作负载重新均衡到其他主机。

DFW vMotion 失败，端口已断开连接。

检测到事件时：“目标主机 {transport_node_name} 上的 DFW 筛选器 {entity_id} 的 DFW vMotion 失败，并且实体的端口已断开连接。”

事件解决后：“目标主机 {transport_node_name} 上的 DFW 筛选器 {entity_id} 的 DFW 配置成功，并清除了 DFW vMotion 失败引起的错误。”

在 NSX Manager 中检查主机上的虚拟机，然后通过 NSX Manager UI 手动重新推送 DFW 配置。可以通过 DFW 筛选器 {entity_id} 跟踪要重新推送的 DFW 策略。还要考虑找到 DFW 筛选器连接到的虚拟机，然后重新启动该虚拟机。

DFW 泛洪限制已达到警告级别。

检测到事件时：“主机 {transport_node_name} 上 DFW 筛选器 {entity_id} 的 DFW 泛洪限制已达到警告级别，即达到为协议 {protocol_name} 配置的限制的 80%。”

事件解决后：“已在主机 {transport_node_name} 上为协议 {protocol_name} 清除了 DFW 筛选器 {entity_id} 的警告泛洪限制状态。”

在 NSX Manager 中检查主机上的虚拟机，检查为协议 {protocol_name} 配置的 DFW 筛选器 {entity_id} 的泛洪警告级别。

DFW 泛洪限制已达到严重级别。

检测到事件时：“主机 {transport_node_name} 上 DFW 筛选器 {entity_id} 的 DFW 泛洪限制已达到严重级别，即达到为协议 {protocol_name} 配置的限制的 98%。”

事件解决后：“已在主机 {transport_node_name} 上为协议 {protocol_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 策略禁用 NSX IDPS。2.已启用 NSX IDPS 引擎，NSX-IDPS 引擎和 vDPI 已启动，已启用 NSX IDPS，并且已通过 NSX 策略配置 IDPS 规则。”

1.检查 /var/log/nsx-syslog.log 以查看是否报告了错误。
2.调用 NSX CLI 命令 get ids engine status 以检查 NSX 分布式 IDPS 是否处于禁用状态。如果是，请调用 /etc/init.d/nsx-idps start 以启动该服务。
3.调用 /etc/init.d/nsx-vdpi status 以检查 nsx-vdpi 是否正在运行。如果未运行，请调用 /etc/init.d/nsx-vdpi start 以启动该服务。

在 DPU 上，NSX IDPS 已通过 NSX 策略启用，并且已配置 IDPS 规则，但 NSX-IDPS 引擎已关闭。

检测到事件时：“在 DPU {dpu_id} 上，NSX IDPS 已通过 NSX 策略启用，并且已配置 IDPS 规则，但 NSX-IDPS 引擎已关闭。”

事件解决后：“在 DPU {dpu_id} 上，NSX IDPS 处于以下任一情况。1.已通过 NSX 策略禁用 NSX IDPS。2.已启用 NSX IDPS 引擎，NSX-IDPS 引擎和 vDPI 已启动，已启用 NSX IDPS，并且已通过 NSX 策略配置 IDPS 规则。”

1.检查 /var/log/nsx-idps/nsx-idps.log 和 /var/log/nsx-syslog.log，以查看是否报告了错误。
2.调用 NSX CLI 命令 get ids engine status 以检查 NSX 分布式 IDPS 是否处于禁用状态。如果是，请调用 /etc/init.d/nsx-idps start 以启动该服务。
3.调用 /etc/init.d/nsx-vdpi status 以检查 nsx-vdpi 是否正在运行。如果未运行，请调用 /etc/init.d/nsx-vdpi start 以启动该服务。

分布式 IDPS 引擎的 CPU 占用率高。

检测到事件时：“分布式 IDPS 引擎的 CPU 占用率等于或高于高阈值 {system_usage_threshold}%。”

事件解决后：“分布式 IDPS 引擎的 CPU 占用率低于高阈值 {system_usage_threshold}%。”

查看超额订阅的原因。请将某些应用程序移至其他主机。

分布式 IDPS 引擎的 CPU 占用率非常高。

检测到事件时：“分布式 IDPS 引擎的 CPU 占用率等于或高于极高阈值 {system_usage_threshold}%。”

事件解决后：“分布式 IDPS 引擎的 CPU 占用率低于极高阈值 {system_usage_threshold}%。”

查看超额订阅的原因。请将某些应用程序移至其他主机。

分布式 IDPS 引擎的网络利用率高。

检测到事件时：“分布式 IDPS 引擎的网络利用率等于或高于高阈值 {system_usage_threshold}%。”

事件解决后：“分布式 IDPS 引擎的网络利用率低于高阈值 {system_usage_threshold}%。”

查看超额订阅的原因。请查看 IDPS 规则以减少受 IDPS 服务限制的流量。

分布式 IDPS 引擎的网络利用率非常高。

检测到事件时：“分布式 IDPS 引擎的网络利用率等于或高于极高阈值 {system_usage_threshold}%。”

事件解决后：“分布式 IDPS 引擎的网络利用率低于极高阈值 {system_usage_threshold}%。”

查看超额订阅的原因。请查看 IDPS 规则以减少受 IDPS 服务限制的流量。

由于 CPU 超额订阅，分布式 IDPS 引擎已丢弃流量。

检测到事件时：“IDPS 引擎的 CPU 资源不足，无法与入站流量保持同步，从而导致丢弃多余的流量。有关更多详细信息，请登录到 ESX 主机并发出以下命令: vsipioctl getdpiinfo -s，然后查看超额订阅统计信息。”

事件解决后：“分布式 IDPS 引擎具有足够的 CPU 资源，不会丢弃任何流量。”

查看超额订阅的原因。请将某些应用程序移至其他主机。

由于网络超额订阅，分布式 IDPS 引擎已丢弃流量。

检测到事件时：“IDPS 引擎无法与入站流量速率保持同步，从而导致丢弃多余的流量。有关更多详细信息，请登录到 ESX 主机并发出以下命令: vsipioctl getdpiinfo -s，然后查看超额订阅统计信息。”

事件解决后：“分布式 IDPS 引擎不会丢弃任何流量。”

查看超额订阅的原因。请查看 IDPS 规则以减少受 IDPS 服务限制的流量。

由于 CPU 超额订阅，分布式 IDPS 引擎已绕过流量。

检测到事件时：“IDPS 引擎的 CPU 资源不足，无法与入站流量保持同步，从而导致绕过多余的流量。有关更多详细信息，请登录到 ESX 主机并发出以下命令: vsipioctl getdpiinfo -s，然后查看超额订阅统计信息。”

事件解决后：“分布式 IDPS 引擎具有足够的 CPU 资源，不会绕过任何流量。”

查看超额订阅的原因。请将某些应用程序移至其他主机。

由于网络超额订阅，分布式 IDPS 引擎已绕过流量。

检测到事件时：“IDPS 引擎无法与入站流量速率保持同步，从而导致绕过多余的流量。有关更多详细信息，请登录到 ESX 主机并发出以下命令: vsipioctl getdpiinfo -s，然后查看超额订阅统计信息。”

事件解决后：“分布式 IDPS 引擎不会绕过任何流量。”

查看超额订阅的原因。请查看 IDPS 规则以减少受 IDPS 服务限制的流量。

DNS 转发器已关闭。

检测到事件时：“DNS 转发器 {entity_id} 未运行。这会影响当前已启用的已标识 DNS 转发器。”

事件解决后：“DNS 转发器 {entity_id} 再次运行。”

1.调用 NSX CLI 命令 get dns-forwarders status 以验证 DNS 转发器是否处于关闭状态。
2.检查 /var/log/syslog 以查看是否报告了任何错误。
3.收集支持包并联系 NSX 技术支持团队。

DNS 转发器已禁用。

检测到事件时：“DNS 转发器 {entity_id} 处于禁用状态。”

事件解决后：“DNS 转发器 {entity_id} 处于启用状态。”

1.调用 NSX CLI 命令 get dns-forwarders status 以验证 DNS 转发器是否处于已禁用状态。
2.使用 NSX 策略 API 或管理器 API 来启用 DNS 转发器，因为它不应处于已禁用状态。

一个 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 位置不匹配。

检测到事件时：“已使用 vMotion 移动 Edge 节点 {entity_id}。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 中不存在。

检测到事件时：“与 Edge 传输节点 {entity_id} vSphere 放置参数对应的 MoRef ID 为 {vm_moref_id} 的虚拟机 {policy_edge_vm_name} 可在 NSX 清单中找到，但在 vCenter 中不存在。请检查该虚拟机是否已在 vCenter 中被移除，或者是否具有其他虚拟机 MoRef ID。”

事件解决后：“虚拟机 MoRef ID 为 {vm_moref_id} 的 Edge 节点 {entity_id} 在 NSX 清单和 vCenter 中均存在。”

虚拟机的受管对象引用 MoRef ID 采用格式 vm-number，在 vCenter UI 中选择 Edge 虚拟机时，它会显示在 URL 中。例如，https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary 中的 vm-12011。对于此 Edge 传输节点 {entity_id}，请在 vCenter 中查找 MoRef ID 为 {vm_moref_id} 的虚拟机 {policy_edge_vm_name}。如果 Edge 虚拟机存在于 vCenter 中但具有其他 MoRef ID，请执行下面的操作。使用 NSX 添加或更新具有 JSON 请求工作负载属性 vm_id 和 vm_deployment_config 的放置 API，以更新该新虚拟机 MoRef ID 和 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 ID 为 {vm_moref_id} 的虚拟机 {policy_edge_vm_name}。此 Edge 传输节点 {entity_id} 的 vSphere 配置中的放置参数引用 MoRef 为 {vm_moref_id} 的虚拟机。”

事件解决后：“虚拟机 MoRef ID 为 {vm_moref_id} 的 Edge 节点 {entity_id} 在 NSX 清单和 vCenter 中均存在。”

虚拟机的受管对象引用 MoRef ID 采用格式 vm-number，在 vCenter UI 中选择 Edge 虚拟机时，它会显示在 URL 中。例如，https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary 中的 vm-12011。对于此 Edge 传输节点 {entity_id}，请在 vCenter 中查找 MoRef ID 为 {vm_moref_id} 的虚拟机 {policy_edge_vm_name}。请执行下面的操作解决警报 - 请检查该虚拟机是否已在 vSphere 中被删除，或者是否具有其他 MoRef ID。
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 ID 为 {vm_moref_id} 的 Edge 节点 {entity_id} 虚拟机的电源并将其删除。已部署 MoRef ID 为 {new_vm_moref_id} 的新 Edge 虚拟机。该 Edge 的旧虚拟机和新虚拟机在同时运行，可能会导致 IP 冲突和网络连接问题。”

事件解决后：“在 NSX 清单和 vCenter 中均无法再找到虚拟机 MoRef ID {vm_moref_id} 失效的 Edge 节点 {entity_id}。MoRef ID 为 {new_vm_moref_id} 的新部署虚拟机在 NSX 清单和 vCenter 中均存在。”

虚拟机的受管对象引用 MoRef ID 采用格式 vm-number，在 vCenter UI 中选择 Edge 虚拟机时，它会显示在 URL 中。例如，https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary 中的 vm-12011。对于此 Edge 传输节点 {entity_id}，请在 vCenter 中查找 MoRef ID 为 {vm_moref_id} 的虚拟机 {policy_edge_vm_name}。请关闭 vCenter 中 MoRef ID 为 {vm_moref_id} 的旧 Edge 虚拟机 {policy_edge_vm_name} 的电源并将其删除。

Edge 节点的硬件版本不匹配。

检测到事件时：“Edge 集群 {edge_cluster_name} 中的 Edge 节点 {transport_node_name} 具有硬件版本 {edge_tn_hw_version}，该版本低于 Edge 集群中的最高硬件版本 {edge_cluster_highest_hw_version}。”

事件解决后：“Edge 节点 {transport_node_name} 硬件版本不匹配问题现已解决。”

请按照知识库文章中的说明，解决 Edge 节点 {transport_node_name} 的硬件版本不匹配警报。

Edge 集群成员切换失败警报

检测到事件时：“在 Edge 集群 {edge_cluster_id} 上为传输节点 ID 为 {transport_node_id} 的 Edge 集群成员索引 {member_index_id} 切换所有服务上下文的操作失败”

事件解决后：“现已解决存在 {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}%，该值等于或高于极高阈值至少两分钟。”

事件解决后：“Edge 节点 {entity_id} 上的 CPU 使用率已达到极高阈值以下。”

通过调用 NSX CLI 命令 get dataplane cpu stats 来查看 Edge 节点上的 CPU 统计信息，以便了解每个 CPU 内核的数据包速率。数据包速率越高，CPU 使用率就越高。请考虑调高 Edge 设备的规格，并将此 Edge 节点上的服务重新均衡到同一集群或其他 Edge 集群中的其他 Edge 节点。

Edge 节点数据路径 CPU 使用率高。

检测到事件时：“Edge 节点 {entity_id} 上的数据路径 CPU 使用率已达到 {datapath_resource_usage}%，该值等于或高于高阈值至少两分钟。”

事件解决后：“Edge 节点 {entity_id} 上的 CPU 使用率已达到高阈值以下。”

通过调用 NSX CLI 命令 get dataplane cpu stats 来查看 Edge 节点上的 CPU 统计信息，以便了解每个 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 节点数据路径 Mempool 使用率高。

检测到事件时：“Edge 节点 {entity_id} 上的 {mempool_name} 的数据路径 mempool 使用率已达到 {system_resource_usage}%，该值等于或高于高阈值 {system_usage_threshold}%。”

事件解决后：“Edge 节点 {entity_id} 上的 {mempool_name} 的数据路径 mempool 使用率已达到 {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}%，该值高于高阈值超过两分钟。”

事件解决后：“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 节点网卡暂时出现接收环缓冲区不足问题。

检测到事件时：“Edge 网卡 {edge_nic_name} 接收环缓冲区在 Edge 节点 {entity_id} 上已溢出 {rx_ring_buffer_overflow_percentage}%。丢失的数据包计数为 {rx_misses}，已处理的数据包计数为 {rx_processed}。”

事件解决后：“Edge 节点 {entity_id} 上的 Edge 网卡 {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，如果 pps 在警报处于活动状态期间不高，请与 VMware 技术支持团队联系。如果 pps 较高，则说明存在突发流量。请考虑禁止警报。注意 - 没有特定的基准以判定 pps 值要达到多少才算高。这取决于基础架构和流量类型。可以记下警报处于非活动状态和活动状态的时间以进行对比。

Edge 节点网卡暂时出现发送环缓冲区不足问题。

检测到事件时：“Edge 网卡 {edge_nic_name} 发送环缓冲区在 Edge 节点 {entity_id} 上已溢出 {tx_ring_buffer_overflow_percentage}%。丢失的数据包计数为 {tx_misses}，已处理的数据包计数为 {tx_processed}。”

事件解决后：“Edge 节点 {entity_id} 上的 Edge 网卡 {edge_nic_name} 发送环缓冲区使用率不再为‘溢出’状态。”

1.如果除了 Edge 虚拟机之外，Hypervisor 还同时容纳了大量虚拟机，则可能没有时间来运行 Edge，为此，Hypervisor 可能不会检索任何数据包。在这种情况下，可以将 Edge 虚拟机迁移到具有较少虚拟机的主机。
2.使用命令“set dataplane ring-size tx”将环大小增加到 1024 倍 。如果在增加环大小后，问题仍然存在，请联系 VMware 技术支持团队，因为 ESX 端发送环缓冲区的值可能比较低。如果 ESX 端不存在任何问题，则表明需要增大 Edge 的部署规格以容纳容量。
3.如果警报一直抖动，即触发之后很快解决，这是由突发流量所致。在这种情况下，请使用命令 get dataplane cpu stats 检查 tx pps。如果 tx pps 在警报处于活动状态期间不高，请联系 VMware 技术支持团队。如果 pps 较高，则说明存在突发流量。请考虑禁止警报。注意 - 没有特定的基准以判定 pps 值要达到多少才算高。这取决于基础架构和流量类型。可以记下警报处于非活动状态和活动状态的时间以进行对比。

Edge 节点网卡链路已关闭。

检测到事件时：“Edge 节点网卡 {edge_nic_name} 链路已关闭。”

事件解决后：“Edge 节点网卡 {edge_nic_name} 链路已启动。”

在 Edge 节点上，通过调用 NSX CLI 命令 get interfaces 来确认网卡链路是否已用物理方式关闭。如果已关闭，请验证电缆连接。

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 节点数据路径网卡吞吐量非常高。

检测到事件时：“Edge 节点 {entity_id} 上的 {edge_nic_name} 的数据路径网卡吞吐量已达到 {nic_throughput}%，该值等于或高于极高阈值 {nic_throughput_threshold}%。”

事件解决后：“Edge 节点 {entity_id} 上的 {edge_nic_name} 的数据路径网卡吞吐量已达到 {nic_throughput}%，该值低于极高阈值 {nic_throughput_threshold}%。”

检查网卡上的流量吞吐量水平，并确定是否需要更改配置。可以使用“get dataplane thoughput &ltseconds&gt”命令以监控吞吐量。

Edge 节点数据路径网卡吞吐量较高。

检测到事件时：“Edge 节点 {entity_id} 上的 {edge_nic_name} 的数据路径网卡吞吐量已达到 {nic_throughput}%，该值等于或高于高阈值 {nic_throughput_threshold}%。”

事件解决后：“Edge 节点 {entity_id} 上的 {edge_nic_name} 的数据路径网卡吞吐量已达到 {nic_throughput}%，该值低于高阈值 {nic_throughput_threshold}%。”

检查网卡上的流量吞吐量水平，并确定是否需要更改配置。可以使用“get dataplane thoughput &ltseconds&gt”命令以监控吞吐量。

故障域的所有成员已关闭。

检测到事件时：“故障域 {transport_node_id} 的所有成员已关闭。”

事件解决后：“可以访问故障域 {transport_node_id} 的所有成员。”

1.在由 {transport_node_id} 标识的 Edge 节点上，调用 NSX CLI 命令 get managers 和 get controllers 以检查到管理平面和控制平面的连接。
2.调用 NSX CLI 命令 get interface eth0 以检查管理接口状态。
3.调用 CLI get services 以检查核心服务状态，例如 dataplane/local-controller/nestdb/router 等。
4.检查 /var/log/syslog 以查找可疑的错误。
5.重新引导 Edge 节点。

Micro 流量缓存命中率降低，数据路径 CPU 较高。

检测到事件时：“Edge 节点 {entity_id} 上的 Micro 流量缓存命中率已降至内核 {core_id} 的指定阈值 {flow_cache_threshold}% 以下，并且数据路径 CPU 使用量在过去 30 分钟内有所增长。”

事件解决后：“流量缓存命中率在正常范围内。”

流量缓存命中率在过去 30 分钟内有所减少，这表明 Edge 性能可能会下降。流量将继续转发，您可能不会遇到任何问题。请检查 Edge {entity_id} 内核 {core_id} 的数据路径 CPU 占用率是否在过去 30 分钟内较高。在连续创建新流量时，Edge 的流量缓存命中率将较低，因为将使用任何新流量的第一个数据包来设置流量缓存以便快速处理路径。您可能需要增加 Edge 设备大小或增加用于活动/活动网关的 Edge 节点数。

Mega 流量缓存命中率降低，数据路径 CPU 较高。

检测到事件时：“Edge 节点 {entity_id} 上的 Mega 流量缓存命中率已降至内核 {core_id} 的指定阈值 {flow_cache_threshold}% 以下，并且数据路径 CPU 使用量在过去 30 分钟内有所增长。”

事件解决后：“流量缓存命中率在正常范围内。”

流量缓存命中率在过去 30 分钟内有所减少，这表明 Edge 性能可能会下降。流量将继续转发，您可能不会遇到任何问题。请检查 Edge {entity_id} 内核 {core_id} 的数据路径 CPU 占用率是否在过去 30 分钟内较高。在连续创建新流量时，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，并检查是否为名为 remote-tunnel-endpoint 的接口分配了正确的 RTEP IP 地址。
6.检查是否在分配的 RTEP IP 地址（{bgp_source_ip}）与远程位置 {remote_site_name} 邻居 IP {bgp_neighbor_ip} 之间成功执行 ping 操作。
7.检查 /var/log/syslog，以确认是否存在与 BGP 相关的任何错误。
8.调用 NSX API GET 或 PUT /api/v1/transport-nodes/&lttransport-node-id&gt 以获取/更新 Edge 节点上的 remote_tunnel_endpoint 配置。这将更新分配给受影响的 Edge 节点的 RTEP IP。如果原因指示“Edge 未就绪”(Edge 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，并检查是否为名为 remote-tunnel-endpoint 的接口分配了正确的 RTEP IP 地址。
6.检查在分配的 RTEP IP 地址和远程位置 {remote_site_name} 的 RTEP IP 地址之间的 ping 操作是否成功。
7.检查 /var/log/syslog，以确认是否存在与 BGP 相关的任何错误。
8.调用 NSX API GET 或 PUT /api/v1/transport-nodes/&lttransport-node-id&gt 以获取/更新 Edge 节点上的 remote_tunnel_endpoint 配置。这会更新分配给受影响的 Edge 节点 {transport_node_name} 的 RTEP IP。

多个全局管理器节点同时处于活动状态。

检测到事件时：“多个全局管理器节点处于活动状态: {active_global_managers}。在任何时候，只能有一个全局管理器节点处于活动状态。”

事件解决后：“现在，全局管理器节点 {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) 之间的数据同步失败。

检测到事件时：“{flow_identifier} 的站点 {site_name}({site_id}) 和 {remote_site_name}({remote_site_id}) 之间的数据同步失败。原因: {sync_issue_reason}”

事件解决后：“{flow_identifier} 的站点 {site_name}({site_id}) 和 {remote_site_name}({remote_site_id}) 现已同步。”

1.通过 ping 检查远程站点和本地站点之间的网络连接。
2.确保在本地站点和远程站点之间允许端口 TCP/1236 流量。
3.确保同时在本地站点和远程站点上运行 async-replicator 服务。调用 NSX API：GET /api/v1/node/services/async_replicator/status 或 get service async_replicator NSX CLI 命令以确定该服务是否正在运行。如果未运行，请调用 NSX API：POST /api/v1/node/services/async_replicator?action=restart 或 restart service async_replicator NSX CLI 以重新启动该服务。
4.检查 /var/log/async-replicator/ar.log 以查看是否报告了错误。

全局管理器 (GM) 和本地管理器 (LM) 之间的数据同步长时间失败。

检测到事件时：“{flow_identifier} 的站点 {site_name}({site_id}) 和 {remote_site_name}({remote_site_id}) 之间的数据同步长时间失败。原因: {sync_issue_reason}。”

事件解决后：“{flow_identifier} 的站点 {site_name}({site_id}) 和 {remote_site_name}({remote_site_id}) 现已同步。”

1.通过 ping 检查远程站点和本地站点之间的网络连接。
2.确保在本地站点和远程站点之间允许端口 TCP/1236 流量。
3.确保同时在本地站点和远程站点上运行 async-replicator 服务。调用 NSX API：GET /api/v1/node/services/async_replicator/status 或 get service async_replicator NSX CLI 命令以确定该服务是否正在运行。如果未运行，请调用 NSX API：POST /api/v1/node/services/async_replicator?action=restart 或 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} 拆分为多个较小的组，并将容量过大组的成员分配给这些组。

Tier-0 网关已进行故障切换。

检测到事件时：“Tier-0 网关 {entity_id} 从 {previous_gateway_state} 故障切换到 {current_gateway_state}，服务路由器为 {service_router_id}”

事件解决后：“Tier-0 网关 {entity_id} 现在已启动。”

调用 NSX CLI 命令 get logical-router &ltservice_router_id&gt 来确定 Tier-0 服务路由器 VRF ID。通过调用 vrf &ltvrf-id&gt 来切换到 VRF 上下文，然后调用 get high-availability status 来确定已关闭的服务。

Tier-1 网关已进行故障切换。

检测到事件时：“Tier-1 网关 {entity_id} 从 {previous_gateway_state} 故障切换到 {current_gateway_state}，服务路由器为 {service_router_id}”

事件解决后：“Tier-1 网关 {entity_id} 现在已启动。”

调用 NSX CLI 命令 get logical-router &ltservice_router_id&gt 来确定 Tier-1 服务路由器 VRF ID。通过调用 vrf &ltvrf-id&gt 来切换到 VRF 上下文，然后调用 get high-availability status 来确定已关闭的服务。

服务组没有活动实例。

检测到事件时：“服务组集群 {entity_id} 当前没有活动实例。它在 Edge 节点 {transport_node_id} 上处于 {ha_state} 状态 (其中 0 表示‘关闭’，1 表示‘备用’，2 表示‘活动’)，在 Edge 节点 {transport_node_id2} 上处于 {ha_state2} 状态。”

事件解决后：“Tier-0 服务组集群 {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} 状态。”

事件解决后：“Tier-1 服务组集群 {entity_id} 此时在 Edge 节点 {transport_node_id} 上有一个活动实例。”

调用 NSX CLI 命令 get logical-router &ltservice_router_id&gt service_group，以检查在给定服务路由器下配置的所有服务组。检查输出以了解服务组退出活动状态的原因。

服务组中的备用实例发生故障。

检测到事件时：“Edge 节点 {transport_node_id} 上连接到 Tier-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} 上连接到 Tier-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.可以从 NSX 节点中访问 LDAP 服务器。
2.在 NSX 中正确配置了 LDAP 服务器详细信息。
3.LDAP 服务器正常运行。
4.防火墙没有阻止 LDAP 服务器和 NSX 节点之间的访问。解决问题后，请使用 NSX UI 中“身份防火墙 AD”下的“测试连接”来测试连接。

执行增量同步时出错。

检测到事件时：“执行与 {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} 不可用，请使用 root 特权调用 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 技术支持团队进行问题故障排除至关重要，建议最好先保存包含核心转储文件的技术支持包的最新副本，然后再从系统中移除核心转储文件。有关更多详细信息，请参阅知识库文章。

传输节点已与其 Intelligence 节点的消息代理断开连接。数据收集将受到影响。

检测到事件时：“传输节点 {entity_id} 上的流量导出程序已与 Intelligence 节点的消息代理断开连接。数据收集将受到影响。”

事件解决后：“传输节点 {entity_id} 上的流量导出程序已重新连接到 Intelligence 节点的消息代理。”

如果消息传递服务未在 Intelligence 节点中运行，请重新启动该服务。解决传输节点流量导出程序与 Intelligence 节点之间的网络连接故障。

Intelligence 节点 CPU 使用率非常高。

检测到事件时：“Intelligence 节点 {intelligence_node_id} 上的 CPU 使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“Intelligence 节点 {intelligence_node_id} 上的 CPU 使用率低于极高阈值 {system_usage_threshold}%。”

使用 top 命令检查哪些进程的 CPU 使用率最高，然后检查 /var/log/syslog 和这些进程的本地日志，以查看是否存在任何有待解决的错误。

Intelligence 节点 CPU 使用率高。

检测到事件时：“Intelligence 节点 {intelligence_node_id} 上的 CPU 使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“Intelligence 节点 {intelligence_node_id} 上的 CPU 使用率低于高阈值 {system_usage_threshold}%。”

使用 top 命令检查哪些进程的 CPU 使用率最高，然后检查 /var/log/syslog 和这些进程的本地日志，以查看是否存在任何有待解决的错误。

Intelligence 节点内存使用率非常高。

检测到事件时：“Intelligence 节点 {intelligence_node_id} 上的内存使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“Intelligence 节点 {intelligence_node_id} 上的内存使用率低于极高阈值 {system_usage_threshold}%。”

使用 top 命令检查哪些进程的内存使用率最高，然后检查 /var/log/syslog 和这些进程的本地日志，以查看是否存在任何有待解决的错误。

Intelligence 节点内存使用率高。

检测到事件时：“Intelligence 节点 {intelligence_node_id} 上的内存使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“Intelligence 节点 {intelligence_node_id} 上的内存使用率低于高阈值 {system_usage_threshold}%。”

使用 top 命令检查哪些进程的内存使用率最高，然后检查 /var/log/syslog 和这些进程的本地日志，以查看是否存在任何有待解决的错误。

Intelligence 节点磁盘使用率非常高。

检测到事件时：“Intelligence 节点 {intelligence_node_id} 上磁盘分区 {disk_partition_name} 的磁盘使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“Intelligence 节点 {intelligence_node_id} 上磁盘分区 {disk_partition_name} 的磁盘使用率低于极高阈值 {system_usage_threshold}%。”

检查磁盘分区{disk_partition_name}，查看是否有任何不需要的大文件可以移除。

Intelligence 节点磁盘使用率高。

检测到事件时：“Intelligence 节点 {intelligence_node_id} 上磁盘分区 {disk_partition_name} 的磁盘使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“Intelligence 节点 {intelligence_node_id} 上磁盘分区 {disk_partition_name} 的磁盘使用率低于高阈值 {system_usage_threshold}%。”

检查磁盘分区{disk_partition_name}，查看是否有任何不需要的大文件可以移除。

Intelligence 节点数据磁盘分区使用率非常高。

检测到事件时：“Intelligence 节点 {intelligence_node_id} 上磁盘分区 /data 的磁盘使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“Intelligence 节点 {intelligence_node_id} 上磁盘分区 /data 的磁盘使用率低于极高阈值 {system_usage_threshold}%。”

停止 NSX Intelligence 数据收集，直到磁盘使用率低于阈值为止。在 NSX UI 中，导航到“系统”|“设备”|“NSX Intelligence 设备”，然后单击“操作”并选择“停止收集数据”。

Intelligence 节点数据磁盘分区使用率高。

检测到事件时：“Intelligence 节点 {intelligence_node_id} 上磁盘分区 /data 的磁盘使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“Intelligence 节点 {intelligence_node_id} 上磁盘分区 /data 的磁盘使用率低于高阈值 {system_usage_threshold}%。”

停止 NSX Intelligence 数据收集，直到磁盘使用率低于阈值为止。检查磁盘分区 /data，查看是否有任何不需要的大文件可以移除。

Intelligence 节点存储延迟高。

检测到事件时：“Intelligence 节点 {intelligence_node_id} 上磁盘分区 {disk_partition_name} 的存储延迟高于高阈值 {system_usage_threshold} 毫秒。”

事件解决后：“Intelligence 节点 {intelligence_node_id} 上磁盘分区 {disk_partition_name} 的存储延迟低于高阈值 {system_usage_threshold} 毫秒。”

由于 I/O 请求数量达到峰值，可能会发生短暂的高存储延迟。如果存储延迟保持较高状态超过 30 分钟，请考虑在低延迟磁盘中部署 NSX Intelligence 设备，或者不要与其他虚拟机共享同一存储设备。

Intelligence 节点状态为已降级。

检测到事件时：“Intelligence 节点 {intelligence_node_id} 已降级。”

事件解决后：“Intelligence 节点 {intelligence_node_id} 正常运行。”

调用 NSX API：GET /napp/api/v1/platform/monitor/category/health 以检查哪个特定 Pod 已关闭及其背后的原因。调用以下 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，并且以后也不会使用，请删除子网或 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 池/子网。

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-State 是 not_ready 或没有输出，请将 Edge 节点置于维护模式，然后再退出维护模式。对于分布式负载均衡器：
1.调用 NSX API：GET /policy/api/v1/infra/lb-services/&ltLBService&gt/detailed-status?source=realtime 以获取详细状态。
2.从 API 输出中，找到报告非零 instance_number 以及 NOT_READY 或 CONFLICT 状态的 ESXi 主机。
3.在 ESXi 主机节点上，调用 NSX CLI 命令“get load-balancer &ltlb-uuid&gt status”。如果报告“冲突 LSP”(Conflict LSP)，请检查该 LSP 是否连接到其他负载均衡器服务。请检查该冲突是否可以接受。如果报告“未就绪 LSP”(Not Ready LSP)，请调用 NSX CLI 命令 get logical-switch-port status 以检查该 LSP 的状态。注意：如果警报可以在 5 分钟内自动解决，请将其忽略，因为降级状态可能是暂时性状态。

分布式负载均衡器服务已关闭。

检测到事件时：“分布式负载均衡器服务 {entity_id} 已关闭。”

事件解决后：“分布式负载均衡器服务 {entity_id} 已启动。”

在 ESXi 主机节点上，调用 NSX CLI 命令“get load-balancer &ltlb-uuid&gt status”。如果报告“冲突 LSP”(Conflict LSP)，请检查该 LSP 是否连接到其他负载均衡器服务。请检查该冲突是否可以接受。如果报告“未就绪 LSP”(Not Ready LSP)，请调用 NSX CLI 命令 get logical-switch-port status 以检查该 LSP 的状态。

集中式负载均衡器服务已关闭。

检测到事件时：“集中式负载均衡器服务 {entity_id} 已关闭。”

事件解决后：“集中式负载均衡器服务 {entity_id} 已启动。”

在活动 Edge 节点上，调用 NSX CLI 命令 get load-balancer &ltlb-uuid&gt status 以检查负载均衡器状态。如果负载均衡器服务的 LB-State 是 not_ready 或没有输出，请将 Edge 节点置于维护模式，然后再退出维护模式。

负载均衡器虚拟服务已关闭。

检测到事件时：“负载均衡器虚拟服务器 {entity_id} 已关闭。”

事件解决后：“负载均衡器虚拟服务器 {entity_id} 已启动。”

查看负载均衡器池以确定其状态并验证其配置。如果配置不正确，请重新配置，并从虚拟服务器中移除负载均衡器池，然后再次将其重新添加到虚拟服务器。

负载均衡器池已关闭。

检测到事件时：“负载均衡器池 {entity_id} 状态为已关闭。”

事件解决后：“负载均衡器池 {entity_id} 状态为已启动。

通过调用 NSX CLI 命令 get load-balancer &ltlb-uuid&gt pool &ltpool-uuid&gt status 或 NSX API：GET /policy/api/v1/infra/lb-services/&ltlb-service-id&gt/lb-pools/&ltlb-pool-id&gt/detailed-status，查询负载均衡器池以确定哪些成员处于关闭状态。如果报告的状态为“关闭”或“未知”，请验证池成员。检查负载均衡器与受影响的池成员的网络连接。验证每个池成员的应用程序运行状况。此外，还可以使用已配置的监控器来验证每个池成员的运行状况。建立成员的运行状况后，池成员状态将根据监控器中的“成功检查计数”配置更新为正常。通过重新引导池成员或使 Edge 节点进入维护模式，然后退出维护模式来修复此问题。

负载均衡器使用率较高。

检测到事件时：“Edge 节点 {entity_id} 中的负载均衡器服务的使用率高。阈值为 {system_usage_threshold}%。”

事件解决后：“Edge 节点 {entity_id} 中的负载均衡器服务的使用率足够低。阈值为 {system_usage_threshold}%。”

如果在此 Edge 节点中配置了多个 LB 实例，请部署新的 Edge 节点，并将一些 LB 实例移到该新的 Edge 节点。如果在相同大小（小型/中型/等）的 Edge 节点中仅配置了单个 LB 实例（小型/中型/等），请部署一个更大的新 Edge，并将 LB 实例移到该新的 Edge 节点。

负载均衡器池成员使用率非常高。

检测到事件时：“Edge 节点 {entity_id} 中的池成员的使用率非常高。阈值为 {system_usage_threshold}%。”

事件解决后：“Edge 节点 {entity_id} 中的池成员的使用率足够低。阈值为 {system_usage_threshold}%。”

部署新的 Edge 节点，并将负载均衡器服务从现有 Edge 节点移动到新部署的 Edge 节点。

由于 Edge 节点上的内存使用率高，未实现负载均衡器配置。

检测到事件时：“由于 Edge 节点 {transport_node_id} 上的内存使用率高，未实现负载均衡器配置 {entity_id}。”

事件解决后：“负载均衡器配置 {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 以查找任何可疑错误。

服务状态为“已降级”。

检测到事件时：“{transport_node_name} 上的服务 {mps_service_name} 已降级。无法与文件提取功能进行通信。{transport_node_name} 上的所有文件提取功能都已暂停。”

事件解决后：“服务 {mps_service_name} 在 {transport_node_name} 上正常运行。”

1.在 {nsx_edge_tn_name} 标识的 Edge 节点上，调用 NSX CLI get ids engine status 以检查 file_extraction (IDS) 服务的状态。检查 /var/log/syslog 以查找包含文件提取 (IDS) 服务和/或 {mps_service_name} 的任何可疑错误。
2.在 {nsx_esx_tn_name} 标识的主机节点上，登录到关联的恶意软件防护服务虚拟机 {entity_id}，并检查文件提取 (NXGI) 服务的状态。在关联的恶意软件防护服务虚拟机 {entity_id} 上检查 /var/log/syslog 以查找任何可疑错误。

服务状态为“已降级”。

检测到事件时：“NSX Application Platform 上的服务 {mps_service_name} 已降级。无法与恶意软件防护数据库进行通信。”

事件解决后：“服务 {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}%。”

运行工具 /opt/vmware/tools/support/inspect_checkpoint_issues.py，如果报告任何问题，请联系 GSS

管理器节点配置磁盘使用率高。

检测到事件时：“管理器节点磁盘分区 /config 的磁盘使用率已达到 {system_resource_usage}%，该值等于或高于高阈值 {system_usage_threshold}%。这可能表明 NSX 数据存储服务在 /config/corfu 目录下的磁盘使用率正在上升。”

事件解决后：“管理器节点磁盘分区 /config 的磁盘使用率已达到 {system_resource_usage}%，该值低于高阈值 {system_usage_threshold}%。”

运行工具 /opt/vmware/tools/support/inspect_checkpoint_issues.py，如果报告任何问题，请联系 GSS

管理器节点 nonconfig 磁盘使用率非常高。

检测到事件时：“管理器节点磁盘分区 /nonconfig 的磁盘使用率已达到 {system_resource_usage}%，该值等于或高于极高阈值 {system_usage_threshold}%。这可能表明 NSX 数据存储服务在 /nonconfig/corfu 目录下的磁盘使用率高。”

事件解决后：“管理器节点磁盘分区 /nonconfig 的磁盘使用率已达到 {system_resource_usage}%，该值低于极高阈值 {system_usage_threshold}%。”

运行工具 /opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig，如果报告任何问题，请联系 GSS

管理器节点 nonconfig 磁盘使用率高。

检测到事件时：“管理器节点磁盘分区 /nonconfig 的磁盘使用率已达到 {system_resource_usage}%，该值等于或高于高阈值 {system_usage_threshold}%。这可能表明 NSX 数据存储服务在 /nonconfig/corfu 目录下的的磁盘使用率正在上升。”

事件解决后：“管理器节点磁盘分区 /nonconfig 的磁盘使用率已达到 {system_resource_usage}%，该值低于高阈值 {system_usage_threshold}%。”

运行工具 /opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig，如果报告任何问题，请联系 GSS

另一个设备正在使用管理器节点的 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 签名证书替换为自签名证书。

缺少管理器 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 上导航到“系统”|“Fabric”|“设置”|“MTU 配置检查”|“不一致”，以查看更多不匹配详细信息。
2.调用 NSX API：PUT /api/v1/host-switch-profiles/&lthost-switch-profile-id&gt 并在请求正文中包含 mtu，或者调用 API：PUT /api/v1/global-configs/SwitchingGlobalConfig 并在请求正文中包含 physical_uplink_mtu，以便在连接到同一传输区域的所有交换机上设置相同的 MTU 值。

全局路由器 MTU 配置大于覆盖网络传输区域的 MTU。

检测到事件时：“全局路由器 MTU 配置大于连接到 Tier-0 或 Tier-1 的覆盖网络传输区域中的交换机 MTU。全局路由器 MTU 值应至少比所有交换机 MTU 值小 100，因为我们需要 100 个配额进行 Geneve 封装。”

事件解决后：“全局路由器 MTU 现在小于覆盖网络传输区域的 MTU。”

1.在 NSX UI 上导航到“系统”|“Fabric”|“设置”|“MTU 配置检查”|“不一致”，以查看更多不匹配详细信息。
2.调用 NSX API：PUT /api/v1/host-switch-profiles/&lthost-switch-profile-id&gt 并在请求正文中包含 mtu，或者调用 API：PUT /api/v1/global-configs/SwitchingGlobalConfig 并在请求正文中包含 physical_uplink_mtu，以便在交换机上设置较大的 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 Pod 活跃性。然后调用 kubectl 命令 kubectl get pods --all-namespaces。如果 NCP Pod 存在问题，请使用 kubectl logs 命令来检查问题并修复错误。
2.检查 NCP 与 Kubernetes API 服务器之间的连接。可以在 NCP Pod 中使用 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 Pod 中使用 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 证书和 ingress 证书是否匹配。检查上述证书的过期日期以确保这些证书有效。检查 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 集群之间的网络连接故障。

传输节点已与其 Intelligence 节点的消息代理断开连接。DPU 上的数据收集将受到影响。

检测到事件时：“传输节点 {entity_id} DPU {dpu_id} 上的流量导出程序已与 Intelligence 节点的消息代理断开连接。数据收集将受到影响。”

事件解决后：“传输节点 {entity_id} DPU {dpu_id} 上的流量导出程序已重新连接到 Intelligence 节点的消息代理。”

如果消息传递服务未在 Intelligence 节点中运行，请重新启动该服务。解决传输节点流量导出程序与 Intelligence 节点之间的网络连接故障。

NSX Application Platform 集群 CPU 使用率非常高。

检测到事件时：“NSX Application Platform 集群 {napp_cluster_id} 的 CPU 使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“NSX Application Platform 集群 {napp_cluster_id} 的 CPU 使用率低于极高阈值 {system_usage_threshold}%。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“核心服务”，然后检查各个服务的“系统负载”字段以查看哪个服务的负载较高。查看是否可以减少负载。如果需要更多计算能力，请单击“横向扩展”按钮以请求更多资源。

NSX Application Platform 集群 CPU 使用率高。

检测到事件时：“NSX Application Platform 集群 {napp_cluster_id} 的 CPU 使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“NSX Application Platform 集群 {napp_cluster_id} 的 CPU 使用率低于高阈值 {system_usage_threshold}%。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“核心服务”，然后检查各个服务的“系统负载”字段以查看哪个服务的负载较高。查看是否可以减少负载。如果需要更多计算能力，请单击“横向扩展”按钮以请求更多资源。

NSX Application Platform 集群内存使用率非常高。

检测到事件时：“NSX Application Platform 集群 {napp_cluster_id} 的内存使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“NSX Application Platform 集群 {napp_cluster_id} 的内存使用率低于极高阈值 {system_usage_threshold}%。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“核心服务”，然后检查各个服务的“内存”字段以查看哪个服务的负载较高。查看是否可以减少负载。如果需要更多内存，请单击“横向扩展”按钮以请求更多资源。

NSX Application Platform 集群内存使用率高。

检测到事件时：“NSX Application Platform 集群 {napp_cluster_id} 的内存使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“NSX Application Platform 集群 {napp_cluster_id} 的内存使用率低于高阈值 {system_usage_threshold}%。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“核心服务”，然后检查各个服务的“内存”字段以查看哪个服务的负载较高。查看是否可以减少负载。如果需要更多内存，请单击“横向扩展”按钮以请求更多资源。

NSX Application Platform 集群磁盘使用率非常高。

检测到事件时：“NSX Application Platform 集群 {napp_cluster_id} 的磁盘使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“NSX Application Platform 集群 {napp_cluster_id} 的磁盘使用率低于极高阈值 {system_usage_threshold}%。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“核心服务”，然后检查各个服务的“存储”字段以查看哪个服务的负载较高。查看是否可以减少负载。如果需要更多磁盘存储，请单击“横向扩展”按钮以请求更多资源。如果数据存储服务的负载较高，另一种方法是单击“纵向扩展”按钮以增加磁盘大小。

NSX Application Platform 集群磁盘使用率高。

检测到事件时：“NSX Application Platform 集群 {napp_cluster_id} 的磁盘使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“NSX Application Platform 集群 {napp_cluster_id} 的磁盘使用率低于高阈值 {system_usage_threshold}%。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“核心服务”，然后检查各个服务的“存储”字段以查看哪个服务的负载较高。查看是否可以减少负载。如果需要更多磁盘存储，请单击“横向扩展”按钮以请求更多资源。如果数据存储服务的负载较高，另一种方法是单击“纵向扩展”按钮以增加磁盘大小。

NSX Application Platform 集群整体状态为“已降级”。

检测到事件时：“NSX Application Platform 集群 {napp_cluster_id} 整体状态为‘已降级’。”

事件解决后：“NSX Application Platform 集群 {napp_cluster_id} 正常运行。”

从节点和服务警报中获取更多信息。

NSX Application Platform 集群整体状态为“关闭”。

检测到事件时：“NSX Application Platform 集群 {napp_cluster_id} 整体状态为‘关闭’。”

事件解决后：“NSX Application Platform 集群 {napp_cluster_id} 正常运行。”

从节点和服务警报中获取更多信息。

NSX Application Platform 节点 CPU 使用率非常高。

检测到事件时：“NSX Application Platform 节点 {napp_node_name} 的 CPU 使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“NSX Application Platform 节点 {napp_node_name} 的 CPU 使用率低于极高阈值 {system_usage_threshold}%。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“核心服务”，然后检查各个服务的“系统负载”字段以查看哪个服务的负载较高。查看是否可以减少负载。如果只有一小部分节点具有较高的 CPU 使用率，默认情况下，Kubernetes 将自动重新计划服务。如果大多数节点具有较高的 CPU 使用率，并且无法减少负载，请单击“横向扩展”按钮以请求更多资源。

NSX Application Platform 节点 CPU 使用率高。

检测到事件时：“NSX Application Platform 节点 {napp_node_name} 的 CPU 使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“NSX Application Platform 节点 {napp_node_name} 的 CPU 使用率低于高阈值 {system_usage_threshold}%。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“核心服务”，然后检查各个服务的“系统负载”字段以查看哪个服务的负载较高。查看是否可以减少负载。如果只有一小部分节点具有较高的 CPU 使用率，默认情况下，Kubernetes 将自动重新计划服务。如果大多数节点具有较高的 CPU 使用率，并且无法减少负载，请单击“横向扩展”按钮以请求更多资源。

NSX Application Platform 节点内存使用率非常高。

检测到事件时：“NSX Application Platform 节点 {napp_node_name} 的内存使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“NSX Application Platform 节点 {napp_node_name} 的内存使用率低于极高阈值 {system_usage_threshold}%。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“核心服务”，然后检查各个服务的“内存”字段以查看哪个服务的负载较高。查看是否可以减少负载。如果只有一小部分节点具有较高的内存使用率，默认情况下，Kubernetes 将自动重新计划服务。如果大多数节点具有较高的内存使用率，并且无法减少负载，请单击“横向扩展”按钮以请求更多资源。

NSX Application Platform 节点内存使用率高。

检测到事件时：“NSX Application Platform 节点 {napp_node_name} 的内存使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“NSX Application Platform 节点 {napp_node_name} 的内存使用率低于高阈值 {system_usage_threshold}%。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“核心服务”，然后检查各个服务的“内存”字段以查看哪个服务的负载较高。查看是否可以减少负载。如果只有一小部分节点具有较高的内存使用率，默认情况下，Kubernetes 将自动重新计划服务。如果大多数节点具有较高的内存使用率，并且无法减少负载，请单击“横向扩展”按钮以请求更多资源。

NSX Application Platform 节点磁盘使用率非常高。

检测到事件时：“NSX Application Platform 节点 {napp_node_name} 的磁盘使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“NSX Application Platform 节点 {napp_node_name} 的磁盘使用率低于极高阈值 {system_usage_threshold}%。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“核心服务”，然后检查各个服务的“存储”字段以查看哪个服务的负载较高。清理未使用的数据或日志以释放磁盘资源，并查看是否可以减少负载。如果需要更多磁盘存储，请横向扩展负载较高的服务。如果数据存储服务的负载较高，另一种方法是单击“纵向扩展”按钮以增加磁盘大小。

NSX Application Platform 节点磁盘使用率高。

检测到事件时：“NSX Application Platform 节点 {napp_node_name} 的磁盘使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“NSX Application Platform 节点 {napp_node_name} 的磁盘使用率低于高阈值 {system_usage_threshold}%。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“核心服务”，然后检查各个服务的“存储”字段以查看哪个服务的负载较高。清理未使用的数据或日志以释放磁盘资源，并查看是否可以减少负载。如果需要更多磁盘存储，请横向扩展负载较高的服务。如果数据存储服务的负载较高，另一种方法是单击“纵向扩展”按钮以增加磁盘大小。

NSX Application Platform 节点状态为“已降级”。

检测到事件时：“NSX Application Platform 节点 {napp_node_name} 已降级。”

事件解决后：“NSX Application Platform 节点 {napp_node_name} 正常运行。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“资源”以检查哪个节点已降级。检查节点的网络、内存和 CPU 使用率。如果节点是工作节点，请重新引导该节点。

NSX Application Platform 节点状态为“关闭”。

检测到事件时：“NSX Application Platform 节点 {napp_node_name} 未运行。”

事件解决后：“NSX Application Platform 节点 {napp_node_name} 正常运行。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“资源”以检查哪个节点已关闭。检查节点的网络、内存和 CPU 使用率。如果节点是工作节点，请重新引导该节点。

数据存储服务 CPU 使用率非常高。

检测到事件时：“数据存储服务的 CPU 使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“数据存储服务的 CPU 使用率低于极高阈值 {system_usage_threshold}%。”

横向扩展所有服务或数据存储服务。

数据存储服务 CPU 使用率高。

检测到事件时：“数据存储服务的 CPU 使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“数据存储服务的 CPU 使用率低于高阈值 {system_usage_threshold}%。”

横向扩展所有服务或数据存储服务。

消息传递服务 CPU 使用率非常高。

检测到事件时：“消息传递服务的 CPU 使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“消息传递服务的 CPU 使用率低于极高阈值 {system_usage_threshold}%。”

横向扩展所有服务或消息传递服务。

消息传递服务 CPU 使用率高。

检测到事件时：“消息传递服务的 CPU 使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“消息传递服务的 CPU 使用率低于高阈值 {system_usage_threshold}%。”

横向扩展所有服务或消息传递服务。

配置数据库服务 CPU 使用率非常高。

检测到事件时：“配置数据库服务的 CPU 使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“配置数据库服务的 CPU 使用率低于极高阈值 {system_usage_threshold}%。”

横向扩展所有服务。

配置数据库服务 CPU 使用率高。

检测到事件时：“配置数据库服务的 CPU 使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“配置数据库服务的 CPU 使用率低于高阈值 {system_usage_threshold}%。”

横向扩展所有服务。

衡量指标服务 CPU 使用率非常高。

检测到事件时：“衡量指标服务的 CPU 使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“衡量指标服务的 CPU 使用率低于极高阈值 {system_usage_threshold}%。”

横向扩展所有服务。

衡量指标服务 CPU 使用率高。

检测到事件时：“衡量指标服务的 CPU 使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“衡量指标服务的 CPU 使用率低于高阈值 {system_usage_threshold}%。”

横向扩展所有服务。

分析服务 CPU 使用率非常高。

检测到事件时：“分析服务的 CPU 使用率高于极高阈值 {system_usage_threshold}%。”

事件解决后：“分析服务的 CPU 使用率低于极高阈值 {system_usage_threshold}%。”

横向扩展所有服务或分析服务。

分析服务 CPU 使用率高。

检测到事件时：“分析服务的 CPU 使用率高于高阈值 {system_usage_threshold}%。”

事件解决后：“分析服务的 CPU 使用率低于高阈值 {system_usage_threshold}%。”

横向扩展所有服务或分析服务。

平台服务 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} 关联的 Pod 并非都处于稳定状态，但该服务仍可能达到仲裁数。这些不稳定 Pod 所消耗的资源可能会被释放。”

事件解决后：“服务 {napp_service_name} 正常运行。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“核心服务”以检查哪个服务已降级。调用 NSX API：GET /napp/api/v1/platform/monitor/feature/health 以检查哪个特定服务已降级及其背后的原因。如有必要，调用以下 CLI 命令以重新启动已降级的服务：kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt。已降级的服务可以正常运行，但性能欠佳。

服务状态为“关闭”。

检测到事件时：“服务 {napp_service_name} 未运行。”

事件解决后：“服务 {napp_service_name} 正常运行。”

在 NSX UI 中，导航到“系统”|“NSX Application Platform”|“核心服务”以检查哪个服务已降级。调用 NSX API：GET /napp/api/v1/platform/monitor/feature/health 以检查哪个特定服务已关闭及其背后的原因。调用以下 CLI 命令以重新启动已降级的服务：kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt

服务已降级。

检测到事件时：“服务 {nsxaas_service_name} 已降级。在其当前状态下，服务可能正在以较低的效率运行，这可能会影响客户工作负载。{service_down_reason}”

事件解决后：“服务 {nsxaas_service_name} 不再处于已降级状态。”

查看标识服务的警报描述中包含的数据、服务的部署位置以及运行状况监控服务捕获的其他数据。此外，还要查看衡量指标服务或 Wavefront（如果适用）记录的历史数据。

服务已关闭。

检测到事件时：“服务 {nsxaas_service_name} 已关闭。{service_down_reason}”

事件解决后：“服务 {nsxaas_service_name} 再次可用。”

查看标识服务的警报描述中包含的数据、服务的部署位置以及运行状况监控服务捕获的其他数据。此外，还要查看衡量指标服务或 Wavefront（如果适用）记录的历史数据。

用户密码已过期。

检测到事件时：“用户 {username} 的密码已过期。”

事件解决后：“用户 {username} 的密码已成功更改或不再为已过期，或者用户不再处于活动状态。”

现在，必须更改用户 {username} 的密码才能访问系统。例如，要将新密码应用于用户，请在请求正文中使用有效密码调用以下 NSX API：PUT /api/v1/node/users/&ltuserid&gt，其中 &ltuserid&gt 是该用户的 ID。如果管理员用户（&ltuserid&gt 为 10000）的密码已过期，则管理员必须通过 SSH（如果已启用）或控制台登录到系统，才能更改密码。输入当前已过期的密码后，系统会提示 admin 输入新密码。

用户密码就要过期。

检测到事件时：“用户 {username} 的密码即将在 {password_expiration_days} 天内过期。”

事件解决后：“用户 {username} 的密码已成功更改或不再为已过期，或者用户不再处于活动状态。”

确保立即更改用户 {username} 的密码。例如，要将新密码应用于用户，请在请求正文中使用有效密码调用以下 NSX API：PUT /api/v1/node/users/&ltuserid&gt，其中 &ltuserid&gt 是该用户的 ID。

用户密码即将过期。

检测到事件时：“用户 {username} 的密码即将在 {password_expiration_days} 天内过期。”

事件解决后：“用户 {username} 的密码已成功更改或不再为已过期，或者用户不再处于活动状态。”

需要尽快更改用户 {username} 的密码。例如，要将新密码应用于用户，请在请求正文中使用有效密码调用以下 NSX API：PUT /api/v1/node/users/&ltuserid&gt，其中 &ltuserid&gt 是该用户的 ID。

物理服务器 (BMS) 安装失败。

检测到事件时：“物理服务器 {transport_node_name} ({entity_id}) 安装失败。”

事件解决后：“物理服务器 {transport_node_name} ({entity_id}) 安装已完成。”

导航到“系统”>“Fabric”>“节点”>“主机传输节点”，然后解决节点上的错误。

物理服务器 (BMS) 升级失败。

检测到事件时：“物理服务器 {transport_node_name} ({entity_id}) 升级失败。”

事件解决后：“物理服务器 {transport_node_name} ({entity_id}) 升级已完成。”

导航到“系统”>“升级”并解决错误，然后重新触发升级。

物理服务器 (BMS) 卸载失败。

检测到事件时：“物理服务器 {transport_node_name} ({entity_id}) 卸载失败。”

事件解决后：“物理服务器 {transport_node_name} ({entity_id}) 卸载已完成。”

导航到“系统”>“Fabric”>“节点”>“主机传输节点”，然后解决节点上的错误。

实体计数已达到策略限制。

检测到事件时：“{constraint_type_path} 中类型为 {constraint_type} 的实体计数当前为 {current_count}，已达到最大限制 {constraint_limit}。”

事件解决后：“{constraint_type} 计数低于阈值。”

查看 {constraint_type} 使用情况。请更新限制以提高限额或删除未使用的 {constraint_type}。

BFD 会话已关闭。

检测到事件时：“在路由器 {lr_id} 中，对等体 {peer_address} 的 BFD 会话已关闭。”

事件解决后：“在路由器 {lr_id} 中，对等体 {peer_address} 的 BFD 会话已启动。”

1.调用 NSX CLI 命令 get logical-routers。
2.切换到服务路由器 {sr_id}。
3.调用 NSX CLI 命令 ping {peer_address} 以验证连接。

已移除静态路由。

检测到事件时：“在路由器 {lr_id} 中，由于 BFD 已关闭，已移除静态路由 {entity_id} ({static_address})。”

事件解决后：“在路由器 {lr_id} 中，在 BFD 恢复时已重新添加静态路由 {entity_id} ({static_address})。”

因为 BFD 会话已关闭而移除了静态路由条目，因此请执行以下操作：
1.调用 NSX CLI 命令 get logical-routers。
2.切换到服务路由器 {sr_id}。
3.调用 NSX CLI 命令 ping &ltBFD peer IP address&gt 来验证连接。另外，请验证 NSX 和 BFD 对等体中的配置，以确保定时器未更改。

BGP 邻居已关闭。

检测到事件时：“在路由器 {lr_id} 中，BGP 邻居 {entity_id} ({bgp_neighbor_ip}) 已关闭。原因: {failure_reason}。”

事件解决后：“在路由器 {lr_id} 中，BGP 邻居 {entity_id} ({bgp_neighbor_ip}) 已启动。”

1.调用 NSX CLI 命令 get logical-routers。
2.切换到服务路由器 {sr_id}。如果原因指示网络错误或配置错误 -
3.调用 NSX CLI 命令 get bgp neighbor summary 以检查 BGP 邻居状态。如果原因指示“Edge 未就绪”(Edge 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 配置代理 ARP。

检测到事件时：“未配置服务 IP {service_ip} 和服务实体 {entity_id} 的代理 ARP，因为由于服务 IP 与路由器 {lr_id} 上的 lrport {lrport_id} 的子网重叠而生成的 ARP 代理条目数已超过允许的阈值限制 (16384 个)。”

事件解决后：“已成功生成服务实体 {entity_id} 的代理 ARP，因为服务 IP 与路由器 {lr_id} 上 lrport {lrport_id} 的子网之间的重叠在允许的限制 (16384 个条目) 内。”

重新配置服务实体 {entity_id} 的服务 IP {service_ip} 或更改路由器 {lr_id} 上的 lrport {lrport_id} 的子网，以使由于服务 IP 与 lrport 子网重叠而生成的代理 ARP 条目数少于允许的阈值限制（16384 个）。

所有 BGP/BFD 会话已关闭。

检测到事件时：“所有 BGP/BFD 会话已关闭。”

事件解决后：“至少有一个 BGP/BFD 会话已启动。”

调用 NSX CLI 命令 get logical-routers 以获取 Tier-0 服务路由器并切换到该 VRF，然后调用以下 NSX CLI 命令：
1. 调用 ping &ltBFD peer IP address&gt 以验证连接。
2. 调用 get bfd-config 和 get bfd-sessions 以检查 BFD 是否正常运行。
3. 调用 get bgp neighbor summary 以检查 BGP 是否正常运行。还要检查 /var/log/syslog 以确定是否存在与 BGP 连接相关的任何错误。

OSPF 邻居已从全邻接状态转变为其他状态。

检测到事件时：“OSPF 邻居 {peer_address} 已从全邻接状态转变为其他状态。”

事件解决后：“OSPF 邻居 {peer_address} 已转变为全邻接状态。”

1.调用 NSX CLI 命令 get logical-routers 以获取 VRF ID 并切换到 Tier-0 服务路由器。
2.运行 get ospf neighbor 以检查此邻居的当前状态。如果输出中未列出该邻居，则表明它已关闭或脱离了网络。
3.调用 NSX CLI 命令 ping &ltOSPF neighbor IP address&gt 来验证连接。
4.另外，请验证 NSX 和对等路由器的配置，以确保定时器和区域 ID 相匹配。
5.检查 /var/log/syslog 以查看是否存在与连接相关的任何错误。

在 Edge 节点上即将达到最大 IPv4 路由限制。

检测到事件时：“在 Tier-0 网关和 Edge 节点 {edge_node} 的所有 Tier-0 VRF 上，IPv4 路由数已达到限制 {route_limit_threshold}。”

事件解决后：“在 Tier-0 网关和 Edge 节点 {edge_node} 的所有 Tier-0 VRF 上，IPv4 路由数在限制 {route_limit_threshold} 内。”

1.检查路由重新分发策略以及从所有外部对等体收到的路由。
2.考虑通过相应地应用路由策略和筛选器来减少路由数。

在 Edge 节点上即将达到最大 IPv6 路由限制。

检测到事件时：“在 Tier-0 网关和 Edge 节点 {edge_node} 的所有 Tier-0 VRF 上，IPv6 路由数已达到限制 {route_limit_threshold}。”

事件解决后：“在 Tier-0 网关和 Edge 节点 {edge_node} 的所有 Tier-0 VRF 上，IPv6 路由数在限制 {route_limit_threshold} 内。”

1.检查路由重新分发策略以及从所有外部对等体收到的路由。
2.考虑通过相应地应用路由策略和筛选器来减少路由数。

在 Edge 节点上已超过最大 IPv4 路由限制。

检测到事件时：“在 Tier-0 网关和 Edge 节点 {edge_node} 的所有 Tier-0 VRF 上，IPv4 路由数已超过限制 {route_limit_maximum}。”

事件解决后：“在 Tier-0 网关和 Edge 节点 {edge_node} 的所有 Tier-0 VRF 上，IPv4 路由数在限制 {route_limit_maximum} 内。”

1.检查路由重新分发策略以及从所有外部对等体收到的路由。
2.考虑通过相应地应用路由策略和筛选器来减少路由数。

在 Edge 节点上已超过最大 IPv6 路由限制。

检测到事件时：“在 Tier-0 网关和 Edge 节点 {edge_node} 的所有 Tier-0 VRF 上，IPv6 路由数已超过限制 {route_limit_maximum}。”

事件解决后：“在 Tier-0 网关和 Edge 节点 {edge_node} 的所有 Tier-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+ 合规性要求之一。这意味着 NSX 状态当前不符合 EAL4+ 要求。”

事件解决后：“EAL4+ 合规性问题已全部解决。”

从 UI“主页 - 监控和仪表板 - 合规性报告”菜单运行合规性报告，并解决所有标有 EAL4+ 合规性名称的问题。

NSX 安全配置不符合 NDcPP 要求。

检测到事件时：“违反了 NDcPP 合规性要求之一。这意味着 NSX 配置当前不符合 NDcPP 要求。”

事件解决后：“NDcPP 合规性问题已全部解决。”

从 UI“主页 - 监控和仪表板 - 合规性报告”菜单运行合规性报告，并解决所有标有 NDcPP 合规性名称的问题。

NSX 安全配置不符合 EAL4+ 要求。

检测到事件时：“违反了 EAL4+ 合规性要求之一。这意味着 NSX 配置当前不符合 EAL4+ 要求。”

事件解决后：“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} 上的上行链路的物理网卡状态。找出此物理网卡在主机上的映射名称，然后在 UI 上执行检查。
1.在 NSX UI 中，导航到“Fabric”|“节点”|“传输节点”|“主机传输节点”。
2.在“主机传输节点”列表中，检查“节点状态”列。查找节点状态为已降级或已关闭的传输节点。
3.选择“&lt传输节点&gt”|“监控器”。检查报告为“已降级”或“已关闭”的绑定（上行链路）的状态详细信息。为避免处于已降级状态，请确保所有上行链路接口均已连接且处于开启状态，而无论它们是否正在使用中。

DPU 上的 LACP 报告成员已关闭。

检测到事件时：“DPU {dpu_id} 上的 LACP 报告成员已关闭。”

事件解决后：“DPU {dpu_id} 上的 LACP 报告成员已启动。”

检查 DPU {dpu_id} 上的 LAG 成员的连接状态。找出相关物理网卡在主机上的映射名称，然后在 UI 上执行检查。
1.在 NSX UI 中，导航到“Fabric”|“节点”|“传输节点”|“主机传输节点”。
2.在“主机传输节点”列表中，检查“节点状态”列。查找节点状态为已降级或已关闭的传输节点。
3.选择“&lt传输节点&gt”|“监控器”。找到报告为“已降级”或“已关闭”的绑定（上行链路）。
4.通过登录到发生故障的 DPU {dpu_id}，并调用 esxcli network vswitch dvs vmware lacp status get 来检查 LACP 成员状态详细信息。

上行链路即将中断。

检测到事件时：“上行链路即将中断。”

事件解决后：“上行链路即将连接。”

检查主机的上行链路的物理网卡状态。
1.在 NSX UI 中，导航到“Fabric”|“节点”|“传输节点”|“主机传输节点”。
2.在“主机传输节点”列表中，检查“节点状态”列。查找节点状态为已降级或已关闭的传输节点。
3.选择“&lt传输节点&gt”|“监控器”。检查报告为“已降级”或“已关闭”的绑定（上行链路）的状态详细信息。为避免处于已降级状态，请确保所有上行链路接口均已连接且处于开启状态，而无论它们是否正在使用中。

上行链路即将中断。

检测到事件时：“上行链路即将中断。”

事件解决后：“上行链路即将连接。”

检查主机的上行链路的物理网卡状态。
1.在 NSX UI 中，导航到“Fabric”|“节点”|“传输节点”|“主机传输节点”。
2.在“主机传输节点”列表中，检查“节点状态”列。查找节点状态为已降级或已关闭的传输节点。
3.选择“&lt传输节点&gt”|“监控器”。检查报告为“已降级”或“已关闭”的绑定（上行链路）的状态详细信息。为避免处于已降级状态，请确保所有上行链路接口均已连接且处于开启状态，而无论它们是否正在使用中。

LACP 报告成员已关闭。

检测到事件时：“LACP 报告成员已关闭。”

事件解决后：“LACP 报告成员已启动。”

检查主机上 LAG 成员的连接状态。
1.在 NSX UI 中，导航到“Fabric”|“节点”|“传输节点”|“主机传输节点”。
2.在“主机传输节点”列表中，检查“节点状态”列。查找节点状态为已降级或已关闭的传输节点。
3.选择“&lt传输节点&gt”|“监控器”。找到报告为“已降级”或“已关闭”的绑定（上行链路）。
4.通过登录到发生故障的主机，并在 ESXi 主机上调用 esxcli network vswitch dvs vmware lacp status get 或在 KVM 主机上调用 ovs-appctl bond/show 和 ovs-appctl lacp/show 来检查 LACP 成员状态详细信息。

无法完全实现转换连接。

检测到事件时：“转换连接相关的配置未完全正确实现。可能发生的问题为无法检索提供程序信息或出现了暂时性的提供程序通信错误。”

事件解决后：“转换连接故障已修复。”

如果此警报未在 10 分钟内自动解除，请重试最新的转换连接相关请求。例如，如果 TGW 连接 API 请求触发了此警报，请再次重试 TGW 连接 API 请求。如果警报在重试请求后仍未解除，请尝试执行以下步骤：
1.检查任务是否一直失败，或者检查任务是否已恢复。a) 确定主 Manager 节点。登录到其中一个节点后，运行命令：- su admin - get cluster status verbose 这将显示主 Manager 节点 b) 登录到 NSX 主 Manager 节点。检查 NSX 主 Manager 节点上的 vmc-app.log：- tail -f /var/log/policy/vmc-app.log c) 检查日志了解以下打印内容 - 如果其中任何错误消息每两分钟显示一次，则意味着任务一直失败。- 无法获取 [] 的 TGW 路由表。错误：[] - 无法获取路由表 [] 中连接 [] 的 TGW 路由。错误 - 无法获取 [] 的 TGW 连接 VPC ID。错误：[] - 无法获取 [] 的 TGW 连接资源 ID。错误：未知资源类型 - 无法获取 TGW [] 的 TGW 连接。错误：[] - 无法获取本地 TGW 连接 []。错误：[] - 在 AWS 中找不到正确的 TgwAttachment 状态，状态为[]，正在跳过 TGW 路由更新任务 - TGW 连接 [] 未与任何路由表相关联 - 未找到 [] 的本地 TGW SDDC 连接
2.在主 Manager 节点上检查来自 NSX Manager 的所有 AWS 调用是否均失败。运行以下命令：- export HTTP_PROXY=http://&ltpop ip&gt:3128 - export HTTPS_PROXY=http://&ltpop ip&gt:3128 - export NO_PROXY=169.254.169.254 - aws ec2 describe-instances --region 如果 aws 命令失败并显示错误，则可能是 pop 上的 HTTP 反向代理配置存在系统问题，或者存在 AWS 服务端问题。
3.检查 TGW 连接是否仍存在于 AWS 中。a) TGW 连接 ID 可以通过 GET cloud-service/api/v1/infra/associated-groups - aws ec2 describe-transit-gateway-attachments --region --transit-gateway-attachment-id &ltTGW attachment ID&gt 找到。 如果 TGW 连接已删除，请联系 VMware 技术支持团队，并共享 SDDC ID 和 TGW 连接 ID。在 VMware 技术支持团队确定问题后，将根据需要手动删除遗留的对象。b) 在 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 会话状态来确定会话关闭原因，并根据原因来解决错误。