New Relic vs Uptrace：OTel 数据留下来，后端由谁运行

Uptrace 不只是一个便宜的 Trace 查看器。当前产品接收 traces、metrics 和 logs，并提供查询与告警；自建文档也明确列出 ClickHouse、PostgreSQL 和 Redis。把它概括成“只补链路，运行几乎不要钱”，会同时低估软件能做的事和团队要承担的事。

New Relic 与 Uptrace 的主要取舍，在于团队想保留哪些现成的分析工作，以及是否要自己运行后端。已有 OTel 数据，可以让采集调整相对独立；已有 New Relic 专有插桩、NRQL 仪表板和告警，则还需要安排应用与查询迁移。平台价格只是其中一项投入。

观测云编辑部 · 2026 年 10 月 27 日。依据官方文档比较 New Relic SaaS、Uptrace Cloud 与自建方式；没有执行双方性能测试，也不引用厂商节省比例作为结论。

Uptrace 接收的不只有 traces

Uptrace 的官方接入目录包含 OTel SDK 与 Collector，也列出 Prometheus remote write、Vector、Fluent Bit 和 Sentry 等集成入口。不同入口有不同的数据类型与配置条件；因此“只接受 OTLP”也不是准确描述。Uptrace 接入方式

对于已经采用 OTel 的应用，迁移重点可以放在出口、鉴权、资源属性与数据处理配置上。New Relic 本身也接受 OTel 的三类信号，不需要先把它描绘成完全封闭的采集系统，才能解释 Uptrace 的价值。New Relic OTel 数据

真正要单独处理的是原生 Agent API、自定义事件与应用内部命名。如果旧代码调用 New Relic API 记录一个业务动作，Uptrace 不会因为接受 OTLP 就自动认识这个调用。可以把合适的业务属性与操作整理进 OTel，但“同一信息”究竟应成为 span、事件还是指标，需要按原用途决定。

自建方案需要恢复的不止遥测数据

当前 Uptrace 自建架构中，ClickHouse 保存 traces、logs 与 metrics，PostgreSQL 保存用户、项目和仪表板等信息，Redis 承担缓存与后台任务协调。部署包让这些组件容易一起启动，并不会把它们变成无需维护的单一文件。自建架构、安装说明

这意味着备份不能只覆盖体积最大的数据库。遥测还在，但用户、项目或查询配置丢失，也会影响恢复后的使用。升级时要考虑应用版本与数据库迁移，容量规划则要同时看写入、历史扫描、后台任务与并发查询。

软件许可与服务支持还应按实际版本区分。Uptrace 当前列有 Community 与商业交付选项，自建的免费软件不等于支持、资源和工程时间都免费。Uptrace 版本

能收到数据，不代表旧图表已经迁好

原来的图表如果按 Transaction 事件计请求，新平台按 span 聚合，就需要明确是入口 span、客户端 span 还是全部 span。一个请求有多个内部调用，把它们全部计入会使吞吐量变大；把错误 span 数直接除以全部 span，也不一定得到业务请求错误率。

同样，P95 必须在所需范围的数据上重新聚合，不能把多个服务或时间桶的 P95 直接平均。当迁移改变数据保留、采样位置或字段类型时，图表结果可能变化，即使两端都成功收到了数据。业务字段的含义与统计对象，应该随查询一起记录下来。

日志关联也需要保留上下文。New Relic 的 logs in context 使用 trace、span 与实体元数据；改成另一种采集时，要确认这些字段怎样进入新平台认可的位置。仍然保留的日志，不能找回已经采样丢弃或过期的 span。New Relic 关联机制

观测云提供受支持的OTel 接入与日志关联链路，也可以保留应用侧已有的标准插桩，再交由托管后端查询。它减少的是后端运行投入，统计口径、业务字段和采样仍需要团队自己确定。这一分工与选择 Uptrace Cloud 或自建时一样，应当明确写进工作范围。

浏览器采集不能只看产品清单

Uptrace 有浏览器 OTel SDK 文档，介绍通过 OTLP/HTTP 发送 spans 和 metrics，以及 fetch、XHR、页面加载等插桩。所以不能一概说它完全不处理前端数据。Uptrace 浏览器接入

但浏览器插桩也不自动等于所有 RUM 工作流。用户旅程、错误归组、会话回放和前后端关联应逐项看具体产品能力与采集方式。已经使用 New Relic Browser 的团队，首先要确认哪些页面和错误分析每天都在使用，再判断应替换、保留还是并行运行，而不是因为后端 trace 能显示就结束前端比较。

先算数据，再核对适用报价

Uptrace Cloud 当前将 spans/logs 与指标数据点分开描述，并提供保留期选项。指标采集间隔会改变数据点数；trace 的属性和事件也会改变记录大小。给每个 span 增加很长的请求正文，既可能增加存储用量，也可能把不该进入遥测的敏感内容送出去。

价格页在本次核验时同时出现不同的起步费率表述，预算上限的说明与超额使用的问答也需要向厂商确认。因此本文不拿其中一个数字推导“便宜十倍”，应按适用版本、保留与超额行为取得一致报价。Uptrace 价格与用量说明

New Relic 的 Data + User 与 Preview 中的 Data + Core Compute 也有不同的用量口径，不能只拿一个摄入单价代表整套服务。自建比较还要加入资源、备份、维护和恢复的投入，才与托管方案在同一层面。New Relic 计费

如果已有 New Relic 的查询、浏览器与应用流程稳定工作，先整理采集和数据量，可能比一次性换平台更划算。明确需要自己控制后端、能够运行数据库，并希望围绕 OTel 数据组织分析的团队，可以认真考虑 Uptrace 自建。只想使用其分析方式而没有数据库维护人员，则应比较 Uptrace Cloud 的服务范围与完整费用，不必把自建当作省钱的必经之路。