合成监控（Synthetic Monitoring）调研与实操：CI 门禁、大厂方案与自研方向

2025年9月19日 · 阅读需 12 分钟

coder

监控前端性能有两条路线：**真实用户监控（RUM）**采集真实用户的实际体验，合成监控（Synthetic）则用脚本/无头浏览器"模拟访问"页面，在受控环境里测性能。RUM 是"事后诸葛"，合成监控是"事前预防"——它能在发布之前、上线之后、甚至上线之前就发现性能退化。

本文调研合成监控的完整玩法：它和 RUM 怎么分工、第三方工具有哪些、怎么接进 CI 当"性能门禁"、大厂自研/开放的产品长什么样、以及如果你想自己搭一套，核心模块和最小实现是什么。

1. 合成监控是什么：和 RUM 怎么分工

维度	合成监控（Synthetic）	真实用户监控（RUM）
数据来源	脚本 / 无头浏览器模拟访问	真实用户的实际访问
环境	受控（固定设备/网络/机型）	不可控（五花八门）
时机	发布前、定时、可主动触发	发布后，被动采集
覆盖	覆盖不到真实长尾，但可复现	覆盖全量用户，但难复现
用途	CI 门禁、回归比对、竞品对标、可用性拨测	线上体验度量、报警、归因
成本	每次跑都要花钱（无头浏览器）	随流量走，边际成本低

两者的正确关系：合成监控是"最低门槛"——通过它才能发布，但它不代表生产环境满分；生产现实要用 RUM 来衡量。而且两者要相互校准：

合成指标漂移上升、RUM 平稳 → 怀疑实验室 profile（设备/限速配置）和现实偏离了；
RUM 漂移上升、合成平稳 → 存在合成没覆盖的用户群体（设备层级、地域、登录态），要补探测路径。

大厂实践（如汽车之家）印证了这套组合：合成监控进 CI 和发布流程，RUM 看线上真实体验。

2. 第三方工具全景

2.1 Lighthouse / Lighthouse CI（Google）

合成监控的事实标准。Google 维护，基于 Chrome DevTools Protocol，内置 94 条性能规则 + 16 条最佳实践，输出评分（Performance / Accessibility / SEO / Best Practices）和明细指标（LCP 元素、长任务、转移字节数）。核心价值是 Lighthouse CI——每次 commit / PR 自动跑，配上性能预算断言，超预算就阻断合并。

2.2 WebPageTest（Catchpoint）

擅长真实网络模拟：多地点、多设备、3G/LTE/Cable 等网络条件，产出 Waterfall 图、HAR、视频帧回放。能录制真实用户脚本（Selenium 风格），适合发布前跨地域压测和竞品对标。可托管私有实例。

2.3 sitespeed.io（Browsertime）

基于 CDP 的高性能采集引擎，深度集成 Lighthouse 审计，侧重 CI/CD 流水线内的快速反馈与回归比对，支持注入自定义指标。社区常把它和 WebPageTest 组合：一个快、一个准。

2.4 k6（Grafana）

虽然更多用于后端，但作为负载测试和定时拨测（HTTP/WebSocket）也能补前端合成监控的"接口层"短板，输出 RPS、p50/p95/p99 延迟、错误率。

2.5 商业 SaaS

产品	形态	特点
SpeedCurve	商业 SaaS	Lighthouse/WPT 的一站式托管 + 预算 + 趋势
Datadog Synthetics	商业 SaaS	全球探测点 + 浏览器/API 拨测 + 告警
New Relic Synthetics	商业 SaaS	与 APM/RUM 打通
腾讯云拨测	云产品	20 万+ 探测点、覆盖 2000+ 城市，可用性/网络质量/CDN 选型
阿里云 ARMS	云产品	RUM + APM + 智能洞察一体

2.6 一套开源工具链怎么协同

社区常见的"全栈性能测试框架"长这样（sitespeed + WebPageTest + k6 + Grafana）：

3. 实操一：Lighthouse CI 接入"性能门禁"

3.1 定义性能预算（双层：按指标 + 按体积）

.lighthouserc.json 里声明断言，达标才放行：

{
  "ci": {
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.85 }],
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
        "total-blocking-time": ["error", { "maxNumericValue": 200 }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
        "total-byte-weight": ["warn", { "maxNumericValue": 512000 }]
      }
    }
  }
}

更工程化的做法是独立的 budget 文件（budget.json），可以按路径配不同的包：

[
  {
    "path": "/*",
    "timings": {
      "largest-contentful-paint": { "error": 2500 },
      "total-blocking-time": { "error": 200 },
      "cumulative-layout-shift": { "error": 0.1 }
    },
    "resourceSizes": {
      "script": { "error": 512000 },
      "image": { "warn": 512000 }
    }
  }
]

3.2 接进 CI：commit / MR 时自动跑，超预算阻断

以 GitLab CI 为例，一个极简 job：

lighthouse-ci:
  stage: test
  image: cypress/browsers:latest     # 自带 Chrome
  script:
    - npm i -g @lhci/cli
    - lhci autorun --config=./lighthouserc.json   # 内置跑 Lighthouse + 断言 + 上报
  only:
    - merge_requests

流程：

效果案例（Lighthouse CI 官方实践）：把"每次引入新库"都纳入预算检查后，客户的 TBT 平均值从 2190ms 降到 200ms。核心原则是："系统应测量、系统应失败，人类只负责调查原因"——靠 code review 人工盯性能无法规模化，必须让 CI 自动拦截。

3.3 定时合成拨测：性能回归 + 可用性

CI 只在"有代码变更"时跑。线上还要定时拨测（每 6/12/24h），检测性能漂移和可用性：

基准环境：统一容器/硬件/网速（如汽车之家 4 核 + 4G + M 端统一 10M），保证结果可比；
设备与网络模拟：低端机（CPU 降速 4x）+ 弱网（3G）profile，暴露"实验室快、低端机卡"的问题；
漂移告警（业界最佳实践）：滚动基线（取最近 N 次夜间运行的中位数）+ 幅度阈值 + 持续性（连续 K 晚）——单次超阈值是噪声，持续超才是真回归。例如 P75 LCP 用"超基线 10% 且连续 3 晚"，CLS 数值小用绝对下限（基线 + 0.02）。

4. 大厂自研工具 / 开放产品调研

4.1 阿里云 ARMS：RUM + APM + AI 洞察一体

ARMS（应用实时监控服务）是阿里的一站式观测平台，前端相关能力包括：

用户体验监控（RUM）：Web/H5、小程序、移动端一键接入，页面/资源/接口/JS 错误分析，会话追踪；
APM 打通：应用拓扑、调用链、持续剖析（Profiling）；
智能洞察：基于 LLM 的根因分析和优化建议、告警收敛；
2025 年演进：3 月发布业务链路分析、7 月新增页面秒开率指标、兼容 OpenTelemetry/Prometheus/Grafana Tempo。

4.2 腾讯云前端性能监控（RUM）+ 云拨测

腾讯的路径是"亿级流量验证过的 SDK 开放成云产品"：

前端性能监控 RUM：宣称日上报量 4000 亿级、上百亿 PV，一行代码接入，覆盖 Web/小程序/React Native/Hippy/Flutter；
2025 年 2 月 RUM + APM 全链路：RUM SDK 通过 injectTraceHeader 透传 TraceId（支持 Traceparent / sw8 / b3 / Sentry-Trace），前端日志和 APM 调用链无感打通，前后端都用 OpenTelemetry 上报即可；
云拨测（合成监控 SaaS）：20 万+ 探测点、覆盖全球 2000+ 城市运营商，PC/手机端拨测，常用于网络质量评估、CDN 选型、域名劫持监测。

4.3 汽车之家：自研 SYN 服务的实战细节

汽车之家的合成监控是自研 + 工程化的代表，几个关键设计：

Web 版 SYN 服务部署在容器里，用队列策略保证单容器同时只跑一个任务，统一硬件（4核+4G）和网速（M 端 10M）——基准统一，结果才公平；
计划任务调度：按 6/12/24 小时间隔跑，统计多次结果的 AVG/TP 排除异常值；
加权评分体系：给各指标设基线和权重，加权求和应用得分，再按 PV 数向上聚合成团队 → 部门 → 公司层级得分，管理层一眼看懂性能状况；
进 CI/QA 套件：作为上线前页面性能测试和竞品对比工具。

4.4 大厂做法的规律

把各家放一起看，规律其实非常一致：先自建"埋点 SDK + 上报链路 + 大盘告警"三件套服务内部，验证成熟后开放成云产品（ARMS、腾讯云 RUM/拨测）。自研和云产品的关系不是二选一，而是"内部用自研、对外卖云"——你如果在大厂内部，往往直接用自家这套；外部团队则可以借云产品快速起步。

5. 自研方向：自己搭一套合成监控

如果你不想用整套商业产品，从零自建的最小闭环只需要五个模块：

调度器：定时（cron/队列）触发探测，也可被 CI 调用；
探测执行器：无头浏览器跑页面——Puppeteer / Playwright（采集层）/ Lighthouse（审计层）；
采集：Navigation Timing、Resource Timing、PerformanceObserver（CLS/长任务），最后断言预算；
存储 + 大盘：InfluxDB/Prometheus + Grafana；
告警：阈值 + 滚动基线漂移。

一个最小实现（Node + Puppeteer + Lighthouse Node API，约 30 行，可直接进 CI）：

const lighthouse = require('lighthouse');
const puppeteer = require('puppeteer');

const BUDGET = {
  'largest-contentful-paint': 2500,      // ms
  'total-blocking-time': 200,            // ms
  'cumulative-layout-shift': 0.1,
};

(async () => {
  const browser = await puppeteer.launch({ headless: 'new' });
  const { lhr } = await lighthouse('https://your.site', {
    port: new URL(browser.wsEndpoint()).port,
    output: 'json',
    throttling: { cpuSlowdownMultiplier: 4 },   // 模拟低端机 CPU
    screenEmulation: { mobile: true, width: 375, height: 667 }, // 移动端视口
  });

  const failed = Object.entries(BUDGET).filter(([id, max]) => {
    const v = lhr.audits[id]?.numericValue ?? Infinity;
    console.log(`${id}: ${v.toFixed(v < 1 ? 3 : 0)} (预算 ${max})`);
    return v > max;
  });

  console.log(failed.length ? `❌ 超预算: ${failed.map(([id]) => id).join(', ')}` : '✅ 达标');
  await browser.close();
  process.exit(failed.length ? 1 : 0);   // 超预算 → 非零退出 → CI 失败
})();

自研的进阶方向（按投入递增）：

多环境/多地域：staging + prod、多个探测点；
多 profile：低端机 + 3G 的"最差情况"探测，和"最好情况"分开看；
回归比对：每次结果和上次/基线 diff，输出 Lighthouse 差异报告；
与 RUM 校准：把合成指标和线上 RUM 的 P75 放同一个大盘，发现偏差及时调 profile；
开放上报：自研的探测结果也可对接到现有 RUM/APM 体系，形成"合成预警 + 真实验证"闭环。

什么时候别自研：如果你只需要"几个关键页面 + 达标即发布"，Lighthouse CI 就够了；需要多地域多设备拨测，直接用商业 SaaS / 云拨测（探测点成本自建根本没法比）。自研的价值在于：和自家 CI/发布链路深度耦合、指标口径完全可控、可以插进内部平台。

6. 一句话总结

合成监控是"受控环境里的模拟访问测性能"，和 RUM 分工明确：合成管"发布前/回归/竞品对标"，RUM 管"线上真实体验"，两者必须相互校准。第三方工具选型：CI 快速反馈用 Lighthouse CI（性能预算断言，超预算阻断合并），真实网络模拟用 WebPageTest，采集引擎用 sitespeed.io，接口层补 k6；大厂层面，阿里 ARMS、腾讯云 RUM + 云拨测 把内部验证过的"SDK + 上报 + 大盘 + 告警"开放成云产品，汽车之家则展示了自研 SYN 的工程细节（统一基准、定时调度、加权评分聚合）。自研方向只有五个模块：调度器 → 探测执行器 → 采集断言 → 存储大盘 → 基线告警，一个 Lighthouse Node API 的 30 行脚本就能进 CI 当门禁。原则就一条：让系统测量、让系统失败，人类只负责调查原因。

参考

Lighthouse CI（Google）：性能预算 + CI 门禁 / Lighthouse 审计规则
WebPageTest：多地域 / 多网络真实模拟、Waterfall、HAR
sitespeed.io：CDP 采集 + Lighthouse 集成，CI 快速反馈
Grafana k6：接口层 / 负载拨测
阿里云 ARMS（RUM + APM + 智能洞察）
腾讯云前端性能监控 RUM / 腾讯云拨测（20 万探测点）
汽车之家：页面性能监控建设实践
前端性能监控与 RUM：见本博客《前端 RUM 真实用户监控》

1. 合成监控是什么：和 RUM 怎么分工​

2. 第三方工具全景​

2.1 Lighthouse / Lighthouse CI（Google）​

2.2 WebPageTest（Catchpoint）​

2.3 sitespeed.io（Browsertime）​

2.4 k6（Grafana）​

2.5 商业 SaaS​

2.6 一套开源工具链怎么协同​

3. 实操一：Lighthouse CI 接入"性能门禁"​

3.1 定义性能预算（双层：按指标 + 按体积）​

3.2 接进 CI：commit / MR 时自动跑，超预算阻断​

3.3 定时合成拨测：性能回归 + 可用性​

4. 大厂自研工具 / 开放产品调研​

4.1 阿里云 ARMS：RUM + APM + AI 洞察一体​

4.2 腾讯云前端性能监控（RUM）+ 云拨测​

4.3 汽车之家：自研 SYN 服务的实战细节​

4.4 大厂做法的规律​

5. 自研方向：自己搭一套合成监控​

6. 一句话总结​

参考​