Dynatrace vs Sentry：一次失败发布，该从错误追到哪里

新版本上线十分钟后，结算页开始报错。前端同事看到一段压缩后的 JavaScript 堆栈，后端同事则发现支付接口延迟上升。两个现象可能来自同一次故障，也可能只是同时发生。此时最需要的不是再增加一个总览面板，而是把错误、发布版本、受影响请求与服务运行状态连接起来。

Dynatrace 和 Sentry 都能参与这段调查，只是入口与工作重心不同。Sentry 的 Issue 工作流适合沿具体异常推进修复；Dynatrace 可以从受支持的应用、进程与主机上下文继续追查。把二者简单分成“运维用”和“开发用”，容易忽略真正决定工具是否好用的接入条件与责任交接。

观测云编辑部 · 资料核对日期：2026 年 10 月 21 日。以下场景用于解释调查路径，没有进行产品性能或成本实测。

错误被归为一组，还不等于根因已经确定

Sentry 会把具有相同 fingerprint 的事件归入 Issue。默认分组会利用堆栈、异常和消息等信息，也允许通过规则或 SDK 调整。这样可以把重复错误变成可分派、可跟踪的问题，而不必逐条翻阅日志。但分组只是调查的组织方式：一组错误不必然只有一个业务原因，多个 Issue 也可能来自同一次发布。Issue 分组。

对于结算页，第一件实事是拿到可读的应用堆栈。Source Map 必须对应实际部署的构建产物；当前推荐的 Debug ID 路径用于把事件与相应文件关联起来，文件需要及时上传。上传了另一次构建的文件，或错误发生时还没有对应产物，都会影响还原。JavaScript Source Maps。

看见源代码行以后，仍要判断它是产生问题的位置，还是接收到坏结果的位置。接口返回缺少字段，可能在前端解构时才抛错；修复一个空值判断可以缓解页面崩溃，却未必解释后端为什么漏字段。版本与负责人线索有助于分工，不能代替请求和数据的核验。

沿请求走到哪里，由采集决定

Sentry 不只做错误上报，当前产品还包含 Traces、Session Replay、Profiling、Logs 与 App Metrics 等能力；不同数据有各自的接入及消费范围。选型时仍把它描述成只有错误数量，已经过时。当前产品与方案。

不过，安装错误 SDK 不等于完整请求已经被记录。以 JavaScript SDK 为例，错误采样与事务采样是不同设置：sampleRate 控制错误事件，tracesSampleRate 或 tracesSampler 控制事务采样。官方说明后两者都未设置时，不发送事务；跨服务还要保留采样继承与上下文传播。JavaScript 采样。

这解释了常见的困惑：错误存在，旁边却没有足够的链路。排查时先确认 SDK、环境、采样和传播，再判断分析界面是否缺能力。把采样临时调高，也应观察数据量与应用开销，不能默认永远全量最合适。

Dynatrace 的 Full-Stack 在受支持的 OneAgent 环境里，可进一步提供代码级、进程与 CPU/内存剖析信息。支持范围取决于运行时和监控模式；它也接受 OTel 数据。仅通过 OTLP 送入一条 Trace，不能自动获得 OneAgent 原来提供的所有信息。Full-Stack、支持矩阵、OTel 接入。

在这个例子中，Sentry 可以帮助确认哪个页面、哪种错误值得优先修复；如果问题继续指向服务端等待或资源压力，团队应确认现有后端证据是否足够。也不应反过来认为有主机指标就无需理解浏览器里的失败过程。

回放与通知，需要进入发布流程

Session Replay 能补充用户操作时的上下文，但不能把采集到的页面直接视为可无限使用的数据。Sentry 浏览器 Replay 默认对文本和输入做遮罩、阻止媒体内容，仍要求上线前核验遮罩配置；网络请求和响应正文的采集是需要主动开启的功能。Replay 隐私配置。

实际接入时，应拿结算页、地址表单和第三方嵌入区域验证：什么内容保留了，什么内容被隐藏，调试人员是否仍能理解步骤。版本升级或组件重构后，这个验证也要继续。回放缺少一段文字有时是正确的保护结果，不应为了方便排障一概关闭遮罩。

Sentry 也有告警，不能沿用“没有告警、只能被动看错误”的说法。当前 Alerts 可以围绕 Issue 与 Monitor 事件设置条件和动作，通过支持的集成发送通知、创建工单或调用 webhook。具体可用动作仍取决于集成和方案。Alerts。

真正需要设计的是谁先收到、何时升级、何时关闭。若页面错误与后端故障分别通知两支团队，最好共享一个可定位的请求或发布标识，并约定主事件负责人。否则两套产品各自运行正常，响应过程仍会重复或遗漏。

自托管是另一项工程，而不是免付费开关

Sentry 提供自托管部署，但官方 Docker Compose 基线以低流量与验证为目标，并不提供高可用或规模化保证。数据库、消息处理、备份、升级与故障恢复都需要运营方负责；SaaS 与自托管也并非功能完全相同，例如 Seer 的专有 AI/ML 组件不包含在该自托管方案中。自托管说明。

当前 Sentry 的相关代码采用 Fair Source 的 FSL 路径，文档说明相应版本两年后转为 Apache 2.0；不宜把最新整套产品笼统写成 Apache 开源版。是否满足某种部署与使用要求，应核对对应版本和组件，而不是只看到仓库公开就下结论。

部署在自己的环境里，意味着能控制更多数据路径，也意味着事故时需要恢复观测系统本身。对主要目的是修复前端回归的小团队，这项工作可能比 Issue 页面是否顺手更影响选择；已有专门平台运维能力的组织，则可以做不同安排。

预算应跟着启用的调查路径走

Sentry 的账单不能只看错误事件。当前公开方案列出 Errors、Spans、Logs、App Metrics、Replays、Profiling 等不同用量，套餐、包含量与超额设置也影响结果。一次错误风暴可能与链路或回放增长同时发生，不能把各项成本假设为同一个事件单价。定价说明。

Dynatrace DPS 的主机 Full-Stack 则按 GiB-hours 计量，使用十五分钟区间、0.25 GiB 整数倍向上取整和每主机 4 GiB 下限；日志等能力另计。两者计量对象不同，不能把一个基础套餐直接与完整平台账单相减。DPS 规则。

可以先用结算服务的一次发布周期核对需要启用哪些能力，再观察正常流量与故障高峰。保留两者时，也应清楚哪些数据是为了不同调查任务而重复采集，哪些只是历史配置遗留。

让修复与运行证据接得上

如果主要痛点是从异常、版本和用户操作推进代码修复，Sentry 值得优先试用；如果调查反复停在应用与进程、主机之间，Dynatrace 的受支持深度监控路径值得重点验证。两者并用也可以合理，但应通过共同标识和事件责任连接起来，而不是让每支团队各看自己的红点。

最终拿同一次失败发布验收：错误能读懂，范围能确认，后端等待能解释，通知能到达负责人，修复后的结果能够复查。这比按岗位给产品分阵营更接近日常工程工作。

在观测云里补齐请求上下文

若还需要一个候选平台来关联受支持的应用遥测，观测云可通过 OTel 接入相应数据。先核对同一次失败请求的服务字段和链路上下文，再决定是否扩展采集；已有错误修复流程应按需要保留。观测云 OTel 文档。