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 和属性；使用任何采集方案，都要验证异步上下文有没有传过去，而不是只看地图是否连成一条线。数据接入。

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

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

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

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

已有 OneAgent 的服务可以先选一个隔离环境评估新路径。保持同一批请求、错误和运行时配置，检查 span 是否重复、服务名是否变化、日志能否继续关联，再决定扩大范围。不要因为两边都支持某种语言，就默认双 Agent 同时运行完全没有影响；这里没有做过这种兼容性测试。

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

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 路径。

决定之前，用真实业务失败确认两边究竟能解释哪一步。观测云也可通过受支持的采集与接入方式查看服务拓扑、Trace 和 Span，再结合相关日志继续调查；业务属性、上下文传播和留存仍需配置。把这部分工作与后端维护放在同一张预算里，比只比较“自动采集”标签更接近实际选择。观测云 APM。