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

Question

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

问题在于，并非所有依赖项都是强制我们的应用程序才能工作的。因此，虽然访问数据库的问题可能很严重，但访问某些微服务的问题只会影响我们应用的一小部分。

除此之外，我们还有 Amazon ELB。仅仅因为一个依赖项是 unhealty 就将我们的应用程序标记为 unhealty 似乎并不正确。 ELB 应该只尝试恢复 unhealty 依赖，这样我们的应用就会再次healthy。

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

Answer 1

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

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

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

亚马逊有许多服务可以帮助监控、报告和管理服务。使用 CloudWatch 进行监控，使用 SNS 或 SES 进行报告，使用 ASG 进行自动缩放等。

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