我管理一个 Web 服务，对于我的公司来说，检测并通知任何服务是否停机以及它执行的任何操作是否响应时间过长非常重要。到目前为止，有一个独立的 Web 应用程序（包括前端和后端）每 15 分钟向这些端点请求随机操作，但我发现它很复杂，因为它需要为此目的维护整个 Web 应用程序，我知道许多免费的 Web 服务应该可以完成这项工作。
我已经设置了 AWS Healthchecks 来替换轮询 Web 应用程序，并且它在正常运行时间部分运行良好，现在我的问题是关于响应时间部分。
所有这些 API 健康检查服务似乎都是为不太复杂的请求准备的，因此，API 应该负责为健康检查服务提供一个“状态”端点，并在其中包含数据库延迟等“OK”内容，还是应该由“健康检查器”负责执行复杂的请求？哪种方法更正确？
谢谢！
答案1
您可能不应该通过应用程序的健康检查路径来监控数据库性能——这可能会发生一些危险的情况。假设您在 AWS 中使用 ASG，并使用 LB 健康检查来确定 ASG 是否应该轮换机器。如果您开始出现数据库争用（与您的应用程序无关），您的 ASG 将开始删除节点。因此，您不仅会拥有性能不佳的数据库，而且还会拥有耗尽的 ASG。
通常，性能监控应在健康范围之外进行。我们大量使用 statsd，并将所有指标、应用程序和数据库都放入其中，以便我们能够据此绘制图表并发出警报。
另外请记住，在扩展时，您的健康检查速度也会扩展 - 我们有一些服务每秒会收到数千个健康检查请求，如果每个请求都在执行合成的昂贵查询，那么我们的数据层就会离线。
当您添加缓存层时，逻辑也会变得更加复杂 - 如果数据库健康但 KV 缓存不健康，健康检查端点应该返回什么？
总的来说，虽然端到端监控对于有效的监控策略至关重要，但我强烈建议对流向数据库的现有查询指标进行带外监控 - 这些指标代表了真实的用户性能，并将为您提供应用程序运行状况的实际表现的可量化指标。