Dynatrace vs Grafana Cloud：保留现有调查，还是换一套采集方式

已经有 Prometheus 告警、LogQL 查询和 Grafana 看板的团队，开始补应用链路时，Grafana Cloud 是很自然的下一步。另一个团队的值班流程一直围绕 OneAgent：从慢请求看到进程，再查看代码和主机资源。对他们而言，迁移后少了这段证据，比少几个看板更值得担心。

Dynatrace 与 Grafana Cloud 的比较，应从这些已有工作开始。前者适合继续利用受支持环境中的深度应用与资源监控；后者适合沿用开放遥测、查询习惯和现有 Grafana 资产。两家都提供托管服务，也都有现成调查功能，不能把它们简化成“全自动平台”和“必须自己拼装的开源组件”。

观测云编辑部 · 资料核对于 2026-10-21。本文讨论 Dynatrace SaaS/DPS 与 Grafana Cloud，不把自建开源栈、Dynatrace Managed 和各云端产品视作相同版本。没有进行双方性能或费用实测。

从慢服务走到慢代码

OneAgent 的 Full-Stack Monitoring 在受支持技术上提供分布式追踪、代码级可见性、剖析和进程信息。覆盖取决于运行时、版本和监控模式，不能仅凭安装成功就假定所有业务方法都已记录。OneAgent 支持矩阵。

Grafana Cloud 也已有应用调查流程。当前知识图谱版 Application Observability 提供服务目录、RED 指标、插桩质量检查及日志、链路、指标、Profiles 的关联入口；官方按组织接入日期区分新版与 classic 文档，2026-09-07 之后接入的组织使用新版说明。它需要应用实际发送 OTel 数据，不能从空白环境推断出完整依赖。知识图谱版 APM。

如果目标是确认一次数据库等待，保留数据库调用 Span 和请求上下文可能已经够用；若需要定位 CPU 热点，还要安排剖析采集。选择能回答常见问题的采集组合，比把“自动”写进采购条件更具体。

自动采集也有不同深度

Grafana Beyla 利用 eBPF 获取 Linux HTTP/S、gRPC 服务的 RED 指标和事务级 Span，适合先补一层应用可见性。它有内核、BTF、权限与传播方式要求；细粒度业务操作仍可能需要语言 Agent 或手工插桩。官方也区分已有 OTel SDK 的服务，避免重复追踪和重复生成指标。Beyla 能力与限制。

因此，从 OneAgent 换到 Beyla，不应只核对请求数量。原先用来解释异常的线程、方法、数据库和资源证据，哪些仍在、哪些要补，应按具体运行时逐项对应。反过来，已经用 OTel SDK 表达业务操作的服务，也没有必要仅为改后端就重新定义所有 Span。

Dynatrace 自身支持 OTel。OneAgent Span Sensor 与 OTLP 导出同时记录同一内容时可能产生重复，受控双写也要区分“把同一份数据送两处”和“两套插桩各生成一次”。OneAgent 与 OTel。

已有查询能留下多少

假设工程师拿到一个 trace ID。Loki 可以先按稳定的服务、环境标签缩小范围，再过滤请求标识。每个请求 ID 都成为流标签，会制造大量日志流；这类高基数值更适合放到结构化元数据等合适位置。Loki 标签、结构化元数据。

这是一种需要维护的查询习惯，却不代表只能手写搜索框。Grafana Cloud 的关联入口和预置应用视图可以组织这些数据；原有 PromQL、LogQL 经验仍有价值。迁到 Dynatrace 后，Grail/DQL 和实体模型则要重新映射，不能只把看板标题复制过去。

尤其要保留告警的含义。错误数量、错误率和失败请求占比可能来自不同采集与采样路径。迁移后曲线更低，既可能是服务变好了，也可能是分母或被保留的数据变了。先用同一时间窗口和业务请求范围对照，再讨论异常检测谁更有效。

日志便宜不便宜，要看写入和回查

当前 Grafana Cloud Logs 分别计量 processed、written、retained 和超出公平使用额度的 queried 数据。Adaptive Telemetry 丢弃数据可以减少写入量，但不会抹掉已经发生的处理量；月度查询包含额度为写入日志量的一百倍。付费账户基本保留期为三十天，延长保留另有计量，不能从 Loki 的索引结构直接推导整张云服务账单。Logs 计费。

例如某个 stack 当月写入 100 GB，查询额度对应 10,000 GB；实际查询 12,000 GB，超出的 2,000 GB 才进入该查询维度。这里还没计算 processed、written、额外保留和产品费用，也没有换算成美元报价。

Dynatrace 的常规日志模式将摄取处理、保留和查询分开；Retain with Included Queries 则包含所设时间窗口内的查询，并有每日扫描额度：窗口内留存日志 GiB 的十五倍。超出后官方会协助评估和优化，范围外的旧数据按相应规则计算。两家都不能概括成“查询永远免费”或“每次查询必定另收一笔”。Dynatrace 日志模式。

比较完整的应用账单

Grafana Cloud Application Observability 有 host-hours 产品费，产生的遥测也按相应规则计费。2026-02-13 起的新客户不适用旧模型的遥测 credits；此前客户的较高 host-hour 费率及包含量，应按自己的合同核对。自己用基础遥测构建看板、告警而不使用该 APM 产品，则没有这项 APM host-hour 费用，但仍有遥测和可视化费用。Serverless 又有单独计量安排。Application Observability 计费。

Dynatrace host-based Full-Stack 的计量与主机 RAM 和运行时间有关：物理机或 VM 最低 4 GiB，向上取至 0.25 GiB 的整数倍，按十五分钟区间计量。相同十台主机，8 GiB 和 64 GiB 不会产生同样的 memory GiB-hours；容器专用模式也有不同规则。Full-Stack 用量。

Grafana Cloud 指标另看活跃序列和数据点频率，不能只数指标名称。一个新增的高基数标签，可能让序列远多于主机数。采购比较应使用同一组实际遥测、保留目标、使用者和产品范围，而不是引用“通常只要三分之一”。指标用量。

保留已经有效的调查方式

团队已有成熟 Grafana 查询与 OTel 规范，希望把后端运行交给托管服务，同时继续使用这些资产，Grafana Cloud 更值得优先评估。它的云端 APM 和知识图谱也应进入实际比较，不能按几年前的纯看板印象判断。

团队日常依赖 OneAgent 的深度应用、进程和资源证据，且这些覆盖已经适合现有技术栈，继续使用 Dynatrace 可能省去大量迁移工作。需要客户环境部署时，应另按 Managed 的功能和合同评估，不能把 SaaS/Grail 的全部能力搬进同一报价。

两边分工也可以成立，例如保留现有应用调查，逐步调整日志路径。但字段、时间范围、权限和跳转链接要有人维护；两份 SaaS 账单之外，还存在长期的交接成本。

在观测云中对照一次完整请求

观测云的链路详情提供已采集请求、关联日志及资源信息的调查入口。把同一条慢请求放到这个流程中，查看关联是否完整，比单独比较功能名称更有用。链路详情。

采集支持、服务命名和保留策略仍要安排。由供应商运行后端，可以减少相应集群运维；业务操作如何表达、哪些证据应保留，仍然是团队需要做的决定。