synthetic-monitoring

合成监控会按计划在生产环境中全天候运行脚本化测试。它能在真实用户报告之前发现服务中断、性能下降和流程故障——凌晨 3 点流量为零时，只有探测才能检查应用是否正常运行。登录页始终返回 200 却从未完成身份验证，简单的运行时间检查也会判定其正常；而会断言仪表板已加载的合成探测则能发现问题。本技能涵盖探测设计、告警集成、SLA 验证、多区域执行，以及让凌晨 3 点的告警具有可操作性的运行手册规范。

快速导航

情况	前往
选择平台（Checkly、Datadog、Grafana、CloudWatch…）	平台选项
编写探测（登录、API 健康状态、搜索）	探测设计 → references/probe-implementations.md
探测正常运行，但用户仍报告服务中断	故障模式
告警过于嘈杂或漏报真正的服务中断	告警集成
计算 SLA 的停机预算	SLA 验证
凌晨 3 点探测失败且值班人员不知所措	references/platforms-and-ci.md 中的运行手册模板

---

发现问题

首先检查 .agents/qa-project-context.md。如果该文件存在，请将其作为上下文，并跳过其中已有答案的问题。每个答案都会影响探测集、告警配置或 SLA 计算。

关键流程（决定要编写哪些探测）：

• 最重要的 5-10 条用户旅程是什么（登录、搜索、结账、注册、核心工作流）？这些将成为探测列表。
• 哪些流程一旦故障，就会立即导致收入损失或客户流失？这些流程应采用最高频率进行探测，并触发值班告警。
• 是否有会悄无声息地故障的流程（数据同步、后台作业、Webhook）？静默故障最需要探测——用户不会报告这些问题。
• 是否记录了可用性和响应时间的 SLA/SLO？它们决定停机预算和告警阈值。

当前监控（决定缺口所在）：

• 目前有哪些监控（运行时间检查、APM、错误跟踪、仪表板）？避免重复，找出缺口。
• 监控覆盖范围与用户实际体验之间是否存在差距？探测正是为了弥补这一差距。
• 目前如何获知生产环境问题（告警、用户报告、社交媒体）？如果依赖用户报告，首先要改进的指标就是发现时间。
• 上一次服务中断是什么时候，多久后才被发现？这决定了探测必须达到的发现时间目标。

基础设施（决定区域和 CDN 断言）：

• 应用是由多个区域还是单个区域提供服务？多区域服务需要进行多区域探测。
• 是否有可能掩盖源站故障的 CDN、缓存或边缘层？如果有，探测必须检查 x-cache/源站标头。
• 第三方依赖（支付、身份验证、电子邮件）是否有自己的监控？它们的状态页应纳入运行手册。
• 目前有哪些告警系统（PagerDuty、OpsGenie、Slack、电子邮件）？这决定了路由配置。

测试账户（决定数据安全性）：

• 生产环境中是否有专用的合成测试账户？没有这些账户，探测会污染真实数据和分析结果。
• 能否将测试账户排除在分析、计费和电子邮件营销活动之外？如果不能，探测流量会影响所有下游数据。
• 是否能通过 API 以编程方式创建账户并清理数据？这决定了创建后删除型探测是否可行。

---

核心原则

1. 合成测试持续验证用户体验

RUM 会告诉你发生过什么；合成监控则会告诉你现在正在发生什么，无论是否有真实用户活跃。凌晨 3 点流量为零时，只有合成探测能检查应用是否正常运行。应与 RUM 互补，而不是取代它：合成监控使用可预测的输入覆盖已知路径，RUM 则能发现真实用户以各种意想不到的方式造成的问题。

2. 保持探测简单、快速

耗时 2 分钟、访问 15 个页面的探测不是探测，而是在生产环境中运行的 E2E 测试套件。探测应当简短（每次探测的实际运行时间预算低于 30 秒）、目标明确（每次只检查一个关键路径）且稳定（retries: 0，零容忍不稳定）。30 秒上限是硬性预算：缓慢但“仍能通过”的探测会掩盖用户实际感受到的性能下降。

3. 根据趋势告警，而非单次失败

单次探测失败只是噪声——网络瞬断和 DNS 故障会不断导致这类情况。连续失败两次才是信号；来自 2 个或更多区域的失败则能确认问题并非局部问题。设置连续失败和多区域阈值，否则告警疲劳会让团队学会忽略告警。

4. 探测不得影响生产数据

探测每隔几分钟运行一次，全天候不间断。即使是很小的副作用（创建一条记录、递增一个计数器），也会不断累积。探测必须是非破坏性的，创建的数据必须立即清理，合成流量必须从分析、计费，以及——尤其重要的是——SLO／错误预算计算中排除，否则探测会抬高你自己的可靠性指标。

5. 验证目标，而非状态码

返回 200 但始终无法完成身份验证的登录页面是坏的。返回 200 但没有任何结果的搜索页面也是坏的。探测应验证用户能否达成目标——数据已加载、身份验证成功、结果已显示——而不只是页面返回了 2xx。

---

探测设计

围绕关键用户旅程设计探测，而不是围绕基础设施组件。用户不关心你的负载均衡器是否正常运行，他们关心的是能否登录并使用产品。

探测	验证内容	频率	超时
首页加载	DNS、CDN、服务器、基本渲染	1 分钟	10 秒
登录流程	身份验证服务、会话管理	5 分钟	15 秒
核心工作流	交付主要价值的操作（创建文档、运行报告）	5 分钟	20 秒
API 健康检查	后端服务、数据库连接	1 分钟	5 秒
搜索	搜索索引、查询处理、结果渲染	5 分钟	15 秒
结账（如适用）	支付集成（沙盒模式）、购物车、订单创建	10 分钟	25 秒
第三方集成	OAuth 提供方、邮件发送、文件存储	10 分钟	15 秒

探测实现

三种探测模式可满足大多数需求：登录流程（Playwright 浏览器）、API 健康检查（状态 + 身份验证 + 延迟预算）以及搜索探测（填写查询 → 提交 → 验证结果，而不只是状态）。每种探测都应限定为一条关键路径、严格的超时和 retries: 0。请参阅 references/probe-implementations.md，了解可运行的登录流程、API 健康检查和搜索探测，以及适应不同环境的配置。

非破坏性探测模式

Safe patterns:
  - Read-only operations: GET requests, page loads, searches
  - Sandbox transactions: payment in test mode, email to internal addresses
  - Create-then-delete: create a draft, verify, delete immediately
  - Synthetic flag: operations tagged as synthetic, excluded from processing

Dangerous patterns (avoid):
  - Creating real orders, tickets, or user-facing records
  - Triggering real notifications (email, SMS, push)
  - Modifying shared resources (config, permissions, settings)
  - Operations that cannot be automatically cleaned up

专用测试账号

Account requirements:
  - Clearly identifiable: email contains "synthetic" or "monitor"
  - Flagged in database with an is_synthetic flag (is_synthetic = true)
  - Excluded from analytics, billing, email campaigns, support queues
  - Excluded from RUM and SLO/error-budget pipelines (synthetic traffic is not real traffic)
  - Pre-populated with stable test data that probes can rely on
  - Credentials in a secrets manager (process.env), rotated quarterly
  - Separate accounts per concurrent probe (avoid state conflicts)

---

平台选项

平台	优势	适用场景
Checkly	原生支持 Playwright，以代码为中心，集成 Git；Rocky AI Agent（2026 年正式发布）现在可对 Playwright/API/Multistep/TCP/DNS/ICMP 检查进行自动化根因分析；可从任何 AI Agent 通过 CLI 访问；MCP 服务	已使用 Playwright 进行端到端测试的团队
Datadog Synthetic	深度集成 APM，支持浏览器和 API 测试	使用 Datadog 平台的团队
Grafana Synthetic Monitoring	开源，可与 Grafana 仪表板集成；可搭配 k6 2.x 使用；固定版本通道（v1.x/v2.x）以确保可复现性	使用 Grafana 技术栈的团队
AWS CloudWatch Synthetics	蓝图（心跳、API、失效链接、视觉差异）；可使用 Python 或 Node Puppeteer 金丝雀	已使用 AWS 的团队
New Relic Synthetics	集成全栈可观测性	使用 New Relic 平台的团队
Better Stack	轻量级运行时间监控 + 状态页面 + 值班	适合中小企业，设置快捷
Uptime Kuma	OSS，可自托管，轻量级	有自托管需求、监控范围较小
自定义（Playwright / k6 / Puppeteer + cron）	完全掌控，不受供应商锁定	预算有限或有自定义需求

可使用 Playwright（TS/JS）、Puppeteer、k6（JS——k6 2.0 于 2026 年 5 月发布，支持 AI 辅助编写测试，并提供更清晰的 Assertions API；适用于合成监控），或 Python（CloudWatch Synthetics、Checkly）编写探测。选择团队已有维护经验的工具。避免在新部署中使用 Pingdom——它是传统的运行时间监控工具；优先选择以代码为中心的替代方案（Checkly、Grafana、自定义 Playwright），以便将探测与应用一同纳入版本控制。

自定义和托管实现

自行管理：使用 GitHub Actions schedule cron（每 5 分钟一次）安排 Playwright 探测，通过 secrets 注入生产凭据，并将结果报告到监控 webhook。托管：Checkly 原生支持 Playwright，并按固定频率从多个位置运行。无论采用哪种方式，都应让探测能够识别环境，使同一份代码可通过不同的基础 URL 和阈值在预发布环境和生产环境运行。请参阅 references/platforms-and-ci.md，了解 GitHub Actions 工作流、Checkly 配置、告警路由规则和运行手册模板。

---

告警集成

并非每次探测失败都是事件。配置规则，在捕获真正问题的同时减少噪声。

Alerting rules:
  - Single failure: log, do not alert (transient network issue)
  - 2 consecutive failures from same region: warning (possible issue)
  - 2 consecutive failures from 2+ regions: alert on-call (confirmed outage)
  - Latency >2x baseline for 10 minutes: warning (performance degradation)
  - Latency >3x baseline for 5 minutes: alert on-call (severe degradation)
  - Any probe timeout: alert if 3 consecutive (service unresponsive)

路由。 收入关键路径（登录、结账、api-health）上的严重故障应触发值班告警（PagerDuty + Slack 事件），并采用较短的重复间隔；次要探测的警告发送到 Slack 监控频道；信息级事件采用较长的重复间隔。探测必须为每个结果添加 severity 和 probe 标签，这些路由才能匹配——完整的 alerting-rules.yaml 和标签添加步骤请参阅 references/platforms-and-ci.md 中的路由说明。

计划维护期间抑制合成告警。 维护窗口应静默合成告警（探测会按预期失败），并将该窗口排除在错误预算计算之外，否则计划内工作会消耗预算，并无故触发值班告警。

告警消息格式——提供足够的上下文，以便立即开始调查：

Alert template:
  Title: [SYNTHETIC] {probe_name} failing from {region}
  Severity: {critical|warning|info}
  Consecutive failures: {count}
  Last success: {timestamp}
  Error: {error_message}
  Duration: {last_response_time_ms}ms (threshold: {threshold}ms)
  Dashboard: {link_to_dashboard}
  Runbook: {link_to_runbook}
  Regions affected: {list_of_failing_regions}

{link_to_runbook} 指向每项探测各自的运行手册（六行内容：测试内容、初步检查、手动复现、升级处理、仪表板、负责人）。请参阅 references/platforms-and-ci.md 中的模板。

---

SLA 验证

可用性计算

Availability = (total_minutes - downtime_minutes) / total_minutes × 100

Where:
  - total_minutes = calendar month in minutes (43,200 for a 30-day month)
  - downtime_minutes = minutes where synthetic probes detected failure

SLA tiers (downtime/month, monthly basis on 43,200 min):
  99.0%  = 432 min   = 7h 12min     (basic web app)
  99.9%  = 43.2 min  = 43min 12s    (business application)
  99.95% = 21.6 min  = 21min 36s    (critical SaaS)
  99.99% = 4.32 min  = 4min 19s     (infrastructure/platform)

这些是常见的可用性目标，并非规定性的等级。应根据用户影响分析来设定目标，而不是按等级名称选择。现代实践（Google SRE Workbook、OpenSLO）更倾向于采用明确的 SLO + 错误预算策略，而非带标签的等级——定义面向用户的故障表现，设定用户可容忍的预算，并据此制定 SLO。参考资料：https://sre.google/workbook/ ；https://openslo.com/

响应时间百分位数

跟踪百分位数，而非平均值——平均值会掩盖最糟糕的体验。

SLA response time targets (example):
  Homepage load:  P50 < 1s,    P95 < 3s,   P99 < 5s
  API response:   P50 < 200ms, P95 < 500ms, P99 < 1s
  Search results: P50 < 500ms, P95 < 2s,   P99 < 4s
  Login flow:     P50 < 2s,    P95 < 5s,   P99 < 8s

错误预算跟踪

错误预算将 SLA 目标与工程决策联系起来。

Error budget calculation:
  SLO: 99.9% availability on a 43,200-min month
  Budget: 0.1% of total time = 43.2 minutes/month

  Budget consumed this month: 12 minutes (28%)
  Budget remaining: 31.2 minutes (72%)

Actions by budget status:
  >50% remaining: normal operations, ship features
  25-50% remaining: caution, review recent changes
  <25% remaining: freeze non-critical deploys, focus on reliability
  Budget exhausted: incident mode, every deploy needs extra scrutiny

从此计算中排除由你自己的维护窗口导致的合成探测停机时间，否则计划内工作也会显示为预算消耗。

---

多区域监控

从用户所在的区域运行探测。从 us-east-1 运行正常、但在 ap-southeast-1 出现故障的服务，对 APAC 用户来说就是不可用的。

Region selection strategy:
  - Minimum 3 regions for global services
  - Always include: closest to primary infrastructure, largest user base, farthest from primary
  - Example for US-primary service: us-east-1, eu-west-1, ap-southeast-1
  - Example for EU-primary service: eu-west-1, us-east-1, ap-northeast-1

单独跟踪各区域的延迟——全球平均值会掩盖区域性性能下降。

Regional latency dashboard:
  Region       | P50    | P95    | Status
  us-east-1    | 120ms  | 340ms  | healthy
  eu-west-1    | 280ms  | 620ms  | healthy
  ap-southeast | 450ms  | 1200ms | warning (P95 above threshold)

Alert when:
  - Any region's P95 exceeds its regional threshold
  - Latency difference between regions exceeds 5x (CDN or routing issue)
  - A region that was healthy becomes consistently degraded

CDN 验证。 合成探测通过检查响应标头（x-cache、cf-cache-status）是否为 HIT，并确认 server 标头与预期的提供商一致，来验证 CDN 缓存。这能在用户遇到缓慢的未缓存响应之前，发现 CDN 配置错误，以及被陈旧缓存掩盖的源站故障。

---

反模式

过于复杂、容易出错的探测

一个要浏览 10 个页面、填写 5 个表单并断言 20 个元素的探测，是 E2E 测试，而不是合成探测。它出错时，你无法判断是应用宕机还是探测不稳定。**解决方法：**每个探测只覆盖一条关键路径，耗时不超过 30 秒，断言不超过 5 个。出现故障时，应能立即看出问题所在。

每次失败都触发告警

网络短暂中断、DNS 故障和云服务瞬时问题偶尔会导致失败。每次都触发告警会产生噪声，让团队逐渐忽略告警。**解决方法：**连续失败 2-3 次，且至少有 2 个区域发生故障后再通知值班人员。按严重程度升级：首次失败记日志，第二次发出警告，第三次通知值班人员。

未隔离测试账户

多个探测共用一个账户会互相干扰——一个探测更改设置，另一个探测因预期默认设置而失败。**解决方法：**每个并发探测使用一个专用合成账户，标记为合成账户，并从分析和计费中排除。

只监控正常路径

只检查“页面已加载、返回 200”的探测会遗漏加载页面背后的功能故障。登录请求返回 200，但始终无法完成身份验证，并不代表登录正常。**解决方法：**对有意义的内容进行断言——数据已加载、身份验证成功、核心操作已完成、搜索返回结果。一个验证“用户能否完成目标”的探测，胜过十个验证“页面是否返回 200”的探测。

探测故障没有运行手册

凌晨 3 点触发了告警。值班人员看到“登录探测失败”，却不知道首先该检查什么、探测执行了什么，也不知道如何区分真实服务故障和探测问题。**解决方法：**每个探测都应链接到一份运行手册（测试内容；首要检查项——第三方状态、近期部署、应用遥测；手动复现；升级流程；仪表板链接）。参见 references/platforms-and-ci.md 中的模板。

新兴模式（2026 年）：由 Agent 驱动的首次响应。 Checkly Rocky（2026 年正式发布，可跨检查类型自动进行根因分析）和 Honeycomb Canvas Skills（Agent 可观测性，于 2026 年 5 月推出；开源的 honeycombio/agent-skill 仓库提供 honeycomb-investigator 和 instrumentation-advisor，适用于 Claude Code 和 Cursor）等工具会读取探测上下文、关联的运行手册和遥测数据，并在聊天中发布候选诊断。应将其视为分诊辅助工具——它能缩短常规故障的 MTTR，但不能取代值班人员对新型事件的判断。

---

故障模式

症状	可能原因	修复或检查
探测结果正常，但用户报告服务中断	探测仅断言 HTTP 200，未检查目标	添加内容／状态断言（仪表板标题、搜索结果数量、body.status）
告警反复触发和解除	没有连续失败或多区域规则	要求连续失败 2 次以上，且至少有 2 个区域确认后再通知值班人员
探测在本地通过，在 CI／区域环境中失败	特定区域发生中断或 CDN 路由问题	比较各区域结果；检查延迟差异和 x-cache 断言
探测失败，但实际并未中断	合成账户状态漂移（账户被共享）	每个并发探测使用一个独立账户；重置／填充稳定数据
源站已宕机，但探测结果仍正常	CDN 正在提供过期缓存	断言 cf-cache-status／源站 server 标头，而不仅仅检查 200
错误预算消耗，但没有事故	维护窗口被计为停机时间	维护期间暂停合成探测告警；在错误预算计算中排除该时间段
值班人员收到通知，却无法采取行动	告警缺少运行手册或手册内容为空	填写六行运行手册；确认 {link_to_runbook} 能正常解析
可靠性数据看起来好得不真实	合成流量被计为 SLO／RUM 中的真实流量	在 RUM、计费和错误预算管道中排除 is_synthetic 流量

---

验证

先进行最小检查，证明监控正常工作后再信任它。

1. 探测在预发布环境中通过。 在预发布环境运行 npx playwright test probes/ --reporter=list，确认每项探测均在声明的超时时间内通过（没有探测超过 30s 上限）。
2. 失败确实会触发通知。 将一项探测指向已知不可用的 URL（503 或错误路径），让它达到配置的连续失败次数，并确认告警在 SLA 检测时间内路由至值班人员；恢复设置后确认告警解除。
3. 断言有实际意义，而不只是检查状态码。 暂时破坏被断言的内容（在预发布环境重命名仪表板标题），并确认探测失败。如果此时探测仍显示正常，说明断言检查错了对象。
4. 合成流量已排除。 在分析／RUM／计费管道中查询 is_synthetic 流量，并确认其已被过滤。

---

完成标准

• 发现阶段确定的每条关键用户旅程都有对应探测（不只是首页可用性或单个健康检查端点），并且每项探测都断言目标，而不只是检查 2xx。
• 每项探测的实际运行时间预算低于 30s，并设置 retries: 0。
• 告警配置包含连续失败 ≥2 次规则和多区域确认规则，并为探测结果添加 severity + probe 标签，以便匹配路由。
• SLA 仪表板显示当前可用性和错误预算消耗情况，且 RUM、计费和错误预算管道均已排除合成流量。
• 测试告警（将探测指向失败的 URL）会在 SLA 检测时间内送达值班人员——已实际确认一次，而非仅作假设。
• 每项探测都链接到非空运行手册，其中包含初步检查、手动复现步骤和升级路径。
• 存在监控健康状况的定期检查任务或日历事项（而不只是打算进行检查）。

参考文件（位于 references/）

• probe-implementations.md — 可运行的登录流程、API 健康检查和搜索探测，以及了解环境的探测配置。
• platforms-and-ci.md — GitHub Actions 定时工作流、Checkly 配置、告警路由规则及标签说明，以及单项探测运行手册模板。

相关技能

• testing-in-production — 安全发布技术（标志、金丝雀发布、护栏指标）在发布期间应用；合成监控则是按计划持续运行的验证，在发布之后持续进行。
• release-readiness — 与特定版本关联的一次性部署后冒烟测试门控属于该技能；如需持续运行、按计划执行且在发布很久之后仍持续运行的版本，请参阅此处。
• observability-driven-testing — 使用生产遥测数据（包括这些探针产生的信号）作为输入来设计新测试；此技能则生成探针及其遥测数据。
• performance-testing — 负载测试按需测量容量；合成探针则在两次负载测试之间追踪生产性能趋势。
• qa-metrics — 探针产生的可用性、响应时间百分位数和错误预算消耗数据，会用于该技能定义的质量仪表板。
• ci-cd-integration — 如需将合成探针接入流水线，作为部署后验证阶段，请参阅该技能。