Dynatrace vs groundcover：从应用调用到云内后端，哪些工作仍要自己做

一个团队已经用 OneAgent 看 Java 服务，准备把更多服务迁到 Kubernetes。新集群里能看到谁在调用谁，但一次退款为什么重复执行，仍要靠订单字段和队列上下文解释。与此同时，平台组希望观测数据保存在自己的云账户，后端扩容却不想全部接手。

Dynatrace 与 groundcover 的比较，正好涉及这两件不同的事：如何得到足够的应用证据，以及谁运行保存和查询证据的系统。eBPF、自动插桩和 BYOC 分别回答其中一部分，不能把它们串成“零改动、零维护、固定总成本”的保证。

资料核对日期：2026 年 10 月 21 日，依据官方支持矩阵与部署文档分析，未运行双方 Agent 或进行性能测试。

看到服务通信以后，还能解释什么

Dynatrace Full-Stack Monitoring 为受支持环境提供分布式追踪、代码层信息、分析能力和进程监控。OneAgent 的价值可以体现在少维护一套手工发现规则，但支持的运行时、版本和采集方式仍需逐项匹配。一个服务在拓扑里出现，不等于所有内部业务步骤都已成为 span。Full-Stack Monitoring、技术支持范围。

groundcover 的 eBPF sensor 可从受支持协议和运行时生成请求观测数据，帮助建立服务之间的通信视图。这里的覆盖取决于实际协议和加密实现。例如当前文档要求 JavaSSL 使用 Java 11 或更高版本，并启用 groundcover Java Agent；它也列出剥离调试符号的二进制在加密通信方面的限制。“无需代码改动”不能解释成所有应用都不需要额外 Agent 或配置。协议与运行时。

退款请求可能经历排队、重试和业务去重。服务间延迟告诉人在哪里等待，订单状态和重试原因则需要业务提供。groundcover 有 OpenTelemetry 接入路径，可以补充应用 span 和属性；使用任何采集方案，都要验证异步上下文有没有传过去，而不是只看地图是否连成一条线。数据接入。

观测云也可通过受支持的接入路径查看服务拓扑、Trace 和 Span，并在配置满足时继续关联日志。对于重复退款，span 可以把重试放进调用顺序，业务属性或日志再解释订单状态。业务字段、上下文传播和保留仍需配置；这部分工作应与后端维护放在同一份预算里，自动采集本身不会给出业务解释。观测云 APM。

集群能安装，不代表采集条件都满足

当前 groundcover sensor 文档列出 Linux 内核 5.3 及以上、发行版支持范围、BTF/CO:RE 条件以及特权容器要求。实际内核和发行版兼容性要一起检查；不能仅按发行版名称，或者看到 Helm 安装成功，就认为 eBPF 路径已经工作。内核要求。

权限也是部署设计的一部分。团队要评估 sensor 能接触哪些进程和流量，哪些载荷允许采集，敏感字段怎样处理。eBPF 有内核验证机制，并不等于任何监控配置都没有资源或数据暴露风险。若运行环境不支持 sensor，其他数据接入路径可能仍可用，但不能把它们当成同样的自动采集覆盖。

也不应把 groundcover 限定为只能监控 Kubernetes。当前官方提供独立 Linux 主机 sensor 的安装方式，示例面向 BYOC endpoint；具体主机和部署支持仍按该路径核对。对有虚拟机、容器和旧应用的环境，应分别列出采集方案，再判断能否维护得住。Linux 主机接入。

两边都支持同一种语言，不代表两套 Agent 共存就没有影响。已有 OneAgent 的服务增加第二条路径，可能出现重复 span、服务名变化，或日志关联字段不再一致。在隔离上线范围内保持请求与运行时条件相同，有助于分清这些采集变化和应用真实行为变化。

数据在自己的云里，责任怎样划分

groundcover 的 BYOC 架构把后端部署在客户云环境的独立集群，供应商管理后端；前端、SSO 认证和托管控制面仍通过外部云提供。它与“所有组件均离线运行”是不同的部署形态。需要数据驻留时，应分别确认数据存储、浏览器访问、认证、管理通道与支持权限。架构说明。

同一文档还区分 onPrem 与 airGapped。onPrem 的后端管理交给客户，认证仍有外部依赖；airGapped 将前端和认证等组件一并放在本地。隔离要求提高，维护职责通常也随之变化。选择哪一种，应和网络出口、升级窗口、故障支持及恢复流程一起确定，不能单凭 BYOC 名称完成合规判断。

Dynatrace 也需要区分 SaaS 和 Managed。最新 Grail 应用的可用范围应按具体部署确认，例如 Clouds 应用要求由 Grail 和 AppEngine 支持的 SaaS 环境。不能因为 Managed 在客户环境运行，就假设所有新 SaaS 体验都可以原样迁过去。Managed、Clouds 前提。

后端在故障时还要能服务调查

数据留在自己账户，确实便于把资源与访问纳入现有治理；同时也要明确云资源费用和资源供给责任。即使供应商负责运行数据库，账号配额、网络策略和资源审批仍可能阻断扩容。应事先约定谁处理这类跨团队问题。

一条慢请求需要日志、调用和资源状态在同一时刻可用。采集出口中断会带来丢失或补送不完整，认证不可用会让仍被保存的数据无法访问，后端恢复后也可能先恢复写入、后恢复历史查询。这是几种不同的故障方式，不能只用数据库进程是否还在运行来描述观测服务是否可用。

从 Dynatrace 迁出时，旧的服务分组、告警阈值、自动化流程和权限也需要重新对应。标准化遥测能减少采集端改动，但不会自动转换平台里的所有配置。保留一段重叠观察期，可以发现新链路缺少的证据，也会产生额外数据和维护费用。

节点数与内存对应不同的账单

groundcover 当前计费文档按 sensor 监控的 Kubernetes 节点或独立主机的平均数量统计用量，并区分计划和部署方式。它不是与环境增长无关的固定总价；日志不作为该节点计量的单位，也不意味着更多日志完全没有存储和计算成本。计费说明。

Dynatrace 主机 Full-Stack 按 memory-GiB-hours 计量。物理或虚拟主机最低按 4 GiB，内存向上取至 0.25 GiB 的整数倍，监控时间按十五分钟区间计算。这里使用的是主机内存，不是 OneAgent 进程的内存。容器 application-only 等方式有各自规则，不能把主机公式直接套到所有采集模式。消费计算。

因此，同样十个节点，节点内存变大可能改变 Dynatrace 主机计量；节点数量不变时，groundcover 的节点计量可以相同，但客户云里的后端开销仍可能增长。日志、其他能力和合同条件也要单独纳入。这个差别值得建模，却不能直接推出任何一方总成本更低。

选择能长期维持的采集与运行方式

已有受支持的 OneAgent 调查流程、需要应用与进程细节，且希望继续利用这些配置资产，可以先围绕 Dynatrace 扩展。希望把后端放在自己的云账户、groundcover 的协议覆盖符合实际应用，又能明确客户与供应商运维边界，则值得评估其 BYOC 路径。