New Relic vs Observe：历史数据留住以后，怎样重新查清问题

日志保存了一年，不等于一年后还能顺利回答同一个问题。三个月前的一条订单请求属于哪个租户、当时运行在哪个 Pod、那台主机后来是否被替换，都需要保留数据之间的关系。只留下文本，调查仍可能停在原地。

New Relic 与 Observe 的比较，可以从这份历史上下文展开。New Relic 适合继续围绕已有应用、实体视图与 NRQL 工作；Observe 值得关注的地方，是把事件与资源组织成带时间含义的 Datasets，并用关系和计算来支持探索。当前官方文档使用 Observe by Snowflake 名称，下文简称 Observe；它与 OpenObserve 是不同产品。

本文由观测云编辑部根据 2026 年 10 月 27 日官方资料撰写，讨论两家的托管服务。没有执行冷热查询压测，也不根据底层架构直接推断价格或性能高低。

资源关系为什么需要保留时间

Observe 的 Event Dataset 表示某个时刻发生的事件，Resource Dataset 则描述资源及其状态历史。资源主键可由多个字段组成，Dataset 之间的关联类似数据库中的键关系。主键和关联建立后，界面才能沿相关数据继续导航；它并不是看到两个字段相似就知道业务关系。Dataset 与时间

例如容器名称被重复使用，单独用名称关联，就可能把旧日志接到新的实例。为资源选择稳定标识，并保留状态在什么时间有效，才能在回看历史时恢复当时的环境。应用和集成可以提供已有的数据模型，自定义业务对象仍需要设计字段和关联。

New Relic 的应用和实体视图有另一种价值：团队已经围绕服务名、环境和现有仪表板形成调查习惯，就不必为了采用新的数据模型重建所有东西。但“同一个平台里都有”仍不等于数据自动关联正确。日志、spans 和资源属性之间的命名与时间需要一致。OpenTelemetry APM

选择 Observe 时要愿意维护这些数据关系；继续使用 New Relic 时，也要承认实体标识与采集规范属于业务自己的资产。两种模型都无法从缺失字段里推导出可靠的租户归属。

Dataset 加速不只是“冷数据慢一点”

Observe 会通过 OPAL 对输入进行转换，形成更适合查询的 Datasets。一个查询可以包含多个阶段，后续阶段使用前面阶段的输出。这个结构使字段提取、聚合和关联能够持续复用，也意味着一处上游变化会影响下游数据。核心概念

历史范围的行为尤其值得理解。当前文档说明，新建或修改 Dataset 时会自动加速此前七天；若查询范围超出已加速窗口，结果可能只覆盖其中一部分，界面会提示。需要完整历史范围时，可以发起额外加速，而这会消耗 Observe Compute Credits。问题不只是等待时间，也包括在加速完成前不要把部分结果当成完整总数。查询与按需加速

这对偶发调查与定时报表的影响不同。工程师临时回看一段旧数据，可以接受等待；财务每天生成同一份长窗口报告，则更需要稳定的范围和执行时间。先明确这份工作持续多久、多少人共用，再安排 Dataset 和历史加速，比把所有数据统称为“冷存储”更能解释预算。

数据新鲜度是另一条约束。Observe 的 freshness goal 控制加速更新间隔，更紧的目标通常带来更多计算消耗，下游 monitor 的要求也会影响执行频率。Acceleration Manager

用于月度容量回顾的数据，允许稍晚更新；用于及时发现故障的数据，则不能为了省计算而随意放宽。这里调的是结果有多新，不是原始数据保留多久。将两项配置混在一起，会让一张看似完整的图表反映过时状态。

New Relic 也有长期日志路径

把 New Relic 写成只支持热数据，会漏掉 Live Archives。该功能用于不常查询但需要长期保存的日志，保存和回查各有计量。访问归档还需要相应权限，查询入口也应明确选择归档数据范围。Live Archives、归档计费

这不等于它与 Observe 的 Dataset 加速机制相同。比较时可以先问同一件事：一条三个月前的日志仍在，但相关 spans 或资源状态是否也保留？如果只有日志延长了留存，历史上下文仍可能断开。查询成本、权限与跨信号保留需要一起安排。

观测云的日志索引也可以按用途安排保留策略；长期存储有独立查询约束，不能按普通存储的使用方式直接估价。当前文档限定日志长期存储单次查询时间范围最多 24 小时。每天回查某个异常窗口与跨整月聚合，应该选择不同的存储安排。观测云数据存储

若团队需要的是应用调查，观测云 Trace 详情已有日志与资源关联入口。把同一标识和相应保留配置好，可以减少每次人工拼关系的工作；它不会让已经被采样掉的 spans 重新出现，也不等同于任意业务 Dataset 的自动建模。

采集协议与分析语言分别决定迁移工作

Observe Agent 是带有 Observe 默认配置的 OpenTelemetry Collector 分发版，可采集主机或 Kubernetes 数据并转发应用遥测；已有 Collector 的团队也可配置相应出口。它是客户侧采集组件，不是把 Observe 分析后端装到了本地。Observe Agent

New Relic 同样支持 OTLP。两者可以共用标准化的采集基础，但 OPAL 与 NRQL、Dataset 关系与实体配置、monitors 与告警仍要分别维护。端点切换成功后，还应确认服务身份、字段类型、聚合与采样口径没有改变。New Relic OTLP

New Relic 当前提供 Data + User 与处于 Public Preview 的 Data + Core Compute；Observe 的加速、回填与查询需求则应进入其实际用量与报价。仅凭“用了数据湖”不能证明更便宜，正如托管数据库不意味着查询计算没有成本。New Relic 计费

哪些工作值得更换数据模型

如果主要工作是解释应用性能、查看现有错误并沿成熟的 NRQL 仪表板处理问题，New Relic 的已有资产应优先保留。历史日志费用过高时，先检查留存和归档是否合适，没必要直接重建整个平台。

如果团队需要把业务对象、资源状态和大量事件按时间联系起来，而且愿意长期维护 Dataset、OPAL 和加速配置，Observe 的模型有明确价值。它让这些关系成为可复用的数据资产，同时也把建模和计算管理变成持续工作。选择它，应当是这些工作值得做，而不是相信“数据进湖之后，关联和成本自然就解决了”。