New Relic vs Axiom：查到订单以后，怎样解释请求为什么慢

比较NRQL与APL、事件和链路语义、区域部署以及当前数据接入、查询计算与存储计费。

观测云编辑部 6 分钟阅读更新于 2026-10-21

客服交来一个订单号，说用户付款时反复等待。工程师先在日志里找到超时，再看到支付服务调用了库存服务。此时问题从“这条记录在哪里”变成“等待发生在哪一段、是不是同一批请求都受影响”。日志搜索与应用性能分析在这里交汇。

New Relic 与 Axiom 的比较，适合沿这条调查路径展开。前者可以从 APM 服务上下文进入，再用 NRQL 追问；后者可以从事件数据集与查询进入，再沿关联找到 traces 和 metrics。Axiom 也已经有独立指标存储和多信号关联，不应继续按“只有便宜日志”来描述。资料核对日期为 2026 年 10 月 21 日，讨论当前托管产品，不把采集 SDK 当成可自建的完整后端。

一条查询先要回答同一个问题

假设已经把相同的原始应用日志送到两边，且都保留字符串 order_id。在 New Relic 中，可以通过 NRQL 查询 Log，按订单号过滤，再限定时间；在 Axiom 的 EventDB 数据集中，则通过 APL 逐步筛选、选择字段和排序。两种写法都能找记录，但数据模型、字段类型和时间范围需要先对齐。NRQL 语法、APL 语法

例如下面只演示对同一种日志的过滤，不表示两个产品里的全部数据已经等价。数据集名称和字段必须替换为实际接入值；Axiom 示例的时间条件使用事件时间 _time。

SELECT * FROM Log
WHERE order_id = 'order-1042'
SINCE 1 hour ago LIMIT 100

['checkout-logs']
| where _time > ago(1h)
| where order_id == 'order-1042'
| project _time, message, order_id
| sort by _time asc
| take 100

搜索得到 100 条结果，也不能直接说只发生了 100 次事件。结果限制、时间边界、上游过滤和重复发送都可能影响观察；要统计数量，应另外聚合，并确认统计的是日志行而不是请求数。一次请求可能写出十几条日志，这个差别不会因查询语法相似而消失。

找到日志以后，能否继续走进请求

New Relic 的 APM logs in context 会将日志与应用实体、trace 和 span 关联；可以由 Agent 装饰并转发，也可以保留已有转发链路。对调查来说，重要的是从这条超时日志能否回到当次调用，而不是仅在服务页上看到同一时段的所有日志。日志关联机制

Axiom 的当前 correlation group 可以关联最多三类数据集：OTel 日志、trace spans 与 MetricsDB 指标。日志需要带 trace_id、span_id 等上下文；配置关联后，才能沿记录进入相应 trace，再查看关联信号。这是具体的多信号工作流，不只是把不同 JSON 放进同一个搜索框。Correlations

它的 trace 视图围绕父子 span、持续时间和属性组织调用过程；但订单号本身不是 trace ID。多次重试、异步回调或者未传播上下文，都可能使同一个订单分散在不同 trace 中。应把业务标识与请求标识一起保留，而不是期待查询平台推断未记录的因果关系。Trace 数据结构

New Relic 接收 OTel 后也需要做服务识别与事务映射。其 APM 页面部分分段信息来自 spans，采样会影响可用细节。比较两边的应用体验时，应该用同一接入配置和相同采样策略，沿一条跨服务请求检查缺失的部分。OpenTelemetry APM UI

指标不是把日志再画成折线

Axiom 现行文档区分 EventDB 与 MetricsDB。前者承载日志、traces 和事件，使用 APL；后者接收 OTel 指标，需要独立的指标数据集，查询可使用目前处于 Public Preview 的 MPL，不能直接用 APL 查指标。计数器、直方图等具有自己的时间与聚合语义，不能用“支持统一查询”掩盖这种区别。指标数据集、APL 范围

New Relic 中同样不能把采样后的 Transaction 事件条数当作全量请求指标。排查某个订单适合读离散事件；判断影响范围，应该选清楚指标或事件的统计含义。否则一边统计已采样 spans，另一边统计日志行，即使最后都画出“错误率”，也不是可比较的结果。New Relic 数据类型

对团队而言，查询能力的价值在于能否稳定表达这些问题。现有 NRQL 仪表板与告警迁到 APL/MPL 时，需要重新确认窗口、字段缺失和聚合含义，不能只做关键词替换。保留几组已知事件与预期结果，比逐张截图对比更能发现差异。

查询本身也在消耗预算

Axiom 当前 Cloud 价格为每月 25 美元平台费加用量，包含每月 1 TB data loading compute、100 GB-hours query compute 和 100 GB 存储额度；超出部分分项计费。存储按压缩后容量计算，SSO、RBAC 等也列有单独附加项。因此“只按接入 GB，查询无限免费”的说法已经不适用。Axiom 当前价格

其中 GB-hours 指查询执行时间与分配内存的乘积，不是扫描了多少 GB 的同义词。界面查询、API、监控器和仪表板刷新都会产生查询工作。长时间范围配合频繁刷新，会持续消耗计算额度；应使用实际查询成本观测来估算，而不是只把每天的日志量乘一个单价。查询用量解释

New Relic 的当前官方口径包括 Data + User，以及仍处于 Preview、需联系账户代表的 Data + Core Compute，另有 Advanced Compute。接入 GB 的计算也不是简单取网络发送字节，而是经过平台修剪和转换后实际存储的数据口径。比较账单时，要先确定合同采用哪种模型，再放入用户、数据、保留和计算需求。New Relic 计费

历史调查还需要看保留。New Relic 按数据类型与账户配置管理有效保留；Axiom 的可配置保留也不代表无限免费存储。一个平台上还能查到订单日志，另一个平台上的 span 却已过期，这时多信号关联仍会断掉。New Relic 保留设置

部署区域与调查权限一起设计

Axiom 当前 edge 文档列出 AWS US East 1 与 EU Central 1。常规事件接入、存储、查询执行和结果返回由所选 edge 处理，但账户管理操作仍经由美国的集中基础设施。另一个例外是 Axiom 托管的远程 MCP：通过它查询时，结果会经过美国基础设施；创建后，数据集的 edge 不能直接修改。多 edge 数据集还涉及附加项。因此“选了欧盟区域”不等于所有账户数据和管理操作都在欧盟，也不等于自托管。Edge deployments

如果主要问题是大量结构化事件的持续调查，团队愿意维护字段与数据集模型，并能把必要的链路、指标关联起来，Axiom 值得重点验证。若日常更依赖已有 APM 服务视图、跨实体调查及 NRQL 资产，New Relic 的延续性可能更重要。两者的选择应由完整工作流和实际用量决定，不能从“对象存储”或“全栈”两个词推导性能或成本赢家。