API 监控：检查、断言和用户旅程

监控 API 不应只看可达性：验证预期响应、发现变慢，并在契约被破坏时提醒正确的人员。

选择正确的监控器

简单端点和状态码检查使用 HTTP。请求需要方法、正文、标头、认证或响应断言时使用 API。成功取决于登录、导航或结账等多个面向用户步骤时使用 Browser。系统主动调用是后台工作完成的最佳证明时使用 Heartbeat。

配置有意义的断言

从一个稳定的健康或就绪端点开始。期望特定状态码，并在有用时验证一个能证明依赖已就绪的小型响应正文值。将凭据作为密钥存储在监控器配置中；绝不要将生产凭据放入公开文档、状态页或客户端代码。

HTTP/API 断言示例

GET https://api.example.com/health
Expected status: 200
Expected body: {"ok":true}

对响应正文进行断言

状态码只能说明服务器已响应。关键词检查会断言返回的内容。每行输入一个断言，所有行都必须匹配，因此多行是 AND 而不是 OR。启用正则表达式匹配后，每行会作为 RE2 模式处理，可用于断言会变化的值。启用关键词必须不存在会反转整个检查，在找到文本或模式时失败。RE2 不支持前瞻、后顾或反向引用，并且只搜索响应的前 1 MB。

文字和正则表达式关键词断言

# Literal: every line must appear in the body
"status":"ok"

# Regular expression (RE2): every line must match
"status"\s*:\s*"(ok|healthy)"
"version":"4\.[0-9]+"

端点不足以说明问题时

API 可以返回 200，但客户面对的流程仍然失败。Browser 监控可以验证用户在应用中的旅程。对于队列、cron 任务、备份和部署流水线，计划 heartbeat 往往是更可靠的信号，因为它确认的是完成而不仅是可用性。

有意识地应对失败

将事件发送到团队实际关注的通知渠道，然后为可以安全自动化的操作添加触发器。将噪声检查与影响客户的检查分开，以便每次失败都有清晰的负责人和通知路径。