前端监控该「全公司一套统一 SDK」还是「各业务线自选 + 上报协议对齐」？

背景

我在前端做了 10 年，带过 3 个不同体量的团队，每个团队都问过同一个问题：我们的前端监控（性能 / JS 错误 / 资源加载 / 白屏 / 接口埋点）到底是接公司统一的那一套 SDK，还是自己挑（Sentry、ARMS、自研）？

我观察到的一个反复出现的现象是：统一 SDK 在「立项时」看起来最省——一个包、一套文档、一套后端聚合；但落地到第 3~6 个月，业务线开始抱怨的往往是：

• 上报字段被锁死，想加个「业务自定义维度」（比如灰度桶、A/B 分组）要走 2~4 周流程；
• SDK 体积 30~80KB，对性能敏感的 C 端页面是硬成本；
• 采样策略、白名单、脱敏规则都是中心化的，业务线只能「接受」或「不用」；
• 升级节奏跟业务线发布节奏冲突，一次强制升级可能踩到线上 bug。

而自选路线的问题也很真实：3 条业务线 3 套 SDK，后端聚合 3 套，告警 3 套，故障排查时跨线对齐字段语义（比如「错误率」到底是 5xx 还是含超时）能吵一整天。

常见分歧 / 几种做法

1. 全统一：公司出一套 SDK + 一套上报协议 + 一套聚合，业务线零选择。优点是治理简单、跨线数据可对齐；缺点是上面列的那一堆摩擦。
2. 协议统一、实现自选：只对齐「上报 schema + 采样语义 + 脱敏基线」，SDK 自己挑。优点是灵活；缺点是语义漂移，半年后字段又开始各说各话。
3. 分层：错误 / 性能这类「平台数据」统一；业务埋点 / 自定义维度自选。折中，但边界怎么划本身就是个政治问题。
4. 完全自选 + 事后对齐：很多创业公司早期是这么干的，规模到 50+ 前端后通常要回炉。

我的倾向

我倾向 3（分层），但前提是「平台数据」那一层的 SDK 必须满足两个硬指标：

• 体积 ≤ 15KB gzip（这是 C 端页面的硬约束，超过就没人愿意接）；
• 业务自定义维度开放（不需要走审批，业务线自己声明、自己负责脱敏）。

理由：错误和性能这类数据天然是「平台资产」，跨线对齐的价值 >> 单线自由度；但业务埋点是「业务资产」，强行统一只会逼出影子 SDK。

想听大家

• 你们所在团队是哪种做法？踩过的最大坑是什么？
• 「统一 SDK 体积超 30KB」在你们那里是怎么被接受的 / 拒掉的？
• 协议对齐这件事，谁来做？（前端平台组？SRE？还是各线各管？）
• 有没有人尝试过「统一 SDK + 插件化业务埋点」？效果如何？