如何监控 REST API 的正常运行时间和响应时间
监控 REST API 与监控网站不是一回事。来自 API 的成功 HTTP 200 并不能保证响应内容正确、响应时间可接受,或者认证仍然有效。本指南介绍 API 监控实际应该检查什么、能尽早捕获问题又不至于嘈杂的阈值,以及简单 ping 检查会遗漏的静默故障模式。
API 监控应该检查的四件事
一个有用的 API 监控会在每次探测时检查四件事。每一项都能捕获其他几项漏掉的一类故障。
状态码:API 返回的是 200,还是 500、502 或 503?响应时间:API 是否在可接受的窗口内响应?响应体内容:响应是否包含预期的字段?认证状态:API 是否仍然接受昨天还在接受的凭据?同时检查这四项的监控,能捕获任何单一检查都会遗漏的异常行为。
值得监控的端点
并不是每个 API 端点都需要监控。三类端点能覆盖大部分实际价值。
- 一个健康检查端点:通常是 /health 或 /status。它应该返回 200,带一个小型 JSON 负载,确认数据库连接以及任何关键依赖项。探测开销低,出问题时失败迅速。
- 使用最频繁的真实端点:承担你最大流量比例的那个。如果你的 /users/me 端点服务 80% 的请求,就直接监控它。一旦它出问题,你的客户会立刻发现。
- 收益最高的真实端点:处理支付、订阅或任何直接转化为收入的端点。同样的监控方式,更高的告警优先级。
设置响应时间阈值而不触发误报
响应时间告警是制造嘈杂监控最简单的方法。部署期间一次缓慢的探测不是信号;连续十次缓慢的探测才是。行之有效的阈值策略是基于百分位的,而不是基于绝对值的。
测量端点在正常一周内的 p95 响应时间。把告警阈值设为 p95 的 2 倍。仅当连续三次探测超过该值时才告警。结果是一个忽略正常波动、但能捕获真实性能下降的监控。在第一个月内调整倍数和连续次数,之后就不再动它。
简单 ping 检查会遗漏的静默故障模式
API 可以返回 HTTP 200 但仍然处于损坏状态。真实事件中常见四种静默故障。
- 被缓存的错误响应:API 正确地返回过一次 500,在 CDN 处被缓存,从此之后就一直提供带有过时错误内容的 200。
- 错误的内容类型:由于调试中间件未关闭,API 返回 HTML 而不是 JSON。状态是 200,响应体无法解析。
- 空的成功响应:API 返回 200,但结果集为空,因为底层查询在一次迁移中悄悄丢失了一个 join。
- 认证漂移:API 返回 200,因为速率限制器优雅地处理了未认证请求,但响应体写着「请登录」。
在不泄露凭据的前提下进行认证监控
许多 API 在每个端点上都要求认证。监控需要凭据。两种模式效果不错;一种常见模式存在严重的安全风险。
好做法:一把专用的只读 API key,作用域尽可能窄,每季度轮换,在监控工具中加密存储。更好的做法:使用 webhook 签名或 HMAC 来代替 bearer token,这样监控就无法冒充用户。糟糕的做法:把一个长期有效的生产管理员用户 bearer token 粘贴到监控配置中。第三种模式会在监控的凭据泄露时引发它自己的事件。
API 的入门监控配置
为每个 API 添加三个监控。一个 /health 监控，60 秒频率，响应时间阈值为 500 毫秒。一个针对使用最频繁的实际端点的监控，60 秒频率，带有响应体内容断言。一个针对收入最高的端点的监控，30 秒频率，使用相同的响应体断言加上更严格的响应时间阈值。监控总数：三个。覆盖范围：大部分关键内容。当真实事故中出现边缘情况时再添加针对性的监控，不要预先设置。
