Datadog vs Graylog：日志平台该独立建设，还是接进统一排障流程

支付失败以后，值班同事先找到了网关的 502 日志。接下来要查的是上游超时，还是某个实例的内存压力？如果答案都在日志里，一套字段处理清楚、查询稳定的日志平台已经很有用；如果还要追到调用链和主机状态，日志只是调查的入口。

这也是 Datadog 与 Graylog 最值得讨论的区别。Graylog 围绕集中日志管理和安全分析建立工作流；Datadog 的常见采用方式，是让日志进入已有的基础设施与应用监控。两者都能搜索和处理日志，真正需要比较的是查到一条记录后，团队还要做多少工作。

资料核对于 2026-10-21，依据官方产品与技术文档分析，未进行双方性能测试。

先让同一个字段表达同一件事

一台设备把响应码写成 status，应用写成 status_code，网关又把它放在一段文本中。字段不统一，聚合出来的错误数量可能只覆盖一部分来源。即使搜索框能找到原始字符串，告警也未必能正确使用它。

Graylog 可以用 Pipeline 对消息做解析、转换和补充，再通过 Stream 组织数据与路由；这些工作不是只有付费安全产品才能做。Datadog 的日志 Pipeline 同样能够串联处理器、解析文本并规范属性，JSON 还可以做预处理映射。选型时，把自己的混合日志交给两边解析，比比较宣传页上的处理器数量更有意义。Graylog 数据管理、Datadog Pipeline。

可以挑一条跨时区的网关记录、一条多行异常和一条缺少服务名的应用日志，看时间是否正确、错误级别有没有被覆盖、字段类型能否稳定。规则上线以后，新版本应用改了格式，谁负责发现解析失败和补规则，也需要有明确归属。成熟规则库是一项资产，迁移时要把它算进去。

日志集中以后，调查还差哪一步

如果排障人员已经在 Datadog 查看服务延迟，日志中的 Trace ID、服务和环境信息可以把调查继续引向对应链路。前提是两边都采集了数据，标识能够匹配，并且目标 Trace 仍在保留范围内。装好 Agent 不代表每种日志框架都会自动补齐这些条件。Datadog 日志与 Trace 关联。

Graylog 的优势场景可以是另一种：设备、系统和应用日志集中处理，团队首先按来源、用户、时间或业务标识开展调查。它的日志管理和 SIEM 产品不能直接等同于一个包括应用插桩、完整调用链、浏览器体验在内的 APM 套餐。需要这些能力时，应明确现有工具如何与日志配合，而不是把日志搜索界面当成完整替代。

这里没有必要为“统一平台”付出不需要的迁移。如果现有 APM 已经稳定，日志是单独的容量和合规问题，补好两个系统间的业务标识与跳转，可能比整体换平台更实际。反过来，每次故障都要在几个工具之间重新输入条件，这部分日常摩擦也值得计入平台价值。

Open、Enterprise 与 Security 解决的不是同一层需求

Graylog Open 当前以 SSPL 提供源码，不能简单写成 Apache 或 MIT 许可的软件。它没有商业日志量限制，但免费许可不包括机器、存储和维护；对外提供服务或修改分发时，应按实际版本许可评估。Enterprise 增加企业日志管理能力；Security 面向 SIEM 工作流。采购时要分别核对所需的留存、访问控制、检测与支持，而不能把 Security 的功能都算给 Open。Graylog 产品与价格。

例如，运营团队想保留查询和定期报告，安全团队要检测规则、案件调查与响应。两边虽然共用日志，却未必需要同一份许可。审计日志“存下来了”，也不等于已经完成检测覆盖、权限分离和证据导出。

Datadog 也需要按产品核对。日志、APM、基础设施和安全相关能力并非一个基础价格全部覆盖。只比较 Graylog 的日志产品与 Datadog 的整套可观测账单，会把范围差异误认为单价差异。

存储可以自己掌握，维护也要接住

当前 Graylog 推荐的核心结构包括 Graylog、Data Node 和 MongoDB。Data Node 管理日志搜索存储，MongoDB 存放配置和元数据；仍可使用符合版本要求的自管 OpenSearch，但不应照搬旧文章中的 Elasticsearch 版本组合。Graylog Stack。

自建时，日志写入正常只是开始。搜索数据需要容量和副本规划，配置也需要备份；恢复了日志存储，若丢了 Pipeline、权限和告警配置，系统还不能算恢复。升级前要核对各组件兼容性，升级后要检查旧查询与解析结果。

日志平台最容易在业务故障时承受更高负载：异常堆栈变多，重试增加，工程师又同时搜索大时间范围。用平日平均写入量采购机器，很容易低估这种写入和查询叠加。评估自建时，应把积压能保留多久、恢复后多久追平、查询如何避免拖慢写入一起考虑。Graylog 部署结构。

托管方案能转移一部分后端维护，但应用日志格式、敏感字段、保留策略和权限仍归客户管理。比较 Graylog Cloud 与 Datadog 的具体托管方案时，也要看服务范围；不能拿一边自建的全部维护工作，去对比另一边只有订阅价格的报价。

交接时还可以做一次恢复演练：从备份重建一个隔离环境，按原有查询找回一笔业务记录，再检查告警是否还能触发。这个过程会暴露只备份数据、没有保存配置的问题，也能看清团队是否真的具备维护能力。演练得到的时间才适合写进内部恢复目标，不能用安装文档的几步操作代替。

保留三十天，和随时能查三十天

假设每天产生 200 GB 原始日志，三十天就是 6 TB 原始输入。这是输入规模，不是最终磁盘用量：压缩、索引、字段补充、副本和临时空间都会改变结果。把它当成确定的磁盘采购值，或者直接乘一个云端单价，都不够准确。

更有用的划分是：哪些日志需要立即搜索，哪些只在审计时调取，哪些根本不该保留。Graylog 的商业产品提供不同的数据分层与 Data Lake 能力；Datadog 的日志存储、索引和归档路径也要按所选方案分别核对。归档便宜并不代表恢复时间和再次查询免费。Graylog 价格说明、Datadog 日志归档。

保留策略最好从一次具体调查倒推：如果三周后收到客户投诉，能否用订单号找到日志？是否还需要链路？恢复历史数据要多久，由谁操作？这些答案比一个笼统的“保留天数”更接近实际需求。

还应留意字段补充带来的变化。原来每行只有时间、级别和消息，加上设备资产信息、部门与业务标签以后，记录会变大，却可能让调查少查几次资产系统。不能只把这部分增长当成浪费；同样，也不能把所有标签都无差别复制进每一行。先明确谁会用它筛选，再决定在哪个处理阶段保留。

让平台选择落在团队已有能力上

已经有维护搜索集群的人，主要需求又是日志集中和处理，Graylog 值得认真评估。现有 Datadog 的服务、主机和告警已形成工作流，把日志接入其中可能减少调查时的切换。若主要任务是安全运营，则应把所需 SIEM 能力与对应许可单独比较。

观测云也可以作为日志与应用排障的候选：日志详情支持字段分析，并在标识和数据满足条件时关联链路。采用 SaaS 时可减少日志后端建设；应用字段、采集范围和保留策略仍需团队定义。用同一批日志验证“找到记录以后能否继续定位”，再比较适用套餐和维护投入，结论会比只问哪家每 GB 更便宜可靠。观测云日志详情。