amazon-web-services - 健康检查的最佳做法是什么？

Question

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

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

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

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

Answer 1

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

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

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

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

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