错误跟踪系统建设的必要性与路径分析

• 版本：v1.0（终稿）
• 更新日期：2026-10-07
• 讨论组：Claude（主持 Sonnet 5 ×2、核验 Opus 5.5）、Codex（gpt-6.1-sol，质疑席）、Antigravity（gemini-3.8-flash-high，顾问席）

一、结论 #

1. 错误跟踪的价值不在“采集异常”，而在“管理缺陷”。 日志、APM、OpenTelemetry（OTel）都能采集异常；错误跟踪系统提供的是另一层能力：按指纹聚合去重、识别首次出现与回归、关联发布版本与可疑提交、还原压缩或混淆后的堆栈（Source Map、dSYM、ProGuard），以及指派、状态流转和修复验证。
2. 已有 APM 不等于不需要，但也不等于要另建一套。 是否建设看缺口，而不看“有没有 APM”：
   • 现有 APM 已含错误跟踪模块，且覆盖实际终端（后端、Web、移动端）→ 先启用并验证该模块，不另建；
   • 有 Web、移动端、小程序等客户端，而现有体系没有对应的崩溃采集与符号化能力 → 需要补建，这是最硬的理由；
   • 只有 Trace/日志检索、缺少聚合与缺陷工作流，且发布频繁、多团队协作 → 需要补建。
3. 路径： 按“现有 APM 错误模块 → SaaS → 自托管”的顺序评估，不从零自研；先小范围试点并用指标决定是否推广。负责人、分诊时限、发布关联和数据脱敏是成败关键，缺了这些，系统只会变成没人处理的告警池。
4. 决策层级要区分。 单个产品团队可直接按上述条件选型；平台级标准化还须统一 SDK 规范、脱敏基线、权限和费用分摊，组织成本明显更高，宜先由一两个团队试点再推广。

“错误跟踪不如 APM 普及”目前只是观察，讨论组没有找到可靠的普及率统计，不作为论据。

二、能力边界 #

要点：

• OTel 只规范采集。 其异常语义约定定义了 exception.type、exception.message、exception.stacktrace，并提示异常消息可能含敏感信息；没有定义问题聚合与生命周期[1]。因此“已接入 OTel 就不需要错误跟踪”不成立。
• 主流 APM 已把错误跟踪做成内置模块，说明两者互补而非替代：Datadog Error Tracking 把相似错误聚合为 Issue，展示首次出现时间、受影响用户数与可疑提交，来源覆盖 APM、浏览器与移动 SDK、日志和 RUM[2]；New Relic Errors Inbox 按指纹分组，支持指派、忽略、标记在指定版本解决，覆盖 APM、浏览器、移动端和 Lambda[3]。已采购这类 APM 时，应先核对该模块是否在合同内。
• 打通而非合并。 错误事件携带 trace_id，可从错误跳转到调用链。但不要假设一份 OTel 数据能直接喂给专用错误跟踪系统：OTel 原先把异常记为 Span 事件，该约定已弃用、改为记入日志，过渡期由配置开关决定输出哪种[12]；而 Sentry 的 OTLP 接入仍为公开测试版，接入时丢弃全部 Span 事件[4]。接入前须按目标产品文档验证异常数据的实际去向。

flowchart TD
    A["盘点：现有 APM/RUM 的错误能力与覆盖终端"] --> R{"命中第三节<br/>不建或缓建情形？"}
    R -- "是" --> X["不建或缓建"]
    X -.->|"条件变化时重新盘点"| A
    R -- "否" --> B{"现有模块能聚合去重、<br/>关联版本、指派闭环？"}
    B -- "能，且覆盖全部终端" --> C["启用并验证现有模块<br/>不另建"]
    B -- "不能，或缺客户端/符号化" --> D{"数据能否交给第三方 SaaS？"}
    D -- "能" --> E["SaaS 试点"]
    D -- "不能" --> F{"有运维 Kafka/ClickHouse<br/>等组件的能力？"}
    F -- "有" --> G["自托管 Sentry 试点"]
    F -- "没有" --> H["轻量自托管（如 GlitchTip）<br/>或其他合规产品"]
    E --> I["试点 4–6 周：达标则推广，<br/>不达标则重评缺口"]
    G --> I
    H --> I
    C --> I

三、适用条件与反例 #

适合建设： 有面向用户的 Web/移动端；每周或更频繁发布，回归识别有价值；多团队共用服务，需要把错误自动派给负责人；偶发故障多，仅看服务端错误率容易漏掉少量用户的持续失败。

不建或缓建：

• 纯后端服务，现有 APM 错误模块已覆盖聚合与指派；
• 低变更的遗留系统、离线批处理，作业失败告警加日志已能闭环；
• 没有修复负责人和分诊时限，上线只会增加噪声。

缓建后若新增客户端、明确负责人或发布加快，应重新盘点。需另建而数据须内留、又缺重型组件运维能力时，SaaS 与重型自托管都不适用，应评估轻量方案，而非不建。

四、如何建设 #

1. 选型

许可证需准确表述：Sentry 主应用采用 FSL（Functional Source License），官方明确它不符合 OSI 的开源定义，两年后转为 Apache-2.0[9]。报告和内部文档应写“源码可得、可自托管”，不宜写“开源 Sentry”。

2. 落地步骤

1. 盘点现有 APM/RUM 的错误能力与终端覆盖，按第三节判断是否建设；
2. 选一个客户端应用和一个关键后端试点 4–6 周：接入 release、environment、服务标识和 trace_id，在 CI 中上传与版本匹配的 Source Map/符号文件；
3. 先建立基线，再比较新回归从出现到发现的时间、定位与修复时间、聚类准确率、有效告警比例和总成本；达不到约定门槛就不推广。

3. 数据安全

• 默认不采集请求体、凭据、Cookie、完整 URL 查询参数、局部变量；附件和会话回放单独评估，默认遮蔽输入；
• 在 SDK（如 beforeSend）或自控网关出站前脱敏，服务端过滤只作补充。Sentry 官方说明：若要求“数据绝不能离开我方系统”，不要依赖其服务端脱敏，附件与回放另有各自的隐私机制[10]；
• 上线前用合成的令牌、邮箱，分别验证错误事件、附件和回放的实际出站内容；
• 权限要实测而非只看配置：New Relic 文档说明，Errors Inbox 的标准角色限制只作用于错误组评论，只读用户仍可指派问题、修改状态[3]。同时配置项目隔离、最小权限、SSO/MFA、审计、保留与删除策略；
• Source Map 只上传给错误跟踪系统，不随公网产物发布；保护符号文件和上传令牌。

4. 组织配套

• 用 CODEOWNERS 或服务目录自动指派负责人，研发对自己代码产生的新问题负责；
• 按用户影响、关键业务失败和新版本回归分级：只有需立即处置的进入值班，其余进入缺陷队列；
• 把新问题和回归数纳入发布评审。

关于收益数据： Sentry 客户案例称 Forethought 通过代码负责人和每周审查，把解决时间“最多缩短 94%”[11]。这是厂商发布的单个案例，未经独立核验，不能作为通用 ROI；收益应以本组织试点数据为准。

讨论中未被采纳的不同意见见附录 A。

参考来源 #

访问日期均为 2026-10-07。

1. OpenTelemetry，Semantic conventions for exceptions in logs：https://opentelemetry.io/docs/specs/semconv/exceptions/exceptions-logs/
2. Datadog，Error Tracking 文档：https://docs.datadoghq.com/error_tracking/
3. New Relic，Errors Inbox 文档：https://docs.newrelic.com/docs/errors-inbox/errors-inbox/
4. Sentry，OTLP 文档：https://docs.sentry.io/concepts/otlp/ ；Traces：https://docs.sentry.io/concepts/otlp/direct/traces
5. Sentry，Self-Hosted Sentry：https://develop.sentry.dev/self-hosted/
6. Sentry，Application Architecture Overview：https://develop.sentry.dev/application-architecture/overview/
7. GlitchTip 官网：https://glitchtip.com/
8. GlitchTip，Installation：https://glitchtip.com/documentation/install
9. Sentry，Licensing：https://open.sentry.io/licensing/
10. Sentry Help Center，What are Sentry's data scrubbing options：https://www.sentry.help/en/articles/13964268-what-are-sentry-s-data-scrubbing-options
11. Sentry，Forethought 客户案例：https://sentry.io/customers/forethought/
12. OpenTelemetry，Semantic conventions for exceptions on spans（状态：已弃用，改用 [1]）：https://opentelemetry.io/docs/specs/semconv/exceptions/exceptions-spans/

附录 A：少数意见 #

1. 顾问席（agy）： 前端、移动端“必须独立建设”，中大型组织宜选自托管。多数意见认为，只要现有 APM 的浏览器/移动模块已覆盖崩溃采集、符号化和缺陷工作流，就不必独立建设[2][3]；是否自托管取决于合规要求与运维能力，而不是组织规模。
2. 研究综合主持席： 已重度投入 OTel 的组织，可先用 OTel 采集的异常（Span 事件或日志）加日志关联做“轻量错误跟踪”，聚合或符号化成为明显痛点后再引入专用系统。多数意见认可“先复用”，但指出这种做法没有缺陷工作流；而且如第二节所述，OTel 异常记录方式正在从 Span 事件迁往日志[12]，部分专用产品的 OTLP 接入又不接收 Span 事件[4]，后续迁移需单独规划采集。
3. 核验席： 估计自托管 Sentry 约需 0.3–0.5 人运维。该数字没有可核查数据，仅供参考。

附录 B：篇幅统计 #

• 口径：正文指一至四节（第一节标题至“讨论中未被采纳的不同意见见附录 A”一句），不含 mermaid 源码、参考来源和附录；分别统计汉字数，以及“汉字 + 英文单词/数字串各计 1 字”的数，两者均计入表格内文字。
• 切分规则：汉字按 Unicode 区间 [\u4e00-\u9fff] 逐字计数；英文单词/数字串按正则 [A-Za-z0-9][A-Za-z0-9._/\-]* 计数，以点、下划线、斜杠、连字符相连的整体算 1 个（如 exception.type、SSO/MFA），4–6 中的连接号“–”不在其内，计 2 个。计数脚本随讨论记录归档，在 v0.2 上复算结果与下文所列 v0.2 数字一致。
• v1.0 结果：汉字 1860；汉字加英文单词/数字串（含引用编号）1999，未超过 2000 字。
• 历史版本（同口径）：v0.3 与 v1.0 数字相同；v0.2 为汉字 1828、合计 1965；v0.1 一至四节为汉字 1689、合计 1819，加上原第五节后汉字为 1920。
• 质疑席第 2 轮报告 v0.1 一至五节汉字 2034，与本口径不同（未说明是否计入 mermaid 等），差异原因未能确认。