主动或被动健康检查： 哪一个适合您？

正如定期去看医生是保持健康的重要组成部分一样，定期检查应用程序的健康状况对于可靠的性能也至关重要。 在反向代理和负载均衡流量时，NGINX 使用被动健康检查，通过自动将流量从不响应请求的服务器转移，保护应用用户免受中断的影响。 NGINX Plus 添加了主动健康检查，发送特殊探测器，甚至可以在不健康的服务器无法处理请求之前检测到它们。 哪种类型的健康检查对您的应用有意义？ 在这篇文章中，我们为您提供做出该决定所需的信息。

什么是健康检查？

从最基本的意义上讲，健康检查是一种确定服务器是否能够处理流量的方法。 NGINX 使用健康检查来监控它进行反向代理或负载均衡流量的服务器 - 它称之为上游服务器。

被动健康检查

被动健康检查——在 NGINX 开源和 NGINX Plus 中均可用——依赖于观察服务器在处理连接和流量时的行为。 它们有助于防止用户因服务器超时而遇到中断，因为当 NGINX 发现服务器不健康时，它会立即将请求转发到其他服务器，停止向不健康的服务器发送请求，并在上游组中剩余的健康服务器之间分配未来的请求。

请注意，仅当上游组定义为具有多个成员时，被动健康检查才有效。 当仅定义一个上游服务器时，它永远不会被标记为不可用，并且当它不健康时用户会看到中断。

被动健康检查的工作原理

这里详细介绍了被动健康检查的工作原理，但如果不感兴趣，请跳至主动健康检查。

默认情况下，如果在与TCP/UDP（流）服务器建立连接时出现单个错误或超时，NGINX 会认为该服务器不健康。

如果在与 HTTP 服务器建立连接、向其传递请求或读取响应头（根本没有收到响应则算作这种类型的错误）时出现单个错误或超时，则 NGINX 认为HTTP 服务器不健康。 您可以使用proxy_next_upstream指令自定义HTTP代理的这些条件，并且还有针对FastCGI 、 gRPC 、 memcached 、 SCGI 、 TCP / UDP和uwsgi协议的并行指令。

对于 HTTP 和 TCP/UDP，NGINX 默认等待十秒，然后再次尝试连接并向不健康的服务器发送请求。 您可以使用服务器[ HTTP ][ Stream ]指令的fail_timeout参数来更改此时间量。

您可以使用服务器指令的max_fails参数来增加 NGINX 认为服务器不健康所必须发生的错误或超时次数；在这种情况下， fail_timeout参数设置必须发生该数量的错误或超时的时间段，以及 NGINX 在将服务器标记为不健康后等待多长时间再次尝试该服务器。

主动健康检查

主动健康检查（NGINX Plus 独有）是定期发送到应用端点的特殊请求，以确保它们正确响应。 它们与被动健康检查是分开的，并且是对被动健康检查的补充。 例如，NGINX Plus 可能会向应用程序的 Web 服务器发送定期 HTTP 请求，以确保它以有效的响应代码和正确的内容进行响应。 主动健康检查能够持续监控特定应用组件和进程的健康状况。 它直接衡量了应用的可用性，尽管这取决于指定的健康检查对整体应用健康状况的代表性。

您可以自定义主动健康检查的多个方面；请参阅主动健康检查的用例。

被动健康检查的用例

被动健康检查是必需的。 对于每个application开发、DevOps、DevSecOps 和平台操作团队来说，运行被动健康检查作为生产基础设施监控程序的一部分是最佳实践。 NGINX 默认对负载平衡流量运行被动健康检查，包括 HTTP、TCP 和 UDP 配置。

被动健康检查的优点包括：

• 可在 NGINX 开源软件中使用
• 默认情况下，上游{}配置块中包含的服务器已启用
• 上游服务器不会承受额外负载
• 可按照时间段内的最小故障次数进行配置，如被动健康检查的工作原理中所述
• 可配置的慢启动（NGINX Plus 独有）——当服务器恢复健康时，NGINX Plus 会逐渐增加转发给它的流量，让它有时间“预热”

NGINX 开源的优势是成本（显然无）、可配置性以及庞大的第三方模块库。 由于源代码可用，开发人员可以修改和扩展功能以满足他们的特定需求。

对于许多应用（及其开发人员）来说，被动健康检查就足够了。 例如，对于不面向客户且执行较小任务的微服务来说，主动健康检查可能有些过度。 类似地，对于缓存可以减少延迟问题发生的可能性或内容分发网络 (CDN) 可以接管部分应用任务的应用来说，它们可能不是必需的。 总而言之，被动健康检查最适合：

• 监控 HTTP 流量
• 与应用分开监控基础设施
• 监控可容忍延迟的应用
• 监控不需要高性能的内部应用

主动健康检查用例

对于关键任务应用，主动健康检查通常至关重要，因为客户和关键流程会直接受到问题的影响。 对于这些应用，以应用的客户或消费者的身份对应用进行测试至关重要，并且这需要主动的健康检查。 主动健康检查类似于应用性能监控工具，例如 New Relic 和 AppDynamics，它们使用带外检查来测量应用延迟和响应。 对于主动健康检查，NGINX Plus 包含许多 NGINX Open Source 中未包含的特性和功能：

• 应用可用性的带外健康检查
• 测试配置的端点并寻找特定的响应
• 测试与处理实际应用流量的端口不同的端口
• 保持 HTTP 连接以进行健康检查，无需为每次检查设置新的连接
• 更好地控制失败和通过的情况
• 可选择在新添加的服务器接收实际应用流量之前对其进行测试

通过主动健康检查，开发人员可以设置 NGINX Plus 来自动检测后端服务器何时关闭或出现问题，然后将流量路由到健康的服务器，直到问题得到解决。 主动健康检查的可配置性更强，可以执行更复杂的健康检查，可能在应用问题影响实际应用用户之前检测到它们。 这可以最大限度地减少停机时间并防止用户访问应用中断。

如何配置健康检查

默认情况下，被动健康检查处于启用状态，但您可以自定义其频率以及在服务被标记为不健康之前发生的故障次数，如被动健康检查的工作原理中所述。 有关被动和主动健康检查的完整配置说明，请参阅我们的文档：

• HTTP 健康检查
• TCP 健康检查
• UDP 健康检查
• gRPC 健康检查

结论： 选择符合您的application要求的健康检查

健康检查是保证任何生产应用平稳、灵敏地运行的重要部分。 它们是检测问题并在影响最终用户之前识别日益增加的延迟源的最佳方法。 对于许多应用来说，被动健康检查就足够了。

对于更关键的应用，需要直接洞察用户级别的应用程序行为，主动检查会更好。 NGINX 开源是免费使用的，并提供可配置的被动健康检查。 NGINX Plus 提供先进的主动健康检查功能以及商业支持。

想要尝试使用 NGINX Plus 进行主动健康检查吗？ 立即开始您的30 天免费试用或联系我们讨论您的用例。