运行状况检查

Posted 2021-09-12 Xinli

为了在服务器运行中保持很高的可靠性，我们可以采用一些方法来及时处理各种可预测的故障。
比如，各种硬件都会有一定的寿命预期，任何软件也有可能在某个时刻崩溃。
理想状况下，我们希望服务的运行状况只有两种状态

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可能可以正常使用，是否要在这种情况下完全停用该机器上的服务，需要慎重考虑。