在记录虚拟服务的客户端流量日志时，NSX Advanced Load Balancer 不包括运行状况监控器。本主题介绍了检查主动运行状况监控器收到的结果的方法。
使用 GUI
以下是从 GUI 中检查服务器状态的不同方法：
将鼠标悬停在关闭（红色）的服务器图标上。
导航到页面，单击运行状况监控器表中的失败监控器以展开结果。
检查虚拟服务器和池记录状态更改的事件以及原因。
有关更多信息，请参见《VMware NSX Advanced Load Balancer 监控和可操作性指南》中的将服务器标记为关闭的原因一节。
使用 CLI 和 API
您可以从 CLI 和 API 中查看池中的每个服务器的详细运行状况监控器信息。下面的示例显示一个缩略图：
show pool [poolname] server hmonstat +---------------------------------+----------------------------------------+ | Field | Value | +---------------------------------+----------------------------------------+ | server_hm_stat[1] | | | server_name | 10.90.15.61:8000 | | oper_status | | | state | OPER_UP | | shm_runtime[1] | | | health_monitor_name | healthmonitor-1 | | health_monitor_type | HEALTH_MONITOR_TCP | | last_transition_timestamp_3 | Tue May 24 20:42:51 2016 ms | | last_transition_timestamp_2 | Tue May 24 20:42:38 2016 ms | | last_transition_timestamp_1 | Tue May 24 20:37:10 2016 ms | | rise_count | 255 | | fall_count | 0 | | total_checks | 1414 | | total_failed_checks | 5 | | total_count[1] | | | type | CONNECTION_TIMEOUT | | count | 5 | | avg_response_time | 1 | | recent_response_time | 1 | | min_response_time | 1 | | max_response_time | 1999 | | port | 8000 | | curr_failed_checks | 1 | | ip_addr | 10.90.15.61 | | port | 8000 | +---------------------------------+----------------------------------------+
使用数据包捕获
默认情况下，在执行数据包捕获时，NSX Advanced Load Balancer 不包括运行状况监控器流量。不过，您可以通过 CLI 使用以下标记更改该设置：
-
debug_vs_hm_include -
在捕获中包括运行状况监控器数据包
-
debug_vs_hm_none -
该默认标记从捕获中忽略运行状况监控器数据包
-
debug_vs_hm_only -
仅捕获运行状况监控器数据包
有关更多信息，请参见《VMware NSX Advanced Load Balancer 监控和可操作性指南》中的数据包捕获一节。
使用手动测试
您可以手动发送 ping、curl 或类似的 Linux CLI 访问的实用程序以验证服务器响应。
有关更多信息，请参见手动验证服务器运行状况。
常见的监控器问题
如果服务器响应结果是所需的响应，并且 NSX Advanced Load Balancer 仍将服务器标记为 DOWN，您可以检查这些常见问题。
常规监控器问题
以下是常规监控器问题：
系统检查从服务器返回的内容，并将其与监控器的服务器响应数据进行比较（区分大小写）。
大多数监控器仅检查服务器响应中的最多 2k 内容，其中包括标头和内容。如果所需的结果位于响应中的其他位置，则会将服务器标记为
DOWN。重复 IP 是导致运行状况检查间歇性失败的最常见问题之一。
被动
在出现重大错误时，系统将触发被动监控器，这会自动为虚拟服务生成日志。在钻取到服务器页面时，被动监控器可能显示不到 100% 的内容。您可以筛选相关服务器以查看虚拟服务日志，然后单击日志分析边栏中的重要性磁贴。
您可以使用以下 CLI 检查是否发生失败，以及失败是否随时间的推移而增加：
: > show pool p1 detail | grep suspect
| lb_fail_suspect_state | 0
Ping
某些设备（包括服务器和防火墙）会限制 ICMP 消息的频率，并且可以静默丢弃这些消息。在这些情况下，您需要降低发送间隔选项的频率。
HTTP
您需要将发送字符串中的确切请求标头发送到服务器。例如，主机标头中的空格可能会导致 IIS 出现问题，例如 Host: Avi Server。HTTP 监控器会添加一些标头以模拟有效的请求。要忽略这些额外的标头，您可以使用 TCP 监控器，对于客户端请求数据字段中定义的发送字符串，该监控器是显式的。如果您使用 TCP，请确保为回车换行符添加 \r\n 字符。
NSX Advanced Load Balancer 在请求的每一行末尾包含 \r\n。HTTP 1.0 要求在最后一行后面发送第二个 \r\n，其中包括：
[Health monitor send string]\r\n User-Agent: avi/1.0\r\n Host: [Avi inserted server name]\r\n Accept: */*\r\n\r\n
对于 HTTP/S，NSX Advanced Load Balancer 不呈现结果，但逐字检查结果。例如，服务器可能将 302 重定向发回到 NSX Advanced Load Balancer，其中不包括 server is good。浏览器将执行重定向，并显示具有正确内容的页面。内容的 URI 编码也可能导致 HTTP/S 响应失败。
外部
您可以通过具有较低特权的 hmuser 用户身份运行外部运行状况监控器。您可以附加到一个服务引擎，并以具有 root 特权的 hmuser 身份登录：su - hmuser <-- login。
root@test-se2:~# su - hmuser
hmuser@10-10-25-28:~$ pwd
/run/hmuser
UDP 运行状况监控器
未配置接收字符串的 UDP 运行状况监控器依靠“无法访问 ICMP”消息以检测错误。如果缺少 ICMP 消息，则导致将服务器标记为启动。在具有很多服务器的部署中，ICMP 消息数量可能很大，并且可能会错误地将 UDP 运行状况监控器标记为启动。
为了消除上述情况并将服务器标记为关闭或将虚拟服务标记为关闭，您可以调整 ICMP 速率限制配置。
如果由于“无法访问 ICMP”速率限制器而大量丢弃“无法访问 ICMP”消息，您可以使用以下命令以确认出现了该问题：
show serviceengine [se-name] flowtablestat | grep icmp_rx_rl | icmp_rx_rl_cfg_pps | 100 | | icmp_rx_rl_confirming | 30 | | icmp_rx_rl_drops | 0 |
以下是用于配置 ICMP 速率限制的命令：
[admin:controller]: configure serviceengineproperties [admin:controller]: seproperties:se_runtime_properties [admin:controller]: seproperties:se_runtime_properties se_rate_limiters [admin:controller]: seproperties:se_runtime_properties:se_rate_limiters : icmp_rl 100
