什么是 API 监控（API Monitoring）？

现代应用是 API 驱动的：前端调后端 API，后端之间互相调，还要调支付、短信、地图等第三方 API。任何一个 API 挂了，功能就断了。 API 监控就是定期、自动地调用这些端点，验证它们返回正确的结果，异常时第一时间告警。

工作原理

API 监控本质上是针对 API 端点的合成探测：

1. 按频率发起调用：每 30 秒到几分钟，向 API 端点发送请求（GET 健康检查、POST 创建资源等）；
2. 多重校验：
   • 状态码（200/201 还是 5xx？）
   • 响应体内容（JSON 里关键字段的值对不对？）
   • 响应时间（接口越来越慢？）
   • 证书与 TLS（HTTPS 接口的证书健康）；
3. 连续失败后创建事件并告警，恢复后自动关闭。

与网页可用性监控的区别：网页检查的是"页面能打开"，API 监控检查的是"接口返回正确的结构化数据"——可以做更深的断言，比如创建一条测试订单再删除，验证完整写链路。

该监控哪些 API

• 核心业务链路：登录、下单、支付回调——坏了直接损失收入；
• 被外部依赖的公开 API：你的客户/合作方在调用的接口， SLA 直接挂钩；
• 第三方依赖 API：你依赖的支付网关、短信通道——它们的故障会变成你的故障，监控它们是为了快速定界；
• 内部微服务间 API：服务网格里的关键调用，上游挂了下游全崩。

一次 API 事件的处理流程

1. 探测连续失败（建议多节点确认，防误报）；
2. 告警触达值班人，带上：失败端点、错误类型（超时/状态码/断言失败）、开始时间、最近一次的响应内容；
3. 值班人按 runbook 排查：是应用挂了？数据库挂了？还是依赖的第三方挂了？
4. 恢复后事件自动关闭，统计 MTTR 与可用率。

价值与局限

价值：先于用户发现故障（用户还没遇到，监控先报了）；量化 SLA（用数据证明 99.95% 而不是口头承诺）；盯第三方（依赖方故障时第一时间切换预案）。

局限：合成监控是"已知路径的定期检查"——它覆盖不了你没想到的接口组合；单次探测成功不代表高并发下正常。它需要与 APM（看真实流量的性能分布）、日志（看错误细节）配合，才是完整的 API 可观测性。

观测云对照

观测云可用性监测支持 HTTP(S) 探测任务，可配置请求方法、Header、Body，对响应做状态码与内容断言，多地域节点发起；告警直连值班通知渠道。对内部 API，APM 探针提供真实流量下的接口级成功率与延迟分布——合成探测（拨测）与真实流量监控（APM）在一个平台上互相印证：拨测红了 APM 也异常，是服务端问题；拨测绿但用户报错，是局部网络或客户端问题。

常见问题（FAQ）

Q：POST/PUT 类写接口怎么做监控？
A：用专门的测试数据：创建→断言→清理。千万别用真实用户数据做探测。对确实不能写的接口，至少监控它的 405/401 响应是否符合预期（证明服务活着）。

Q：监控频率和超时怎么设？
A：核心 API 1 分钟一次、超时 5-10 秒；一般接口 5 分钟一次。超时别设太短——网络抖动会造成误报，配合"连续 2-3 次失败才告警"更稳。

Q：第三方 API 的监控数据有什么用？
A：两个用途：故障时快速定界（"是我们的问题还是微信支付的？看监控就知道"）；以及长期评估——第三方频繁超时就该考虑换供应商或加双通道。