我们有一个REST API。现在我们的/health对我们拥有的每个依赖项（数据库和几个微服务）进行冒烟测试，然后如果没有错误则返回200。
问题是并非所有依赖项都是必需才能使我们的应用程序正常工作。因此，虽然访问数据库的问题非常重要，但访问某些微服务的问题只会影响我们应用程序的一小部分。
最重要的是我们有亚马逊ELB。将我们的应用标记为 unhealty 并不恰当，因为一个依赖项是 unhealty 。 ELB应该只尝试恢复 unhealty 依赖关系，并且我们的应用程序将再次 healty 。
这导致了一个问题：我们应该在健康检查中检查什么？因为看起来我们不应该检查任何依赖性。另一方面，它实际上非常有助于了解我们的应用程序访问其所有依赖项的状态（例如，用于解决问题），因此为此目的使用其他端点也很常见（例如/sanity还是/diagnostics）？
答案 0 :(得分：1)
请勿过度检查健康检查中的每项服务，每项依赖项等。基本上将您的运行状况检查视为Go / No Go测试，以便负载均衡器知道服务是否正在运行。
负载均衡器无法恢复失败的实例。他们只会让您的服务离线。 Auto Scaling Groups可以通过创建新实例和终止失败的实例来恢复失败的实例。 CloudWatch可以监控您的实例并报告问题并导致事件发生（例如重新启动）。
您可以实施更全面的测试，这些测试在服务器内部运行并选择报告/恢复路径。示例可能包括向您的电子邮件或手机帐户发送SNS通知，重新启动服务器等等。
亚马逊提供多种服务来帮助监控，报告和管理服务。查看用于监控的CloudWatch，用于报告的SNS或SES，用于自动扩展的ASG等等。
想一想您的服务需要什么类型的容错，高可用性和恢复策略。然后实现一种足够简单的方法，以便监控本身不会成为故障点。