Graylog 与 Splunk：从日志字段到可靠的调查流程

一个分支机构的防火墙升级后，原来的拒绝访问告警突然不再触发。日志并没有停止发送，只是事件字段和格式变了。总部门户仍显示“设备在线”，而真正负责排查的人需要重新找出规则命中的地址、账号和时间。

这类问题很适合用来比较 Graylog 与 Splunk。它不依赖演示环境中漂亮的图表，而是考验平台怎样接收异构日志、管理解析规则、保持查询含义，以及把平台自己的故障暴露出来。本文以 Graylog 的日志管理与 Splunk Enterprise、Splunk Cloud Platform 为主；安全产品的授权和工作流另外说明，不把它们混成一个套餐。

日志收到之后，先让字段可靠

Graylog 的处理路径围绕接入、解析、流水线和 stream 展开。Stream让符合条件的消息进入指定的数据路径，流水线可以补充、转换和路由字段。创建 stream 时通常指定 index set，采用数据路由后还可选择其他受支持的目的地。这些配置会影响后续搜索和保留方式，并非只是给界面加一个筛选标签。

防火墙升级后，如果来源地址从 src_ip 变成了另一种表达方式，团队需要明确在哪里归一化、原字段是否保留、哪些告警依赖旧字段。最好同时保留成功解析和解析失败的样本，避免“错误日志没有出现”被误读为“没有异常”。没有针对格式变更的检查，再强的搜索界面也会在不完整的数据上工作。

Splunk 也有接入和字段处理，但大量知识可以在搜索时定义：字段提取、别名、lookup 以及事件分类。官方搜索时处理顺序说明了这些操作的依赖关系。修改一个字段提取，可能影响多个共享搜索；迁移一条 SPL 告警，也可能需要一起迁移它背后的知识对象。

因此，两边都要维护字段契约。防火墙、身份系统和应用日志中的账号、地址、结果与时间，需要有明确而一致的含义。事件进入系统时就丢掉了地址，后面的告警查询再正确也无法命中；只有处理路径清楚，团队才不会把解析失败当作查询问题。

观测云的日志详情提供字段及相关数据的查看入口，也依赖这份字段契约。地址、账号和时间解析正确后，记录才便于继续调查；若要连接资源或链路，相应数据还须已接入，并满足字段、权限与留存条件。统一入口不会修复一条格式升级后已经漏掉关键字段的日志。

运维要覆盖日志数据，也要覆盖配置

Graylog 当前推荐的组件结构包含 Graylog、Data Node 和 MongoDB：前者承担处理与界面，Data Node 提供日志索引和搜索后端，MongoDB 保存配置与元数据。只给日志存储做备份，不足以恢复用户、权限、仪表盘和流水线规则。

这也意味着不能照着多年前的 Elasticsearch 部署文章直接升级当前环境。应以所用 Graylog 版本的兼容关系规划迁移，并将证书、配置、存储容量与处理积压一起纳入监控。Data Node 帮助管理搜索集群，并不让这些运行责任消失。

Splunk Enterprise 的自管环境同样需要明确索引、搜索和配置的运行职责。改用 Splunk Cloud Platform，则应根据托管服务边界重新分工。Graylog 也提供 Cloud 方案；比较时最好让自管对自管、托管对托管，再讨论团队想保留多少控制权，避免把一边的运维人力省略掉。

日志来源中断时，设备在线并不能说明事件仍在到达，平台本身还需要暴露数据缺口。恢复时也有相同的区别：存储服务启动，只说明组件恢复了；配置、权限、告警和报表仍能表达原来的含义，调查工作才真正回来。这是备份范围必须同时包含数据和配置的原因。

长期保存不等于一直留在同一查询路径

不同日志不需要相同的使用方式。应用错误可能持续用于告警，低频设备审计数据则可能只在调查时才取回。在自管部署中，Graylog 的数据分层区分热、温与归档等安排，相关高级能力需要相应企业许可。Graylog Cloud 不提供这套分层配置功能，高级索引与存储安排由托管服务处理。归档保存和重新处理，与日常搜索后端中的数据不是同一条操作路径。

设计保留策略时，应先问一条旧记录需要多久能交付给调查人员，再选择存储层。要立即驱动告警和报表的数据，不应仅作为待取回资料处理。灰度调整路由之前，还应确认是否改变了检索范围、权限和数据重复写入，不能只观察总存储量有没有下降。

Splunk Cloud 也需要区分可搜索保留与归档。索引管理文档给出可搜索数据的管理方式，归档或外部存储方案有各自的恢复条件。采购时把“保留一年”改写成“哪几类数据一年内要在多长时间内查到”，会更容易得到可比较的配置。

历史数据迁移也遵循相同逻辑。新平台开始接收今天的日志，并不代表过去的证据已经可查。可以保留一段旧平台只读窗口，明确查询入口、账号和下线时间，避免事故复盘时才发现报表跨越了两个互不连接的时间段。

日志管理与安全产品要分别选

Graylog Open 是 SSPL 下的源码可用版本；不能直接等同于没有许可条件的任意开源组件。Enterprise 提供商业日志管理能力，Security 则在其基础上增加 SIEM 工作流。现行产品与价格页按日处理量或年度 GCU 消费授权，不是按节点数收费；Enterprise 与 Security 公示起价分别为每年 15,000 和 18,000 美元，具体范围要按报价确认。

Splunk Enterprise Security 也不是基础 Splunk Enterprise 或 Cloud Platform 的另一个名称。它有单独的许可要求，同时依赖底层平台容量。若需求包括检测内容、调查分派和响应流程，就应比较对应安全产品，而不是用两边日志搜索的差别直接推导 SIEM 的胜负。

已有 Splunk 的团队还应盘点规则、数据模型、lookup 和运行手册：哪些只是通用字段映射，哪些直接依赖现有安全工作流。已有 Graylog 的团队则应识别当前版本真正缺少的是解析和治理，还是需要商业版的访问、报告或安全能力。增加产品之前，先确定工作缺口在哪里。

费用要跟着处理路径一起算

对于 Graylog，当前授权关注活动数据层的处理量；接入多少设备与实际处理多少数据不是同一个数字。补充资产字段会增大记录，也可能减少人工查找。对高频消息选择性补充上下文，比对每条日志无差别复制整份资产信息更容易解释其价值。

Splunk 的现行报价模型包含摄入、工作负载和 Cloud Platform 的 activity-based 方案。后者同时考虑摄入与搜索活动；工作负载方案的 Cloud Platform 使用 SVC，而 Enterprise 使用 vCPU。不能从“日志每天多少 GB”这一项推出所有合同的费用。

把真实日志格式、处理后大小、留存和查询并发放进估算，同时列出自管资源、备份、升级、迁移规则与培训投入。免费版本不代表没有运行成本，商业版本的起价也不是整个项目总价。没有相同范围的报价和工作量，诸如“只花十分之一”的结论没有依据。

如果主要工作是集中处理明确的一组日志来源，Graylog 的流水线、路由和版本选择值得先验证。如果团队已经依靠大量 Splunk 知识对象与安全流程，应该先测迁移这些工作需要多少改变，而不是从品牌大小判断是否保留。

资料核对日期：2026 年 10 月 21 日。本文依据官方文档讨论选型，没有进行性能、恢复时间或费用实测。