New Relic 与 Dash0：换了采集出口，调查还能继续吗

把 OpenTelemetry Collector 的出口换掉，只需要几行配置；让值班工程师在新平台上继续找到同一个失败请求，却可能需要更长时间。服务名称、采样、日志关联、告警和历史数据，都不会因为双方支持 OTLP 就自动对齐。

New Relic 与 Dash0 适合从这个迁移场景比较。前者既有自己的应用 Agent，也提供原生 OpenTelemetry 接入；后者围绕 OpenTelemetry、PromQL 和 Perses 组织采集与调查。真正需要判断的是，现有监控工作能保留多少，哪些地方必须重新验证，而不是给“传统平台”和“开放平台”各贴一个标签。

同一个请求，先看采集到了什么

假设结算服务从同步 HTTP 改成消息队列处理。页面上的响应时间仍正常，但订单延迟增加。此时有没有消费端 span、消息上下文能否传播、日志是否带上 trace ID，比首页有多少张图更重要。

New Relic 原生 OTLP endpoint 支持 OpenTelemetry 数据，官方推荐使用原生接入，并建议 HTTP/protobuf。区域地址、认证头和信号路径需要匹配；信号专用 endpoint 与通用 endpoint 的路径处理也不同。它不是只能接收自家 Agent 数据的平台。

Dash0 的 Kubernetes Operator 部署 Collector，并为支持的运行时安排自动插桩。当前范围包括 Java、Node.js、.NET，以及需主动启用的 Python、Ruby；日志和指标采集不受同一运行时列表限制。没有自动插桩覆盖的应用，仍需要合适的 SDK 或其他采集方式。

“自动”也涉及变更窗口。配置文档 说明，默认启用命名空间监控会重启其中工作负载以应用插桩。试用不宜直接从全部生产 namespace 开始。选一条有同步调用和异步消费的路径，验证上下文传播，再逐步放大范围。

开放格式能带走什么，不能带走什么

Dash0 的 仪表盘 基于 Perses，可将日志、指标、链路、资源和 Web 事件放在同一画布上，查询使用相应表达式。开放的仪表盘格式有助于配置管理与兼容系统之间的迁移，但目标端的数据源、字段和查询语义仍须匹配。

New Relic 里已经积累的 NRQL 查询、业务告警和应用实体不会自动变成 PromQL 或 Perses。反过来，采用 OpenTelemetry 也不会自动补上应用从未生成的业务字段。客户等级、订单阶段或队列重试次数，仍要由应用或采集处理正确记录。

因此可以用一段已知故障做迁移验收：先找到受影响服务，再缩小到一次失败消费，查看相关日志，最后确认告警中的链接能落到同一时间范围。若旧平台可以完成而新平台缺了一步，先查丢失的属性、采样和权限，不急着归因于查询引擎。开放标准降低部分迁移成本，不等于没有迁移成本。

指标相同，聚合方式可能不同

接收成功不代表图表可直接对比。New Relic 对 OTLP 指标建议使用适合其架构的 delta temporality；它也支持 cumulative，但选择会影响 SDK 内存与摄取量。不同 instrument 的规则并不相同，Gauge 与 UpDownCounter 不能照搬 Counter 的设置。官方指标说明 与 endpoint 文档应一起核对。

迁移时先固定采集间隔、标签和聚合窗口，再比较请求率与延迟分布。把一个平台的累计值与另一个平台的速率直接放在同一张图上，即使曲线不同，也不能据此判断哪个漏数。直方图桶、重置处理和重复采集也会改变结果。

对于结算服务，最好保留业务计数作为外部参照，例如已确认订单数。它不替代观测系统，但能帮助发现因为采样或错误聚合而产生的“看起来很正常”。

Profiling 也要分清接收与采集

将 Dash0 描述成“没有 Profiling”已经不准确，但把它理解成安装 Operator 后自动采集所有剖析数据也不对。当前 Profiling 文档 说明，Operator 可以启用 OTLP profiles 的接收、处理与导出；采集本身仍需要单独的 profiler，例如 OpenTelemetry eBPF profiler。

该文档还指出，profiles 不使用 namespace-specific exports，而是走 Operator 的默认出口。若团队按命名空间隔离数据去向，这个限制就必须进入方案。应验证实际语言、内核权限与数据去向，而不是用收购公告或产品页图标证明已满足部署条件。

对任何平台，CPU 热点与慢请求也只是不同角度的证据。等待外部支付接口的请求可能很慢，却不消耗大量本地 CPU。试用时应该让请求时间线与剖析结果互相解释，而不是要求一张火焰图回答所有延迟问题。

记录数与 GB 账单，不能直接比单价

Dash0 当前公开价格 按信号计数：日志记录、span、Web event 每百万分别为 0.06 美元摄取和 0.54 美元存储，所列保留期为 30 天；指标点每百万为 0.02 与 0.18 美元，保留 13 个月。这是公开基础费率，阶梯和合同应另核。SignalControl 过滤的数据仍产生摄取费，仅不再产生相应存储费。Agent0 按 credits，AI SDLC Insights 按用户席位计费，不能概括为所有功能都没有席位或附加费用。

New Relic 当前定价模型 包括 Data + User，以及文档仍标为 Preview、需联系账户团队的 Data + Core Compute。后者改变了“所有人都要买席位”的讨论前提；Advanced Compute 又是另一层能力与用量。用户模型里的 Basic 用户可以查询数据和使用自定义仪表盘，但不等于拥有全部 APM 界面。

这种计量差异要求同时记录事件数和处理后的 GB。大量短日志与少量大堆栈，即使字节量相近，在按记录数的模型里也不是同一账单；同样，更多标签和属性可能改变按数据量计费的结果。先用实际样本估算，再加上保留期、查询使用和团队访问方式，才有可比的成本。

Dash0 的 预算控制 还涉及接近上限提醒及宽限期后的暂停摄取。预算保护因此也是数据连续性决策。谁可以调整上限、暂停时如何通知值班人员，应在流量高峰之前确定。

选择要落在团队下一次调查上

如果团队已依赖 New Relic 的应用调查与大量现有规则，先验证原生 OTLP 能否满足开放采集目标，比立即搬家更稳妥。如果团队已经以 OpenTelemetry、PromQL 和配置即代码组织工作，Dash0 值得用一条完整业务路径试用，重点检查运行时覆盖、权限、剖析出口和账单。

迁移结束也不是停止双写那一刻。旧事故链接、历史基线和告警维护责任都应有明确去处。最终标准是新值班同事能否接着调查，而不是一次演示里能否看到数据。

在观测云中复用同一条验证路径

观测云的 OpenTelemetry 接入文档 也可以作为这一验证的起点。用相同业务请求核对支持的接入方式、资源属性与链路关联，再判断是否适合现有工作流。开放采集提供了选择空间，完整上下文仍需要团队逐项保留下来。

资料核对日期：2026 年 10 月 21 日。本文未对两家产品做性能、可靠性或总成本实测。