New Relic vs Logz.io：熟悉的查询语法之外，还要迁什么

用过 Elasticsearch 的团队看 Logz.io，很容易先问一句：原来的查询还能不能用？这个问题值得问，却不能独自决定迁移。日志送得进去、关键词搜得出来之后，字段类型、告警窗口、权限和历史数据仍要有着落。

New Relic 与 Logz.io 的差异，也已经不是“统一商业平台”和“几个开源界面的托管组合”那么简单。Logz.io 当前提供 Open 360 Explore、APM 与统一仪表板；New Relic 则围绕自身的数据类型、NRQL 和应用视图组织调查。熟悉 Lucene、PromQL，可以降低一部分学习成本，但无法把两家的保存查询、告警与权限变成同一种资产。

本文由观测云编辑部依据 2026 年 10 月 27 日官方资料撰写，比较托管服务的实际接入和查询路径，不声称执行过性能或费用测试。

先看现在使用的界面

Logz.io 的 Explore 将日志、指标和 spans 放在不同标签中。日志使用增强的 Lucene 查询，指标使用 PromQL 或查询构建器，Trace 标签用于查找 spans；相应账户中没有该类数据，标签不会因为“平台统一”就自动可用。这比把产品描述为“原生 Kibana 加 Grafana 加 Jaeger”更贴近当前入口。Explore 文档

New Relic 的日志既有搜索界面，也可用 NRQL 查询。其摄入时解析将属性保存进 NRDB，查询时解析则可以临时处理已有记录。团队已经维护大量 NRQL 告警和仪表板时，这些资产本身就是继续使用的理由；若改用其他后端，查询看起来都像 SQL，也不代表函数、数据类型和时间语义相同。日志解析

例如 duration 原来是数值，迁移后却成为带单位的字符串。关键词仍然能搜索，阈值规则却不能再按原来的数值比较。发现这种差异后，应该明确在采集、摄入或查询阶段统一类型，而不是把“兼容查询语言”理解为处理规则也已经搬好了。

OpenTelemetry 降低接入耦合，不搬运整套平台

Logz.io 提供 OpenTelemetry 接入说明，应用的 spans 经 SDK 或自动插桩产生，再交给 Collector 等转发路径。新平台不能根据日志里的服务名恢复没有采集过的方法调用；是否能看到数据库、消息队列或自定义业务步骤，取决于实际插桩覆盖。Logz.io OpenTelemetry

New Relic 同样支持原生 OTLP，并推荐通过它发送 OpenTelemetry 数据。端点地区、认证、信号路径和属性限制都有具体要求。统一协议让采集端更容易调整去向，但 NRQL、实体视图、告警和访问策略仍是平台上的配置。New Relic OTLP

迁移时更容易遗漏的是分母。按全部请求生成的错误率，和按保留下来的错误 spans 计算出的比例，不一定描述同一件事。采样位置、过滤规则、迟到数据和聚合窗口改变以后，同名图表也可能出现合理差异。先写清统计对象，才能判断差异来自丢失还是口径变化。

日志与链路的关联需要共同的标识

New Relic 的 logs in context 可以为应用日志增加 trace、span 和实体标识。语言 Agent、日志框架和转发配置决定具体行为；已有独立日志采集路径时，要避免 Agent 又把同一批记录发送一次。New Relic 日志关联

Logz.io 的统一 Explore 提供从日志查看 Kubernetes 资源上下文等入口，但前提是相应元数据和指标已经存在。只有一条文本中写着 checkout，不足以区分不同集群里同名服务。环境、集群与服务身份应一并保留，trace ID 则用于定位某一次请求。

观测云的日志和链路详情也围绕这些已采集字段提供关联入口。若团队正在整理两套平台的命名，可以在接入阶段统一 service、env 与 trace_id，让日志关联链路成为可持续维护的配置。它减少的是手工拼接上下文的工作，不会替代应用插桩，也无法找回已经过期的 Trace。

长期保存和日常查询是两份预算

Logz.io 的消费计费文档分别列出日志摄入、索引与热保留、延长保留、不同存储层、指标和链路等用量。文档里的算例帮助理解组合方式，不是对每个客户有效的报价。仅拿一项日志 GB 单价，就无法推出“比 New Relic 便宜”。消费计费机制

Warm Tier 有自己的启用和保留规则。当前文档要求启用后 Hot Tier 至少保留 14 天，并按账户或子账户配置。历史查询能否满足需求，要看所选层级、实际账户能力和查询路径，不能把“有长期存储”写成“所有历史数据始终同样快”。Warm Tier

New Relic 也有面向低频回查的 Live Archives，长期存储和查询有额外计量，查询还需要相应权限。它不是只提供短期热数据的平台。Live Archives 计费

当前 New Relic 既有 Data + User，也有处于 Public Preview 的 Data + Core Compute。比较报价时，应把选定计划、保留和实际查询需求一起放入计算，不把免费 Basic 用户等同于所有产品界面的免费访问。New Relic 计费

熟悉什么，可以复用到哪一步

已经围绕 Lucene 日志搜索、PromQL 和 OTel 组织采集的团队，Logz.io 值得优先研究。省下的是部分语法和采集习惯的重学，仍要处理账户、字段、保存视图、告警与分层策略。不要承诺“改 endpoint 即完成迁移”。

已经在 New Relic 中形成成熟的服务视图、NRQL 和错误调查路径，则先计算这些配置迁出的成本。若真正的问题只是日志量和保留过长，分流与保留调整可能比替换整个平台更有效。

选择 Logz.io 的理由应是它当前的查询和数据管理方式更符合团队工作，而非把它当成没有迁移成本的开源出口；选择 New Relic 的理由应是现有应用上下文仍有价值，而非假定另一家没有 APM。两边都是托管服务，客户最终仍需维护业务字段、采集规则与告警含义。