New Relic 与 groundcover：先看见服务调用，再解释业务超时

一次集群发布后，结算接口偶尔超时。值班同事想先知道请求卡在哪两个服务之间，应用负责人却要进一步区分：是库存预留、优惠计算，还是支付重试占用了时间。前一个问题可以从网络和协议活动入手，后一个需要应用理解自己的业务步骤。

New Relic 与 groundcover 的区别，在这两步之间才会变得具体。不能把它简化为“需要探针”对“完全不需要插桩”，也不能把 groundcover 的节点许可当成日志增长没有任何成本。采集能看到什么、后端放在哪里、谁负责保持它可用，是三个需要分别回答的问题。

先看到调用，再解释调用内部

groundcover 的 eBPF sensor 可以在支持的环境中观察协议通信，生成相关链路和应用指标。这能减少逐个服务改代码才能开始观察的门槛，尤其适合先找出服务依赖和异常通信的位置。但协议中可见的信息，不会自动变成“这次请求用了哪一版优惠规则”这样的业务属性。

覆盖也有具体条件。当前支持清单分别列出 HTTP、gRPC、数据库和消息协议，以及加密库与运行时。JavaSSL 的 Java 11+ 路径需要启用 groundcover Java agent；文档还提示 stripped 二进制的加密通信限制。不能把所有 TLS 请求都看作无需配置即可解读。协议与运行时支持

New Relic 的语言代理提供框架相关的自动采集，也允许补充自定义插桩。以 Python 为例，配置或 API 可以增加指定函数的计时，但官方明确这不会递归追踪该函数下面的所有调用。于是试点应该问“需要解释的业务步骤有没有被记录”，而不是笼统认为装了语言代理就能看到每一行代码。Python 自定义插桩

两种方式可以成为不同层次的证据。先定位异常服务，再给关键业务步骤补 span 或属性，往往比一开始就追求所有方法都有明细更容易维护。新增采集也应观察实际资源和数据量；本文没有做双方开销排名。

节点可安装，不代表应用都在覆盖内

eBPF 接入要先核对节点。groundcover 当前 sensor 文档列出 Linux 5.3+、BTF/CO:RE 条件和加载程序所需的特权容器。托管集群的安全策略、节点镜像和权限审批，都可能决定这条路径能否落地。内核不满足要求时，不能把 eBPF 观察结果当作仍然可用；其他日志或集成数据的可用性应另看配置。内核要求

groundcover 也不只支持 Kubernetes。当前独立 Linux 主机安装文档覆盖 AMD64 与 ARM64，列出主机资源指标、Docker 容器日志与链路；JournalD 和静态日志文件需要额外配置。文档中的安装示例连接 BYOC endpoint。应把实际主机、容器与日志来源列出来，不再用“非 K8s 不支持”作为结论。Linux 主机接入

New Relic 也有 eBPF 路径。当前官方仍提供 Pixie 集成，要求核对区域和集群条件；它使用独立的 Pixie Community Cloud，并受相应条款约束。Pixie 现场可见的数据与配置为长期导出到 New Relic 的数据也要区分。因此，New Relic 与 groundcover 不是有没有 eBPF 的二选一。Pixie 集成、导出与存储

标准接入保留的是数据，不是所有界面行为

已有 OpenTelemetry 的团队不必仅为换后端重写全部埋点。New Relic 提供原生 OTLP 接收，groundcover 的后端也提供 OpenTelemetry 接入。服务名、环境、父子关系和业务属性可以作为对照的基础，但不同后端的字段处理、服务识别和查询仍需验证。New Relic OTLP、groundcover 后端

一条带重试的结算请求，可能同时出现在网络观察与应用插桩中。前者描述协议活动，后者可以记录业务步骤；两份记录有助于解释不同层面的等待，却不能直接相加作为业务请求量。入口 span、下游调用与日志之间的对应关系，决定了哪些记录属于同一次执行。

还应保留一份没有出错的请求作对照。只看到错误样本，无法判断某个属性是否同样普遍存在于正常请求。平台提供了分析入口，属性和样本的含义仍由采集设计决定。

观测云链路详情提供了查看已采集耗时、错误和相关日志的入口。服务和请求标识对应后，可以把这些证据放回同一次结算调用中；未采集的业务步骤仍然不会出现。这项关联工作是比较后端部署与运维分工之前，两种采集方式都需要完成的部分。

BYOC 要看数据路径，也要看控制路径

New Relic 的托管平台通过所选区域的接收端点获取遥测。对于有驻留要求的团队，应核对账户区域、网络路径和合同，而不是仅凭应用运行在自己的云里判断后端数据位置。

groundcover 的 BYOC 将遥测存储后端放在客户云环境中，由供应商管理；界面、身份认证与管理控制面仍使用外部云。它的 onPrem 方案把后端运行责任交给客户，但认证仍有外部依赖；airGapped 则把界面和认证也放在本地。数据存储位置、管理权限和离线运行是不同要求，不能统称为“完全不与外部通信”。部署架构

这会影响故障时的协作。后端容量不足由谁扩容，供应商如何进入环境，外部认证不可用时怎样处理，升级和恢复由谁批准，都应在试点前写清楚。数据留在客户账户不等于自动通过审查，也不意味着客户没有基础设施费用。

节点许可与整个平台成本不是一回事

groundcover 当前计费文档按监控的 Kubernetes 节点或独立主机平均数量计量。它解释的是订阅尺度，不是存储和计算消耗永远不变。相同节点数下，日志大小、保留期和并发查询增长，仍可能改变客户云中后端所需资源。计费口径

New Relic 则需要按账户的用户或计算方案、摄入和保留等项估算。当前 Core Compute 仍在官方文档中标为 Public Preview；数据加用户与数据加计算不能混成一个报价。用已确认的方案，将实际使用者和日常查询、告警活动带入模型。New Relic 计费

最好同时记录平日和发布期间的数据。一次突发可能来自业务流量，也可能来自 debug 日志或重复上报；如果不知道增长原因，仅靠换计费单位很难判断长期成本。比较总预算时，还应列出后端云资源、网络、维护和迁移工作，不能只对订阅起价。

选择能继续解释故障的接入方式

若现有 New Relic 已积累可靠的业务插桩、日志关联和团队使用路径，先检查实际缺口是不是节点覆盖或配置，而不是马上替换整个平台。若团队更看重客户环境内的后端、现有 Linux/Kubernetes 覆盖与供应商管理模式，groundcover 值得进入同一条结算链路的试点。

服务地图能帮助定位发生超时的服务，应用负责人还需要知道库存预留、优惠计算或支付重试中的哪一步在等待。只要这个问题仍依赖已有 span 和业务属性，原有插桩就还有保留的理由。减少接入工作应发生在证据可以衔接的地方，不能以删掉解释故障所需的细节为代价。

资料核对日期：2026 年 10 月 21 日。本文没有执行双方性能、传输流量或完整成本测试。