New Relic 与 Honeycomb：少数客户的超时，怎样查到具体请求

一项报表导出服务总体延迟没有明显变化，客服却连续收到几家客户的超时反馈。按服务看平均值，一切正常；按租户、报表类型和数据分片继续拆开，才可能看见少数请求经历了完全不同的路径。

这也是 New Relic 与 Honeycomb 值得放在一起比较的地方。两者都能围绕应用数据继续查询，区别不能归结为“一边只能看仪表板，另一边才会探索”。更实际的问题是：工程师是否拿到了足够的请求上下文，能否从异常群体找到具体证据，以及采样后还剩下什么可以解释。

先给请求留下可用的业务属性

租户编号、报表类型、分片和功能开关，往往不在默认的主机指标里。它们需要通过应用或采集配置进入遥测。New Relic 可以为 APM 等数据添加自定义属性，再用 NRQL 查询和分组；这些属性会增加摄入量。不要为了“高基数能力”无差别收集个人信息，应使用解决问题所需的标识和合适的访问控制。自定义属性

假设 export-service 的 Transaction 事件已经包含 tenant_id，可以从下面这样的示意查询开始：

SELECT percentile(duration, 95)
FROM Transaction
WHERE appName = 'export-service'
FACET tenant_id
SINCE 30 minutes ago
LIMIT 20

它对所查询的 Transaction 数据按租户分组，不是列出每个租户的完整业务请求台账；LIMIT 20 也限制返回的分组。一个租户没有出现在结果中，不能直接解释为它没有请求。接下来应收窄到客户和时间窗口，检查原始记录与数据覆盖。NRQL 参考

Honeycomb 的事件查询同样依赖字段已经存在。把同一业务步骤所需的上下文放在一起，才便于临时换维度继续追问。若租户属性只出现在入口 span，而耗时发生在后台任务，需要通过链路关系和上下文传播找回关联，不能要求每个子 span 天然知道全部业务信息。

BubbleUp 提供差异，不替代因果验证

Honeycomb 的 BubbleUp 可以把选中的慢请求区域与其余数据作比较，展示字段分布差异。例如异常区域集中在某个分片或功能开关值，就可以沿着这些条件继续查。BubbleUp

这个交互适合“不知道该先按哪个字段拆”的调查，但相关性仍需要解释。某个租户全部使用新版功能，它既可能是问题条件，也可能只是恰好占了大部分流量。需要继续对照正常请求、部署时间和具体 span，不能把差异排名直接当作根因证明。

New Relic 中也可以从自定义属性、分组查询和已有应用上下文继续缩小范围。已有团队若能熟练维护这些查询，迁移时要算上学习和规则重建；如果经常在临时比较群体差异这一步停住，可以用真实问题评估 Honeycomb 的交互是否减少了工作。本文没有测量双方排障速度，也没有把使用习惯当成产品性能排名。

指标负责连续观察，事件负责解释一次工作

Honeycomb 当前已支持原生指标数据集，与 traces 和 logs 的事件数据分开。它支持 OpenTelemetry 指标类型、基于指标的 Trigger，以及在事件结果或 span 中查看相关资源指标。不能继续把它描述成只会分析事件、基础设施指标必须放在另一个产品里。Honeycomb 指标

但接受指标不代表会自动采到整个环境。CPU、内存或队列深度必须接入，关联也需要资源属性正确。导出服务变慢时，可以先看持续的资源趋势，再进入具体请求；单条请求的业务条件与长期指标各自回答不同问题。

New Relic 也需要区分数据类型。Transaction、Span、Log 与指标并不是可以随意替换的同一种记录；保留设置也可能不同。一个月后的复盘即使还能看到总体趋势，也不意味着当天的逐请求明细仍可恢复。选型时应给日常告警和事后调查分别设定数据要求。数据与保留

采样改变的不只是账单

New Relic 的标准分布式追踪主要采用头部采样；Infinite Tracing 使用尾部采样，需要对应的 trace observer 配置。把所有已插桩 span 发给 observer，不等于后端永久保存全部请求，还可能增加出口流量。已有 OTel 采样也会影响最终看到的数据。分布式追踪机制

Honeycomb 可以用 Refinery 等方式在发送前采样，并利用样本权重修正部分聚合。权重不能恢复没留下来的某条失败请求，COUNT_DISTINCT 也不按采样率补偿缺失的唯一值。因此，采样之后查到的“客户数量”不能直接当成完整受影响客户清单。采样后的查询

对于少数租户的偶发超时，试点应保留慢请求、错误和少见业务分支，同时记录总体请求量。调整策略后，既检查预计用量，也检查原来能解释的问题是否仍能解释。平均延迟曲线接近，并不能证明两边保留了同一批罕见样本。

用业务量推导遥测量，再比较方案

Honeycomb 当前分别计量事件与原生指标数据点；一个 trace 中的多个 span 会分别计为事件，不是一个请求只占一个事件。假设每秒 50 个请求、每个请求平均生成 12 个 span，未采样时一天就有：

50 × 12 × 86,400 = 51,840,000 个 span

这只是指定假设下的 span 数，还没计日志等其他事件。指标数据点也有单独的月度额度，不能从事件预算推断指标无限。应查看实际方案的超额处理，不把采样或突发保护当成无边界接入。用量定义

New Relic 的自定义属性大小会影响摄入；数据加用户和数据加 Core Compute 的计费路径也应分别估算，当前官方将后者标为 Public Preview。需要纳入真实使用者、查询与告警活动，而不是拿“每 GB”同“每事件”直接相除。计费方式

成本比较最终仍要回到证据。少发很多数据却丢了少数付费客户的错误，不一定划算；保留所有重复字段却无人使用，也不等于更完整。可以先列出值班时反复提出的几个问题，再确认支持它们的字段、样本和保留期限。

让下一位值班者能够接着查

已有 New Relic 的应用、基础设施与团队查询体系运行顺畅时，可以先补齐业务属性和采样设计。若主要障碍是不断变化的异常群体，以及不知道该选哪个维度继续分析，Honeycomb 的事件探索值得用这些真实场景试用。是否增加第二个平台，要看它是否解决了持续出现的工作缺口。

交接时不只留下截图，也应保留查询条件、时间范围、数据类型和采样说明。下一位同事要能回到同一批证据，继续确认分片、版本或客户条件，而不是从一张“红色区域”图重新猜测。

若把观测云纳入评估，可以从链路详情验证同一条报表请求的耗时、错误与相关日志，再检查业务属性是否按预期接入。关联与调查仍取决于字段、样本、权限和留存；平台入口不能补回未采集的事件。观测云链路详情

资料核对日期：2026 年 10 月 21 日。查询为文档语义示例，未在厂商账户执行；没有吞吐、排障效率或价格收益排名。