主动健康检查是以每个上游服务群集进行配置。如服务发现部分所述，主动健康检查与SDS服务发现配合使用。但是，即使使用其他服务发现方式，也有相应需要进行主动健康检查的情况。Envoy支持三种不同类型的健康检查以及相应设置（检查时间间隔，因故障标记主机不健康，成功之后标记主机健康等）：
-
HTTP：HTTP健康检查期间，Envoy将向上游主机发送HTTP请求。如果主机健康，预计会有200返回码。如果上游主机想立即通知下游主机不再向其转发流量，则返回503返回码。
-
L3/L4：在L3/L4健康检查期间，Envoy会向上游主机发送一个可配置的报文。如果主机期望被认为是健康的，则在响应中回应相应的报文。Envoy也支持只连接L3/L4健康检查。
-
Redis：Envoy将发送一个Redis PING命令，并期待一个PONG响应。上游Redis服务器可以使用PONG以外的任何其他响应，来立即触发的健康检查失败。
Envoy还支持通过检测异常值，来进行被动健康检查。
浏览此处获取更多信息。
当部署Envoy网格并在集群之间进行主动健康检查时，会生成大量健康检查的流量。Envoy提供一个可配置HTTP健康检查过滤器，并安装在HTTP监听器中。这个过滤器有几种不同的操作模式：
-
不通过：在此模式下，健康检查请求永远不会传递到本地服务。Envoy将根据服务器当前的耗尽状态，以200或503响应。
-
通过：在这种模式下，Envoy会将每个健康检查请求传递给本地服务。预计该服务将返回200或503取决于其健康状况。
-
通过缓存：在这种模式下，Envoy会将健康检查请求传递给本地服务，但是会将结果缓存一段时间。随后在缓存有效时间内，进行的健康检查都会从缓存获取结果。当缓存超时后，下一个健康检查请求将被传递给本地服务。在使用较大的Envoy网格时，这是推荐的操作模式。Envoy使用持久性连接进行健康检查，健康检查请求对Envoy本身的成本很低。因此，这种操作模式产生了每个上游主机的健康状态的最终一致的视图，而没有使大量的健康检查请求压倒本地服务。
进一步阅读：
- 健康检查过滤器配置
- 健康检查失败管理端口(/healthcheck/fail)
- 健康检查成功管理端口(/healthcheck/ok)
当使用主动健康检查和被动健康检查（异常检测）时，通常使用较长的健康检查间隔来避免大量的主动健康检查流量。在这种情况下，在使用健康检查失败管理端口时，对能够快速排除上游主机，仍然很有用。为了支持这个，路由器过滤器将响应x-envoy-immediate-health-check-fail头。如果此报头由上游主机设置，则Envoy将立即将主机标记为主动健康检查失败。请注意，只有在主机集群中配置了主动健康检查，才会出现此情况。如果Envoy已通过健康检查失败管理端口标记为失败，则运行状况检查过滤器将自动设置此标头。
只要验证上游主机对特定健康检查URL的响应，并不一定意味着上游主机是有效的。例如，在云自动扩展或容器环境中，使用最终一致的服务发现时，主机可能会消失，然后以相同的IP地址返回，但会以不同的主机类型返回。解决这个问题的一个办法是为每个服务类型设置不同的HTTP健康检查URL。这种方法的缺点是使得整体配置变得更加复杂，因为每个健康检查URL都是完全自定义的。
Envoy的HTTP健康检查支持service_name选项。如果设置了此选项，运行健康检查程序会将x-envoy-upstream-healthchecked-cluster响应头域的值与service_name进行比较。如果值不匹配，健康检查不通过。上游运行状况检查过滤器会将x-envoy-upstream-healthchecked-cluster附加到响应头域。附加值由--service-cluster命令行选项确定。