Datadog vs groundcover：eBPF 接入以后，谁来维护可观测后端

一个 Kubernetes 集群里有几十个服务，语言和框架各不相同。平台团队想先知道谁在调用谁、哪里开始报错，却发现给每个应用排期接入探针，要比部署监控后端更久。groundcover 的 eBPF 采集方式正好切中了这个问题：先在受支持的运行环境中获得服务通信的可见性。

但如果团队已经在 Datadog 使用应用探针、云集成和告警，换平台就不只是减少几个 SDK。还要决定查询与存储运行在哪里，以及厂商和自己分别维护什么。Datadog 与 groundcover 的区别，最好沿着一次请求从采集到查询的路径来看。

资料核对于 2026-10-21，依据官方文档分析，未进行采集开销或查询性能测试。

自动发现调用，先看运行环境

groundcover 可以在 Kubernetes 中部署传感器，也支持符合条件的独立 Linux 主机；当前安装文档提供了面向 BYOC 接入地址的主机传感器安装方式。不能因为产品围绕 Kubernetes 展开，就断言虚拟机完全不能接入。Linux 主机接入。

eBPF 也有具体前提。当前文档列出 Linux 内核 5.3 及以上的要求，同时提供发行版兼容表；还需要 BTF/CO:RE 支持以及加载程序所需的权限。容器环境涉及特权运行，实际评估要同时核对节点镜像与集群安全策略。单看 uname 输出里的版本数字，不足以决定能否上线。内核与权限要求。

Datadog 也有无需应用 SDK 的 Universal Service Monitoring，使用配置好的 Agent 获取服务健康与依赖信息。因此不能把两家描述成“eBPF 对传统探针”的二选一。更实际的问题是：哪些服务适合自动发现，哪些仍需应用级 Trace，现有平台已覆盖了多少。Datadog USM。

看到了网络请求，还缺什么上下文

同一个接口有些请求很慢，网络层可以帮助看清调用目标与耗时，但未必知道它们属于哪种订单、是否走了某个功能开关，或者在哪段应用内部逻辑等待。平台无法凭空推导应用没有暴露的业务语义。需要这些维度，就仍要补充属性或应用埋点。

groundcover 支持接收 OpenTelemetry 数据，所以 eBPF 与应用插桩可以配合使用。可以先覆盖服务间通信，再为订单处理、队列消费和关键业务步骤增加 Span。这样减少的是全面铺开插桩的第一步成本，并不意味着所有后续工作都会消失。groundcover 数据接入。

同样，服务图有连线不等于异步任务已经连成同一条 Trace。消息生产端和消费端是否传播上下文，框架是否覆盖重试和批处理，仍需用真实调用检查。迁移时保留已有的 OTel 业务字段，通常比为了展示“零代码”而把它们去掉更有价值。

加密流量是接入时值得提前验证的一关

groundcover 官方列出了支持的协议、加密库与运行时。Java SSL 的支持注明 Java 11+，并要求启用 groundcover Java agent；文档还列出了 stripped 二进制的加密采集限制。因此，“支持 HTTPS”不能被解释成任意运行时、任意构建产物都无需额外配置。支持的技术。

试用时可以挑一个真正会进入生产的服务镜像，覆盖加密入口、数据库访问和消息队列，而不是只访问一个明文演示接口。平台团队能否安装特权传感器、应用团队是否接受额外 Java agent、升级运行时以后谁验证覆盖，这些都是接入方案的一部分。

验证时也要看采集到了什么。接口和耗时足够解决部分问题，完整载荷却可能包含敏感字段。应按调查需要确定采集与脱敏范围，而不是默认“越多越好”。如果缺少某段上下文，可以补业务埋点；如果环境权限不允许传感器运行，则需要评估其他受支持的接入路径。

后端在自己的云里，不等于自己全管

groundcover 的 BYOC 架构把后端部署在客户云环境的独立集群内，由厂商管理；前端、认证及管理控制面仍涉及外部云服务。on-prem 模式把后端管理交给客户，前端也部署在本地，但认证仍有外部依赖；air-gapped 模式则进一步本地化这些组件。三种交付方式不能只用一句“数据不出云”替代。架构说明。

对平台团队来说，重要的是谁负责扩容、版本升级、故障恢复和管理权限。数据留在自己的云账户，确实改变了存储与访问安排，但云资源账单不会因此消失，厂商远程管理的访问方式也需要在实际部署中明确。

Datadog 常见的 SaaS 使用方式，把大部分可观测后端交给厂商运行，客户仍管理 Agent、集成与数据策略。具体产品也可能有不同部署选项，不能据此推论整个产品目录都只能采用一种数据路径。比较时应画出实际采购方案：采集、处理、存储、查询和身份服务各在哪里运行，才看得出责任差异。

维护分工还应延伸到故障当天。后端集群故障以后，传感器的数据如何处理，客户需要先开工单还是可以自行恢复，厂商能否在约定时间访问环境，这些最好在试用时说清楚。部署图里的一条管理连接，实际对应的是网络策略、账号权限与值班协作。只有正常时可以管理，不足以证明故障时也能恢复。

按节点订阅，费用仍会随使用方式变化

groundcover 的计费文档以传感器监控的 Kubernetes 节点或独立主机平均数量为基础。它与把日志量、APM 等产品分别计量的 Datadog 报价，关注的是不同维度；具体套餐、周期和附加功能仍需核对。groundcover 计费、Datadog 价格。

例如，业务流量翻倍，但节点数暂时不变，按节点计算的订阅部分未必同步翻倍。写入和查询后端却要处理更多数据，云端计算、存储和网络费用仍可能变化。反过来，自动扩容增加了被监控节点，也会改变订阅计量。固定的计费单位不等于固定的总成本。

因此，把 BYOC 报价与 SaaS 比较时，至少要纳入后端集群、对象存储、网络以及团队承担的运维。还要保持留存和查询负载一致：保留七天与保留一个月，单人查最近一小时与多人查整月，并不是同一份服务。

可以用平常一天和故障高峰各估一次。平日给出常态预算，高峰则暴露容量余量和采集积压的处理方式。若只把最安静的一天外推到整月，按节点和按数据量两种模式都可能被算得过于乐观。

迁移预算还包括现有告警和仪表板。指标名称能对上，并不代表窗口、聚合、缺失值处理和告警接收人都已迁过去。可以挑一个正在使用的延迟告警，在双方相同时间范围内核对触发条件；再让实际值班人员沿着告警去找请求。这些操作不要求先迁全公司，却能较早看出平台变化给日常工作带来的影响。

试用结束时留下覆盖清单和责任人，比只截几张漂亮的服务图更有用，后续升级也可以沿用这份记录。

从最难接入的那组服务开始评估

对于大量尚未插桩、环境满足要求的 Linux 服务，groundcover 值得用实际镜像验证覆盖；BYOC 也适合希望后端留在自己云账户、同时仍希望获得托管运维的团队。已有成熟 Datadog 工作流时，则应看新增覆盖能否抵消告警、仪表板和调查习惯的迁移投入。

也可以把观测云作为另一种应用排障路径：通过受支持的采集方式查看服务拓扑与调用链，并在数据条件满足时连接相关日志。团队仍需维护上下文、采样与字段；SaaS 和私有部署的维护分工应分别明确。比较最终能查清哪些请求、由谁维护后端，比“有没有 eBPF”更接近长期选择。观测云 APM。