Dynatrace vs Sumo Logic：从慢请求到安全调查，证据怎样交接

登录接口突然变慢，几分钟后安全团队又发现同一批账号出现异常访问。应用团队需要解释请求在哪里等待，安全团队则要还原账号、来源地址和权限操作。它们可能在调查同一件事，但使用的证据与结论不同：一条慢链路不能证明入侵，几条可疑登录日志也不能解释线程为什么阻塞。

Dynatrace 与 Sumo Logic 的比较，适合从这次交接开始。已经依赖 OneAgent 调查服务运行状态的团队，关心深度证据能否留下；已经围绕 Sumo Logic 做日志检索和安全分析的团队，关心数据如何组织、扫描与关联。两者都有超出传统标签的能力，不能简单分成“APM”和“日志”。

资料核对日期：2026 年 10 月 21 日。本文依据官方文档讨论工作路径，未进行双方性能或成本实测。

服务变慢以后，两边各能提供什么

Dynatrace Full-Stack Monitoring 在受支持的 OneAgent 环境里提供请求、代码、进程和主机上下文。调查可以从异常服务进入一次调用，再看下游等待与资源条件。运行时、平台与监控模式决定具体覆盖；安装成功并不代表所有方法、队列和旧框架都已被观测。Full-Stack 范围与 支持矩阵

Sumo Logic 当前也提供 APM、RUM、Span 分析和服务图。服务图由进入平台的分布式追踪数据构建，服务详情可以继续查看链路、指标和服务看板。要比较的是自己系统里的接入结果：服务关系是否完整，能否继续找到请求细节，而不是先给整个产品划能力等级。APM 范围与 Services List and Map

以登录服务为例，先看浏览器到 API、API 到身份服务的上下文是否连贯，再确认错误、耗时和资源字段能否对应。若队列消息没有传播上下文，后端即使收到了两端 Span，也可能无法还原为同一条调用。Dynatrace 同样支持 OTel 接入；选择标准协议，不要求先放弃既有后端。Dynatrace OpenTelemetry 接入

真正值得保留的是调查中经常使用的那段证据。若 OneAgent 的进程与剖析信息对定位问题不可替代，可以先保留它，再单独评估日志去向；若原有排障已经以 OTel 和结构化日志为主，迁移范围则可以不同。

日志查得更精确，不一定扫描得更少

Sumo Logic Flex 当前以日志分析和扫描为核心计费，官方 FAQ 说明摄入与索引本身不收费。它与旧的 Continuous、Frequent、Infrequent 数据层不是同一套设计，既有 Cloud Flex 账号的适用范围也要分别看，不能用旧冷热分层的价格逻辑解释所有账户。Flex 说明

这会改变日志组织方式。Flex 查询的成本与选中的分区和时间范围有关；加入一个错误关键字，通常不能像缩小分区那样减少扫描量。假设登录与支付日志都进同一个大分区，只搜索某个账号仍可能扫描该分区内对应时段的数据。把经常独立调查的来源合理分区，再限制时间，比单纯增加过滤词更有意义。

例如下面只表示查询范围，不是执行过的性能测试；auth_prod 必须是实际存在的分区：

_index=auth_prod AND _sourceCategory=prod/auth

如果把范围写成 _index=auth_prod OR error，error 可能出现在其他分区，扫描范围就可能重新扩大。迁移原有告警时，不仅要确认结果相同，还要检查定时执行的查询会覆盖哪些分区。Flex 查询优化与默认范围

Dynatrace SaaS 的日志进入 Grail 后可以通过 DQL 筛选与分析。其标准日志模型区分摄入、保留和查询扫描，也提供 Retain with Included Queries 方案；后者仍受配置的时间窗口与额度限制。24 小时内包含的扫描额度为该窗口内留存 GiB 的 15 倍，超出后官方说明会协助评估与优化消费，不能概括成无限查询。日志计量与 包含查询的保留方案

因此，偶尔回查一周日志，与持续运行宽范围检测，是两种不同的消费形态。查询频率、分区、保留和日常调查习惯，要与日摄入量一起记录。

安全调查需要自己的数据处理

在 Sumo Logic Cloud SIEM 中，原始消息经过解析、字段映射、规范化和富化形成 records，检测规则再产生 signals，并围绕实体组织后续调查。一个 IP 在不同来源中叫什么、账号名称是否规范、事件时间是否正确，会直接影响关联。把所有日志收进平台，并不等于已经建立有效检测。记录处理流程与 Cloud SIEM 规则

Cloud SIEM 需要启用相应产品能力。它的 records 和 signals 位于独立 security data tier，扫描安全索引不计入 Flex 扫描消费；这不表示 Cloud SIEM 本身免费，也不能据此把普通应用日志的扫描规则套到安全数据上。Cloud SIEM 访问范围与 安全数据扫描说明

对这次登录异常，性能团队可以提供受影响服务、请求时间和发布信息；安全团队继续核对身份、来源与行为模式。把两个结果关联起来，有助于分辨异常流量、权限问题和普通性能回归，但任何自动分析结论都应保留可追溯的原始证据。

若采购目标包含安全运营，就应按相应安全产品与检测流程评估。不能把 Dynatrace APM 与完整 Cloud SIEM 当成同一功能包，也不能因为 Dynatrace 的应用调查有效，就推断它自动满足所有日志审计要求。

保留两套平台时，减少的是哪部分工作

把历史日志迁出、保留 Dynatrace 应用监控，是一种可能的分工，但收益来自具体减少的消费。OneAgent 仍在运行，Full-Stack 用量不会因为日志换了目的地就消失。当前 DPS 主机 Full-Stack 按内存 GiB-hours 计量，每主机至少 4 GiB，按 0.25 GiB 向上取整、以 15 分钟区间计算，不能只按主机台数估算。主机计量规则

Sumo Logic 侧也要区分 Flex 日志扫描、保留和其他遥测或产品的 credits。信用单位是账户用量的表示方式，并不让日志、指标、追踪和 SIEM 获得同一个无差别单价。Flex 账户与 credits

双写期间，额外出口流量、两边字段处理、权限与保留策略都需要维护。更重要的是不要让调查在链接处中断：链路已过期、日志还在，或同一个 service.name 在两套环境里含义不同，都会增加人工判断。先让一例真实故障能跨平台复现，再决定是否扩大分工。

本文的 Grail 与当前 DPS 讨论以 Dynatrace SaaS 为范围。Managed 部署不能默认获得所有依赖 Grail、AppEngine 的新应用；Sumo Logic SaaS 的区域、接入和合同范围也要与实际账户一致。Dynatrace Clouds 应用前提

选择应跟着团队经常交接的证据走

若反复卡在请求、进程和主机之间，优先验证 Dynatrace 支持范围内的深度调查；若日常工作以大批日志的分区查询、检测规则和安全分析交接为主，优先验证 Sumo Logic 对这些工作流的承接。两边的 APM 或日志能力都应按真实任务评估，避免先把其中一方排除在外。

拿登录异常验收时，最终应能说清请求在哪里等待、哪些账号受到影响、哪些材料支持安全判断，以及保存和重复查询这些材料需要多少用量。这样的结论比“日志一定迁走更便宜”更能指导采购。

在观测云核对日志与请求关联

观测云支持将日志与已采集链路关联。评估时可以沿同一请求确认服务、时间和 Trace ID 是否一致，再判断这条调查路径是否适合团队。关联能力不能补回未采集的数据，也不能代替安全检测规则与权限设计。观测云日志关联