Dynatrace 与 Splunk：应用链路与日志调查如何分工

凌晨的支付超时已经恢复，第二天却多了一个问题：某个账户在故障期间反复尝试修改收款信息。应用团队打开 Dynatrace，看下游服务的响应时间和失败调用；安全团队打开 Splunk，找登录、权限变更和网关访问记录。两边都在调查同一段时间，关心的证据却不完全相同。

这也是 Dynatrace 与 Splunk 比较时容易错位的地方。一个团队要补的是应用调用上下文，另一个团队要保住的是跨系统日志和长期调查流程。先弄清楚这次采购准备接替哪一段工作，再讨论是否保留两个平台，往往比把品牌的全部功能列成一张表更有用。

先把 Splunk 的产品边界说清楚

本文谈到 Splunk 日志平台时，指的是自行运行的 Splunk Enterprise 和托管的 Splunk Cloud Platform。它们承载日志检索、分析及其上层工作流。Splunk Observability Cloud 则包含 APM、基础设施监控等能力；AppDynamics 也属于 Splunk 产品组合，但仍有自己的部署与产品文档。不能因为当前只购买了日志平台，就推断 Splunk 没有 APM，也不能把其他产品的能力直接算入现有日志合同。Splunk Observability Cloud 概览

Dynatrace 的 Full-Stack Monitoring 将受支持的应用调用、代码级分析和基础设施上下文放在同一套调查流程里。覆盖深度取决于技术栈、采集方式和配置，并不意味着所有服务都能无条件得到同样的代码细节。评估时应拿出实际的 Java 服务、异步队列、第三方调用和容器环境，逐项看证据，而不是只看演示中的一条完整链路。Full-Stack Monitoring 文档

因此，如果需求是替换已有 Splunk 日志检索，应该比较日志迁移和查询工作流；如果需求是给应用团队增加 APM，则应比较 Dynatrace 与实际拟采购的 Splunk APM 产品及其权益。这两个项目可能同时发生，但预算和验收范围需要分开写。

一条请求与一段历史，调查路径并不相同

应用超时通常从受影响的服务开始：哪个下游变慢，哪段调用消耗了时间，异常是否和某次发布、进程或主机变化有关。Dynatrace 的根因分析使用拓扑、事务和代码等上下文，帮助关联问题与影响范围。这能减少人工拼接线索的工作，但系统指出的原因仍需要结合具体请求和业务事实确认。根因分析机制

日志调查的起点可能只是一个账户、来源地址，或者一个很久以前出现过的错误字符串。团队需要跨服务搜索、提取字段，再把结果与资产、权限和业务记录对应起来。已经积累的 SPL 查询、字段规则、查找表和告警条件，实际上承载了团队对系统的认识。迁移时只复制原始日志，并不会自动搬走这些知识。

两条路径也会在同一个请求上汇合。假设 trace 显示支付调用失败，日志里记录了网关拒绝的业务原因；只有请求标识、服务名、环境和时间范围能够对齐，来回切换才有意义。将所有日志都发往一个地方，却没有维护这些字段，界面上即使出现关联入口，也不等于拥有可靠的业务关联。

同一个品牌，也需要配置日志与链路的连接

在 Splunk 体系内，Log Observer Connect 可以让 Observability Cloud 查询已经存于 Splunk 平台的日志，本身不重新存储或索引这些日志。它是一条值得评估的连接路径，但仍需要按部署方式配置连接、权限和可查询范围。不要把它理解为购买日志平台后，所有 APM 数据和权益都会自动出现。Log Observer Connect 配置

如果继续使用 Dynatrace 做应用调查、Splunk 保留日志，应先明确哪些数据需要双投，哪些只需要能够定位到另一端。双投会带来额外传输、存储和权限管理；只保留跳转又依赖字段一致及目标数据尚在留存期。两种方案都可以合理，关键是用真实事故中的请求验证交接过程。

这种验证可以从一个小服务开始：让应用负责人根据链路找到对应日志，再让安全负责人从账户记录定位到同一业务请求。检查的不是按钮能否打开，而是接手的人是否有权限、是否能复现查询，以及关键字段是否在脱敏或处理时被移除。这里描述的是建议的验收方法，并非本文已经完成的产品实测。

留存多久，要连同取回方式一起回答

“保存一年”没有说明这一年的数据能否随时检索。Splunk Cloud Platform 的索引可以设置可搜索留存期，期满后的去向则取决于配置。使用 Splunk 管理的归档服务 DDAA 时，可以将归档数据恢复到 Cloud Platform 搜索；使用自有存储 DDSS 时，归档数据不能直接从 Cloud Platform 搜索，恢复检索需要另行安排，例如恢复到 Splunk Enterprise。不能把两条归档路径的恢复体验当成同一种服务。索引与数据留存管理

这会影响调查承诺。如果安全团队要求几小时前的异常立即可查，近期数据的搜索容量需要留足；如果季度审计可以等待恢复，则可以单独评估归档成本、恢复流程和负责人员。真正应该验收的是“谁能在多长时间内拿到需要的记录”，而不是合同上的保存天数。

对于自行运行的平台，还要把索引、配置和访问控制一并纳入备份与恢复演练。原始记录找回了，但字段提取或查询权限没有恢复，调查仍可能停在半路。迁移方案也应保留旧系统的可访问期限，避免新数据已经切换、历史事件却无处查询。

安全工作流不能靠一份日志许可概括

Splunk Enterprise Security 是运行于 Splunk Enterprise 或 Cloud Platform 之上的付费产品，需要对应授权与基础平台容量。拥有日志平台，不等于自动拥有这套安全运营工作流；反过来，评估已有 Enterprise Security 的组织，也不能只比较普通日志搜索的功能和价格。Enterprise Security 许可说明

同样，不宜用“Dynatrace 只管性能”概括整个产品组合。这里需要拆开的是当前项目中的责任：应用风险、威胁调查、告警分派、事件留证分别由谁负责，所购买的产品是否覆盖这些步骤。平台可以提供数据和工具，但保留日志本身不会自动完成合规，私有部署也不会自动解决访问审批、审计与数据处理要求。

如果两个团队已经分别形成有效流程，先保留边界、减少重复采集可能比一次性合并更稳妥。若主要问题恰好是所有调查都在不同工具间断裂，则应把跨团队交接作为试用的核心，而不是只比较单个分析页面。

成本要跟着实际工作量走

Splunk 当前提供不止一种计费方式：除了按摄取量计费，还有工作负载计费，以及面向 Cloud Platform、同时衡量摄取与搜索活动的 activity-based pricing。工作负载口径下，Cloud Platform 使用 SVC，Enterprise 使用 vCPU；它们不能直接换算成每天摄取多少 GB。具体采用哪种方式、包含哪些产品和存储，需要以报价与合同为准。Splunk 计费模式

Dynatrace Full-Stack Monitoring 的主机计量则涉及内存 GiB-hour，而不是所有主机一个固定单价；日志摄取、留存、查询也需要另算。其包含查询的日志留存选项有适用窗口及扫描额度：在该窗口内，每 24 小时的额度为留存 GiB 的 15 倍，超过后官方可能协助优化使用，不能据此理解为无限查询；窗口外查询还要按相应规则计费。包含查询的日志留存示例

因此，预算表应分别放入应用覆盖范围、日志量、近期可搜索容量、归档与恢复需求，以及高峰时的查询负载。再加入并行运行期间的重复数据和维护工作，才能看见迁移的实际代价。厂商整合、折扣谈判或公开起价，都不能代替这张基于自身工作量的清单。

如果还在评估统一调查入口，也可以把观测云放入同一轮验证：用实际服务的日志字段与链路上下文检查关联过程，而不是先假设换个平台就能消除数据治理工作。最终值得保留的系统，是能让应用与安全团队接得住彼此证据、又能承担长期维护责任的那一套组合。