前端可观测性不是“埋点工具”：我们如何构建指标闭环

这篇文章记录我们在十月完成的可观测性改造：目标是让前端团队对性能、错误、用户体验有“实时可见 + 可追溯 + 可复盘”的能力。工具不是重点，体系才是。

1. 限定边界与目标

三个核心问题：

用户是否能在 3 秒内看到首屏？
前端错误出现时，我们能定位到具体版本与用户？
产品指标（转化、留存）与体验指标如何关联？

我们设定的 SLO：

FCP P75 ≤ 1.8s
JS 错误率 ≤ 0.8%
页面崩溃率 ≤ 0.2%

2. 数据采集层

性能指标：使用 PerformanceObserver 收集 FCP/LCP/CLS/INP；
错误捕获：window.onerror + unhandledrejection + 自研 SDK；
用户行为：点击路径、关键交互时间、A/B 实验分组；
环境信息：浏览器、操作系统、网络类型、版本号。

SDK Stub：

const beacon = new BeaconClient({ endpoint: 'https://obs.example.com' })

performance.observe('largest-contentful-paint', entry => {
	beacon.send('web_vitals', {
		type: 'LCP',
		value: entry.value,
		url: location.pathname,
		version: window.__APP_VERSION__
	})
})

window.addEventListener('error', (e) => {
	beacon.send('js_error', {
		message: e.message,
		stack: e.error?.stack,
		version: window.__APP_VERSION__,
		feature: currentFeatureFlag,
	})
})

3. 传输与存储

采集端通过 navigator.sendBeacon 上报，减少对主线程影响；
服务端使用 ClickHouse 存储高基数数据，Postgres 存业务指标；
引入 Kafka 作为缓冲层，后续可做实时计算（如异常告警）。

架构图：

1	Browser SDK → Nginx (intake) → Kafka → ClickHouse / Postgres → Grafana / Superset

4. 指标与看板

4.1 技术指标 Dashboard

核心指标：FCP、LCP、INP、错误率、崩溃率；
维度拆分：浏览器、版本、地域、Feature Flag；
告警：Prometheus Operator 订阅 ClickHouse 导出的时间序列。

4.2 产品指标 Dashboard

埋点与订单、留存数据结合，回答“体验变好是否带动转化”；
Dbt 定时生成对比报表，发给产品经理。

4.3 版本对比页面

提供一个“版本雷达图”界面，比较上一个版本与当前版本的指标差异；
支持 drill-down 到具体页面、具体用户 session。

5. 运维与治理

所有指标定义写成文档 + Schema（类似 OpenAPI），防止名字漂移；
每次大版本上线前，必须在预发环境跑一次端到端体验测试：k6 + Lighthouse CI；
每月一次事故演练：注入伪造错误，验证告警链路和 On-call SOP。

常见问题：

数据泛滥：上线初期我们采了太多日志，ClickHouse 磁盘涨得很快，后来通过 TTL + 采样解决；
版本映射：确保每次构建把 Git SHA 写进全局变量，定位问题不再靠猜；
隐私合规：对用户字段做脱敏，遵守《个人信息保护法》。

6. 总结

可观测性不是买个工具，而是把“采集 → 传输 → 存储 → 呈现 → 行动”五步走通。我们现在做到：

30 分钟内定位绝大多数线上问题；
SLO 超标会自动触发金丝雀回滚；
产品可以直接看到体验指标对业务的影响。

下一步计划引入 OpenTelemetry 做端到端 tracing，把前后端链路串起来。

琅琊苑