为了在服务器运行中放弃很高的可靠性，咱们能够采纳一些办法来及时处理各种可预测的故障。
比方，各种硬件都会有肯定的寿命预期，任何软件也有可能在某个时刻解体。
现实情况下，咱们心愿服务的运行状况只有两种状态

1. 失常工作
2. 不失常工作但不会影响其余服务

然而事实上当某个服务产生故障时，可能会对整个零碎造成极大的影响。
通过运行状况查看（health check), 咱们能够检测单机故障，从而能够及时对机器进行主动替换或是及时告诉到 SDE。然而执行 health check 也有可能将小问题转变为全面的大的中断。因而在增加这种查看时须要权衡利弊。

What

health check 是一种询问特定服务器上的服务是否胜利执行的工作办法。LB 能够定期向服务器收回询问申请，以确定能够平安的将流量导向哪些服务器。如果服务是从 queue 中轮询音讯，那么在轮询前能够先查看本人是否运行状况良好，再决定是否从 queue 中取出更多的工作。Monitoring agents（能够在每台机器上运行或在内部监控 fleet 中运行）也能够用来询问服务器是否运行良好，而后决定是收回警报还是主动解决产生故障的服务器。

health check 能够解决 least request 负载平衡算法存在的 black hole 问题。

How

现实的 health check 须要查看利用程序运行的方方面面，包含非关键反对过程是否正在运行。然而如果因为非关键起因使得 health check 失败，从而将该台服务器从可用服务器中移除，那么这种机制会弊大于利。
health check 的难点在于，执行全面的 health check，可能会导致查看过细，使得本应该还对付可用的服务器间接被停用，导致给整个 fleet 造成侵害。而过于拉垮的 health check 则起不到本应该起的作用。另一方面，误报故障会给整个 fleet 造成侵害。因而，如果单台服务器产生某个问题，则可用将其停用，但如果所有服务器“产生”同样的问题，则应该容许流量持续通过。这种机制称为 Fail open。
咱们能够简略的将 health check 分为 shallow health check 和 deep health check。

1. shallow health check 示意的是本机器的问题，覆盖范围仅仅是单台机器。比方读写查看，机器磁盘是否满了，满了能够主动换机器；bean 有没有启动胜利等。
2. deep health check 示意的是与其余机器相干的 health check，比方对于依赖项的查看等。

执行 health check 时要满足的一些条件：

1. 机群应该采取大致相同的行为模式，比方将不同类型的流量路由到不同机器即违反了此条。
2. 队列应该同构，即应该应用大致相同的机器。
3. 必须报告谬误或行为差别。因为咱们依附服务器自身来报告谬误，因而如果它们的监控零碎也产生了问题，就很麻烦。因而咱们能够将查看增加到会拜访服务器的客户端，比方 Load Balancer，在 LB 上能够查看日志，从而晓得每个申请都发往了哪个后端服务器，响应工夫，以及该申请胜利还是失败。

tips：
优先执行 health check！
衡量依赖项查看与影响范畴，比方有的依赖项并不是服务的要害依赖项，这种货色失败就失败了，不要因而而使得 health check 失败，导致服务不可用。
或者一个 service 上有多个 API，其中一个 API 不可用了，但其余 API 可能能够失常应用，是否要在这种状况下齐全停用该机器上的服务，须要慎重考虑。