New Relic vs SigNoz：换成 OpenTelemetry 以后，还要迁走什么

如果换平台的主要理由是希望数据采集不再绑定一家厂商，不必把“接入 OpenTelemetry”和“离开 New Relic”放在同一天完成。New Relic 本身支持 OTLP；SigNoz 则围绕 OpenTelemetry 和 ClickHouse 组织日志、指标与链路。先把采集边界理顺，再决定查询和后端放在哪里，通常比一次替换整套系统更容易控制变化。

两者真正拉开距离的地方，是团队愿意保留哪些平台能力，以及愿意接手多少运行工作。New Relic 已有的 APM 视图、NRQL 查询和告警规则是一笔存量投入。SigNoz 的社区自建、Cloud 和 Enterprise 提供不同的交付方式，不能把社区版资源账单与一份包含托管服务的订阅直接相比。

观测云编辑部 · 2026 年 10 月 27 日。本文依据官方文档比较 New Relic SaaS 与 SigNoz 自建及 Cloud，未执行双方生产压测或完整迁移。

OTel 能保留采集代码，保留不了全部查询

New Relic 的 OTLP 接入覆盖 traces、metrics 和 logs。已有应用使用 OTel SDK 时，可以保留插桩，再调整 Collector 的导出、鉴权和资源属性配置。若当前依赖 New Relic 原生 Agent 的专有 API，则需要逐项确认这些调用对应什么遥测，不能只把出口地址换成 SigNoz。New Relic OTel 数据模型

SigNoz 的采集路径把 OTel 数据送入 ClickHouse，后台负责查询与前端展示。统一协议减少的是接收端适配，不会让 NRQL 仪表板变成 SigNoz 仪表板。原来的查询可能统计 Transaction 事件，新查询可能按 span 聚合；一个请求内部有多个 span，直接替换计数对象会改变吞吐量和错误率。SigNoz 架构

SigNoz 官方也指出，服务页按顶层操作统计，而直接查询相关调用指标可能包含子操作。两张图都标着 requests/s，并不意味着分母相同。迁移时应保留服务名、入口操作和错误判定的含义，再调整语法。只要求曲线看起来接近，很容易把口径变化误认为流量变化。服务指标口径

关联依赖字段，不依赖“同一个数据库”的口号

应用日志里有一个名为 traceId 的普通属性，不代表平台已经把它识别为链路标识。SigNoz 的 trace parser 可以将已有属性映射到标准 trace 和 span 字段；若日志本来就没有上下文，后端也无法补出它属于哪次执行。Trace 字段解析

New Relic 的 logs in context 通过 trace.id、span.id 和实体信息建立关联。使用受支持的 APM Agent 时，可以保留日志装饰、关闭 Agent 转发，让已有日志采集器负责发送，避免同一份数据走两条路径。New Relic 日志关联

这类细节比“单后端三信号”更影响交接。日志保存一个月、Trace 只保存一周，月底打开日志里的链接仍可能找不到链路；在 SDK 端已经采样掉的 span 也不会因为日志还在而恢复。应用端的上下文和双方的保留策略，应与后端选择一起安排。

观测云的日志关联同样基于已采集的链路与日志标识。若希望保留 OTel 插桩、同时把存储和查询交给托管平台，可以沿用受支持的OTel 接入方式，再整理服务与日志字段。托管服务减少后端维护，并不免除这项业务配置。

浏览器数据要看具体入口

把 SigNoz 写成“没有 RUM”已经过于绝对。它提供通过 OTel 采集 Web Vitals 的文档，包含 LCP、INP、CLS 等数据，以及把浏览器和页面属性带入分析的方法。这能回答真实访问中的部分性能问题，但不是一张“支持 OTel”的勾选就自动得到会话回放、用户旅程和所有浏览器分析功能。SigNoz Web Vitals

已有 New Relic Browser 工作流的团队，需要按正在使用的能力决定是否替换。页面性能指标、JavaScript 错误、前后端链路关联和回放各自需要相应采集与产品支持。后端 APM 已经迁通，并不能证明前端工作也完成；反过来，仅需要 Web Vitals 的网站也不必为用不到的功能迁移整套工作流。

自建账单里还有查询与恢复

SigNoz 自建让团队控制部署和数据所在基础设施，也让团队负责 ClickHouse 容量、采集积压、升级与恢复。日常写入稳定，不代表长时间范围的聚合和告警并发也稳定。扩大保留期增加的不只是磁盘，还可能增加查询扫描与备份恢复时间。

SigNoz Cloud 将这些后端运行工作交给服务方，其价格区分日志与 traces 的 GB、指标样本及保留期。指标没有按标签单独收费，不等于高基数没有成本：每个新增时间序列持续输出样本，会增加总样本量。SigNoz 价格、指标样本计量

例如，固定 10,000 条活跃序列、每 60 秒输出一次、连续 30 天，就产生 432,000,000 个样本；缩短到每 15 秒一次，会变为四倍。这是指定假设下的算术结果，没有包含额外序列或厂商计费调整。降低采集频率能省下一部分用量，但也会减少短暂尖峰的可见性。

New Relic 当前提供 Data + User，并列出仍处于 Preview 的 Data + Core Compute 路径。后者不是把所有套餐默认改成无限用户免费用；查询、告警等活动进入计算计量，仍需核对合同与附加功能。New Relic 计费

什么值得迁，什么值得保留

已有 New Relic 查询和跨团队值班流程运行顺畅时，先把 OTel 采集与数据量整理好，通常比为了“开源”整体搬迁更稳妥。团队明确需要自己运行后端，并能持续维护数据库，SigNoz 自建才把控制权落到了实际工作上；希望使用其 OTel 分析方式但不接手数据库，则应比较 SigNoz Cloud 的完整服务费用。

迁移预算里应留出重建查询、告警和权限的时间。标准协议让下一次移动数据容易一些，平台上累积的判断方式仍需要人来搬。能说清楚哪些工作将减少、哪些仍由团队承担，才有依据判断这次更换是否值得。