正如定期体检是保持身体健康的重要一环，定期检查应用的运行状况对于确保性能可靠也至关重要。在对流量进行反向代理和负载均衡时，NGINX使用被动健康检查，自动将流量从不响应请求的服务器转移出去，帮助应用用户免受服务中断的影响。NGINX Plus还提供主动健康检查，通过发送专用探测请求，甚至可以在服务器无法处理请求之前检测到其运行状况异常。哪种健康检查更适合您的应用？本文将提供相关信息，帮助您做出决定。
什么是健康检查？
从最基本的意义上说，健康检查是一种用于确定服务器能否处理流量的方法。NGINX使用健康检查来监控由其反向代理或进行流量负载均衡的服务器，即所谓的上游服务器。
被动健康检查
被动健康检查在NGINX Open Source和NGINX Plus中均可用，其工作原理是观察服务器在处理连接和流量时的行为。它们有助于避免用户因服务器超时而遭遇服务中断，因为当NGINX发现某台服务器运行状况不佳时，会立即将请求转发到其他服务器，停止向该服务器发送请求，并将后续请求分配给上游组中其余运行状况良好的服务器。
请注意，只有当上游组中定义了多个成员时，被动健康检查才有效。如果仅定义了一台上游服务器，则该服务器永远不会被标记为不可用；当其运行状况不佳时，用户将遇到服务中断。
被动健康检查的工作原理
下面详细介绍被动健康检查的工作原理。如果对此不感兴趣，可直接跳至“主动健康检查”。
默认情况下，如果NGINX在与TCP/UDP（stream）服务器建立连接时遇到一次错误或超时，即会将该服务器视为运行状况不佳。
如果在与HTTP服务器建立连接、向其传递请求或读取响应标头时发生一次错误或超时（完全未收到响应也属于此类错误），NGINX会将该HTTP服务器视为不健康。可以使用proxy_next_upstream指令自定义HTTP代理的这些条件；以下协议也有对应的指令：FastCGI、gRPC、memcached、SCGI、TCP/UDP和uwsgi。
对于HTTP和TCP/UDP，NGINX默认等待10秒，然后再次尝试连接到运行状况不佳的服务器并向其发送请求。可以使用fail_timeout参数调整server［HTTP］［Stream］指令中的这一时长。
可以使用max_fails参数，提高NGINX将服务器视为不健康状态所需发生的错误或超时次数，该参数属于server指令。在这种情况下，fail_timeout参数用于设置指定次数的错误或超时必须发生的时间段，以及NGINX将服务器标记为不健康状态后，等待多长时间再重试该服务器。
主动健康检查
主动健康检查是NGINX Plus独有的功能，通过定期向应用端点发送特殊请求，确认端点是否正常响应。主动健康检查与被动健康检查相互独立，是后者之外的补充。例如，NGINX Plus可能会定期向应用的Web服务器发送HTTP请求，确保服务器返回有效的响应代码和正确的内容。主动健康检查可以持续监控特定应用组件和进程的运行状况。它可以直接衡量应用可用性，但衡量结果取决于指定的健康检查能否代表应用的整体运行状况。
您可以自定义主动健康检查的多个方面；请参阅《主动健康检查用例》。
被动健康检查的使用场景
被动健康检查是必不可少的基础措施。对于应用开发、DevOps、DevSecOps和平台运维团队而言，将被动健康检查纳入生产基础设施监控方案是一项通行做法。默认情况下，NGINX会对负载均衡流量执行被动健康检查，包括HTTP、TCP和UDP配置。
被动健康检查的优势包括：
- NGINX Open Source中提供
- 默认对以下配置块中包含的服务器启用：
upstream{}configuration block - 不会给上游服务器增加额外负载
- 可配置指定时间段内的最少失败次数，具体说明请参阅被动健康检查的工作原理
- 可配置的慢启动（NGINX Plus专属功能）：当服务器恢复正常运行时，NGINX Plus会逐步增加转发到该服务器的流量，使其有时间完成“预热”
NGINX Open Source的优势包括零成本、可配置性，以及丰富的第三方模块库。由于源代码可用，开发人员可以修改和扩展其功能，以满足特定需求。
对于许多应用（及其开发者），被动健康检查已足够。例如，对于不直接面向客户且仅执行较小任务的微服务，主动健康检查可能没有必要。同样，如果应用可通过缓存降低出现延迟问题的可能性，或由内容分发网络（CDN）接管部分应用任务，也可能不需要主动健康检查。总而言之，以下情况更适合仅使用被动健康检查：
- 监控HTTP流量
- 将基础设施与应用分开监控
- 监控可容忍延迟的应用
- 监控对高性能要求不高的内部应用
主动健康检查的使用场景
对于关键任务型应用，主动健康检查通常至关重要，因为一旦出现问题，客户和关键流程会直接受到影响。对于此类应用，必须基本按照客户或应用使用者的实际使用方式进行测试，而这需要主动健康检查。主动健康检查类似于New Relic和AppDynamics等应用性能监控工具，后者使用带外检查来测量应用延迟和响应。对于主动健康检查，NGINX Plus提供了NGINX Open Source不具备的多项特性和功能：
- 用于检查应用可用性的带外健康检查
- 测试已配置的端点并检查是否返回特定响应
- 测试与处理实际应用流量的端口不同的其他端口
- 为运行状况检查保持HTTP连接，避免每次检查都建立新连接
- 更精细地控制失败和通过条件
- 可选择在任何新添加的服务器接收实际应用流量之前对其进行测试
借助主动健康检查，开发人员可以将NGINX Plus配置为自动检测后端服务器何时停机或出现问题，并将流量路由到健康的服务器，直至问题得到解决。主动健康检查具有更高的可配置性，因而可以执行更复杂的健康检查，并可能在应用问题影响实际用户之前将其发现。这有助于最大限度地缩短停机时间，并避免用户访问应用时发生中断。
如何配置健康检查
被动健康检查默认启用，但您可以自定义检查频率，以及服务被标记为不健康之前允许的失败次数，具体说明请参阅“被动健康检查的工作原理”。有关被动和主动健康检查的完整配置说明，请参阅相关文档：
结论：选择符合应用要求的健康检查
健康检查是确保任何生产应用顺畅运行并及时响应的重要环节。它们是及早发现问题和识别不断增加的延迟来源、避免最终用户受到影响的有效方式。对于许多应用，被动健康检查已足够。
对于更关键的应用，如果需要直接洞察用户层面的应用行为，主动健康检查更为合适。NGINX Open Source可免费使用，并提供可配置的被动健康检查。NGINX Plus提供高级主动健康检查功能和商业支持。
想试用NGINX Plus的主动健康检查功能？立即开始30天免费试用，或联系我们，讨论您的用例。
关于作者
相关博客文章
NGINX Plus R26 正式发布
NGINX Plus R26通过缓存JSON Web密钥集加快JWT验证，并强化TLS握手，从而提升安全性。NGINX JavaScript的新功能包括增强对异步函数的支持，以及实现WebCrypto API。
使用NGINX App Protect DoS保护gRPC应用，抵御严重的DoS攻击
gRPC具备开发人员设计和部署现代应用所需的速度与灵活性，但其开放性也使其极易受到第7层DoS攻击。NGINX App Protect DoS可保护gRPC应用免受此类破坏性攻击。
Ingress Controller 选型指南（第 2 部分）：风险与面向未来的规划
了解选择错误的Ingress控制器可能带来的风险，以及如何从关键方面着手，让您的选择更好地适应未来需求。
NGINX Plus R19 正式发布
NGINX Plus R19扩展了监控功能，不仅提供更多指标，还新增了指标分析方式；增加试运行模式，用于测试限速效果；增强键值存储，以支持IP地址范围；并使限速更加动态。
NGINX现已正式加入F5
NGINX现已正式成为F5的一部分。Gus Robertson现任F5 NGINX业务部门负责人。他阐述了两家公司在人才、文化和愿景方面融合的价值，以及双方将如何携手增强NGINX的开源产品和商业产品。
