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

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

然而事实上当某个服务产生故障时，可能会对整个零碎造成极大的影响。
通过运行状况查看（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。

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

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

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

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