New Relic vs Sentry：错误变成 Issue 之后，怎样走到修复

同一个 JavaScript 异常一小时出现几千次，开发者真正需要的通常不是几千封通知，而是一个能分派、能找到源码位置、能判断修复是否生效的问题。错误事件进入平台，只完成了这条路径的第一步。

Sentry 把错误组织成 Issue，再连接源码、版本和负责人，是它值得关注的工作方式。New Relic 同样有 Errors Inbox、错误分组与应用上下文，不能简化为“只看系统、不管代码”。选择要看团队的工作主要卡在错误修复，还是卡在跨服务与资源的调查，而不是把两家放进互不重叠的类别。

本文由观测云编辑部根据 2026 年 10 月 27 日官方资料撰写，以 SaaS 为主要比较范围，另说明自建 Sentry 的边界。没有测试哪家分组算法更准，也没有测量修复效率。

一个 Issue，不等于一种确定的根因

Sentry 按 fingerprint 将事件归入 Issue。默认规则参考堆栈、异常与消息，必要时可用项目规则或 SDK fingerprint 调整。合并已经存在的 Issue，与改变新事件的分组规则是不同操作；后者不会自动重新整理全部历史问题。Sentry 分组规则

New Relic 的 Errors Inbox 也按 fingerprint 建立 error groups，规则会参考账户、实体、错误信息与堆栈等。自定义 error.group.name 可以影响分组。同一应用若被建成多个实体，外观相似的错误也可能落入不同组。New Relic Error tracking

因此，同样写着“请求失败”的两条错误，可能来自不同调用点；带有不同订单号的两条错误，也可能只是同一种故障。把易变的业务 ID 放在属性里，比把它塞进错误标题更利于稳定分析。分组减少了待处理条目，但没有替工程师证明原因，也不能把一组中的事件次数直接当成独立受影响用户数。

源码可读性要在构建时准备

Sentry 的浏览器 JavaScript Source Map 流程要求生成并上传与部署产物匹配的映射。当前推荐工具可向构建产物注入 Debug IDs，用于把运行中的文件与上传内容对应起来。映射应随实际生产构建进入发布流程，不要等出错之后才拿另一次构建的文件补传。Sentry Source Maps

New Relic Browser 也有 Source Map 上传 API，可将映射与应用及相应 JavaScript 文件关联。它并非没有还原压缩代码的能力。New Relic Source Map API

这里的共同问题是产物一致性。相同源码重新构建后，chunk 名称、内容哈希或行列位置可能变化。报错所使用的脚本必须能对应到那次部署的映射。能看到一条堆栈，与能定位到正确源码版本，是两个不同结果。

Sentry 的 Suspect Commits 进一步把堆栈中的应用代码关联到仓库提交，需要相应源码映射、仓库集成与 code mappings 等条件；也有手工提供提交信息的路径。它给出的是调查线索和建议负责人，不是证明该提交引入错误的结论。当前文档也将这一功能限定在 error issues。Suspect Commits

错误之外，两家都有更多信号

Sentry 已有 Tracing、Logs、Session Replay 等产品，不能继续描述为只接收异常。Logs 可以与错误、spans 和 traces 一起调查；是否完整仍取决于 SDK、采集配置和实际保留的数据。Sentry Logs

New Relic 的 Errors Inbox 可以汇集 APM、Browser、Mobile 与 Lambda 错误，并从错误详情进入相关链路和日志。已经建立应用与基础设施调查路径的团队，可以先看看这条现成路径是否已经满足修复工作，再决定是否添加 Sentry。

跨浏览器、后端与日志的关联都需要共同标识。Trace 被采样丢弃，错误记录可能仍在；有错误并不保证能找到完整调用链。Sentry 的数据丢弃说明区分客户端采样、过滤与其他丢弃原因，不能仅凭界面上的一条统计就推断原始事件从未发生。Sentry 数据丢弃说明

观测云的 RUM 错误查看器也提供 Source Map 与错误详情入口，便于把前端错误带回会话、页面或相关请求。需要结合后端调查时，再把应用链路及关联标识接好。错误聚类、源码还原与跨信号调查各解决一段工作，不能据此承诺自动复制 Sentry 的全部 Issue、提交和分派流程。

计费单位决定该控制哪类数据

Sentry 当前分别列出错误、spans、日志、Application Metrics、replays 等用量，并为不同计划提供相应额度。一个请求可能生成多个 spans，错误事件也不等于唯一 Issue 数。只统计 Issue 数量，会低估实际采集量。Sentry 价格

New Relic 当前有 Data + User 和处于 Public Preview 的 Data + Core Compute，并有按能力计量的附加项。团队需要的是哪些界面、多少数据以及怎样使用平台，应一起进入报价。New Relic 计费

减少重复报错、过滤确定无用的记录可以控制用量，但规则过宽会掩盖新问题。前端错误、后端 spans、日志与回放不必采用相同采样策略；先明确每类数据承担的工作，再决定保留范围。两套平台同时运行，还要算上双份数据和两套告警、版本与人员映射的维护。

自建与同时使用，都需要明确负责人

Sentry 有自建分发版，但它不是零运行成本的 SaaS 替代品。部署、升级、备份及依赖服务的运行需要团队负责，功能和许可也应以自建版本为准，不能把云端产品清单直接视作全部包含。Sentry 自建说明

如果修复工作围绕 Issue 分派、源码与提交展开，Sentry 的方式值得优先采用；尤其当工程师每天需要维护这个问题队列时，流程一致性本身就有价值。如果团队主要从服务异常进入链路、日志和资源，New Relic 已经保留了这些证据，就先把 Errors Inbox 和构建关联配置完整。

同时使用并非错误，但需要有明确收益。让一套负责开发者的问题队列，另一套负责运行状态调查时，应约定版本号、服务身份和交接链接，并避免两边重复通知。增加平台应该缩短从问题到修复的路径，而不是再增加一个无人清理的错误列表。