健康检查的最佳做法是什么？

Question

我们有一个 REST API。现在我们对我们拥有的每个依赖项（一个数据库和几个微服务）/health进行冒烟测试，200如果没有错误则返回。

问题是并非所有依赖项都是我们的应用程序运行所必需的。因此，虽然访问数据库的问题可能很关键，但访问某些微服务的问题只会影响我们应用程序的一小部分。

最重要的是，我们有亚马逊 ELB。仅仅因为一个依赖是unhealty 就将我们的应用程序标记为不健康似乎是不正确的。ELB 应该只尝试恢复不健康的依赖项，这样我们的应用程序将再次健康。

这就引出了一个问题：我们实际上应该在健康检查中检查什么？因为看起来我们根本不应该检查任何依赖项。另一方面，了解我们的应用程序访问其所有依赖项的状态实际上非常有帮助（例如用于故障排除问题），那么为此目的使用其他端点是否常见（例如/sanity或/diagnostics）？

Answer 1

不要过度尝试检查健康检查中的每个服务、每个依赖项等。基本上将您的健康检查视为 Go / No Go 测试，以便负载均衡器知道服务是否正在运行。

负载均衡器不会恢复失败的实例。他们只会让您的服务脱机。Auto Scaling Groups 可以通过创建新实例和终止失败的实例来恢复失败的实例。CloudWatch 可以监控您的实例并报告问题并导致事件发生（例如重启）。

您可以实施在服务器内部运行并选择报告/恢复路径的更全面的测试。示例可能包括向您的电子邮件或手机帐户发送 SNS 通知、重新启动服务器等。

亚马逊有许多服务来帮助监控、报告和管理服务。查看用于监控的 CloudWatch、用于报告的 SNS 或 SES、用于自动扩展的 ASG 等。

仔细考虑您的服务需要哪种类型的容错、高可用性和恢复策略。然后实施一种足够简单的方法，以便监控本身不会成为故障点。