Graylog vs ELK：日志管道、搜索与运维怎么选

支付服务发布以后开始返回 500。日志虽然已经集中，值班同事仍要先判断哪条属于新版本，再处理字符串形式的耗时字段；换成业务团队的账号，有些记录又看不到。搜索框里能查出内容，离真正查清故障还有一段距离。

Graylog 把输入、处理、Streams 和搜索组织成日志管理流程，适合日常工作主要围绕日志展开的团队。已有 Elasticsearch、映射和查询经验，Elastic Stack 往往更容易继续用下去。两边都要处理字段、保留和权限，差别在于这些工作怎样安排，以及团队已经熟悉哪一套。

观测云编辑部 · 资料核对于 2026-10-21，存储兼容范围按 Graylog 7.2 说明。下文是文档与工作方式比较，没有进行双方吞吐或查询性能测试。

一条日志进入搜索之前

ELK 原指 Elasticsearch、Logstash、Kibana，今天的 Elastic Stack 并不要求每条日志都经过这三个组件。Elasticsearch 保存并检索文档，Kibana 的 Discover、Lens、ES|QL 及相关应用提供调查入口，其保存的对象也位于 Elasticsearch。

Graylog 中，Inputs 接收日志，Pipeline 加工字段，Streams 组织与路由数据。当前架构由 Data Node 管理 OpenSearch，也可采用兼容的自管理 OpenSearch；MongoDB 保存配置等元数据，不是原始日志主存储。搜索后端仍然存在，不能把 Graylog 的管理界面理解成取消了底层存储维护。

Elastic 官方接入架构允许 Elastic Agent 直接把数据送到 Elasticsearch，Logstash 并非每套部署必需。需要额外转换、缓冲或路由时，再加入合适组件。把所有 Elastic 部署画成固定三件套，会高估一些场景的复杂度，也会低估复杂管道真正需要的工作。

假设应用输出 JSON，服务名、环境、响应码都有，耗时却偶尔写成字符串，时间戳还混用了本地时区。同一时间范围可能漏掉一部分事件，数值聚合也可能失败。改变搜索界面不会修复这些记录。

在 Graylog 中，可以先配置输入，把日志解析为稳定字段，再通过 Pipeline 规范数据，并由 Streams 将支付、网关等数据分开组织。Stream 关联的存储目的地和 index set 决定数据落到哪里；保留和访问策略应与业务分类一起设计。当前 Data Routing 文档把输入、处理和目的地连成一条配置路径，Data Lake 等目的地则有版本权益限制。

在 Elastic 中，可以让 Elastic Agent 的集成或 Logstash 完成接入，用 ingest pipeline 或 Logstash filter 做解析与补充，再通过映射确保耗时是数值、时间是日期。哪些处理放在采集端，哪些放在 Elasticsearch，要根据数据源、网络和缓冲要求决定。Elastic 数据转换与丰富。

解析失败的数据去了哪里，和成功记录怎样查询同样重要。缺字段、异常时间或超长内容被处理管道丢弃后，错误日志可能反而变少。没有失败记录的观察入口，很容易把数据缺失误认为业务恢复。

查一次故障，才能看出搜索方式是否合适

支付接口在发布后开始返回 500。使用 Graylog，可以先限定支付 Stream、发布时间和错误字段，再按版本或实例聚合；使用 Kibana，可以在 Discover中筛选同一时间范围和字段，再用 Lens 或 ES|QL 观察异常分布。两条路都需要一致的服务标识和字段类型。

汇总结果只说明哪组实例更异常，接下来还要回到原始记录解释错误。常用查询能否保存、值班角色能否读到对应数据，会决定这一步是否顺畅。管理员账户能完成的调查，普通角色未必能完成；原有查询、保存对象和权限也不会因为两边都使用搜索引擎就原样迁过去。

如果下一步需要判断“这次失败卡在数据库还是外部支付接口”，还需要追踪或其他证据。日志管理与完整 APM 有关联，但不是同一能力。Elastic 可以通过相应 Observability 接入继续调查；Graylog 的日志工作流也不能仅凭几条错误文本还原完整调用链。

Graylog 7.2 的存储兼容性，不能照搬旧教程

Graylog 的 Data Node负责管理 OpenSearch，包括版本、扩展与证书等工作；MongoDB 保存配置元数据。它减少了部分手工管理，但磁盘容量、恢复目标和备份验证仍然存在。

根据当前兼容矩阵，Graylog 7.2.x 的 MongoDB 范围为 7.x 至 8.2.x。使用自管理 OpenSearch 时，Open/Enterprise 的范围为 1.1.x 至 3.7.x，Security 为 2.0.x 至 3.7.x。但 OpenSearch 3.x 有明确条件：旧于 OpenSearch 2.0 创建的索引不兼容，已有部署升级前必须处理这些索引。

这也解释了为什么旧文档与新文档看似冲突：7.1 及更早版本的兼容上限不同。不能把“永远不能升级 3.x”照抄到 7.2，也不能用 7.2 的表证明旧版本可以升级。更不能因为旧教程里出现 elasticsearch_* 配置名，就认定当前 Graylog 支持任意最新版 Elasticsearch。

免费版本、归档和安全能力分开看

Graylog Open按 SSPL 提供源码与免费使用，包含核心日志收集、检索、看板和告警。它与 Enterprise、Security 不是同一权益集合。Data Lake、企业支持、特定归档与恢复能力，以及安全检测和调查功能，应对应实际版本与合同确认，不能统称为“Open 全部自带”。SSPL 也不应直接等同于 Apache 2.0 这类许可；面向他人提供托管服务时尤其要核对条款。

Elastic 同样需要区分源码许可、默认发行包和订阅功能。其免费源码部分在 2024 年增加 AGPLv3 选项，默认 Elasticsearch/Kibana 发行包仍为 ELv2；此前 7.11 的许可变更不是今天全部情况。Elastic 许可说明。需要哪些安全控制、连接器或分析功能，再对照订阅矩阵。

长期保存一份数据、随时在线查询、在规定时间内恢复，是三种不同的要求。归档平时便宜，取回时仍可能需要计算、临时存储和等待时间；保存了文件，也不等于权限和完整性已经满足审计要求。经常查历史的日志，和一年只恢复一次的日志，不必采用相同的存储方式。

维护工作最后落在哪里

自管理 Graylog 要计算 Graylog 服务、MongoDB、Data Node/OpenSearch、备份与维护；自管理 Elastic Stack 要计算 Elasticsearch、Kibana、实际需要的采集处理组件及订阅。托管方案减少部分运行工作，但仍有用量、网络、保留和迁移费用。两者不能因为都使用搜索技术就被判定为性能相同。

持续写入时的磁盘增长、查询并发和积压恢复，会把维护成本慢慢显露出来。只有少量近期查询，和几十个人同时回查一个月日志，不能按同一套资源估算。相同的保留时间也不代表相同的索引、备份与副本开销。

日志运营是主要工作，希望围绕输入、处理、分流和搜索建立清晰流程，Graylog 比较自然。Open 已能满足核心任务时，不需要为了完整产品目录采购所有版本；需要 Data Lake 或安全能力时，再把相应权益与费用算进去。

已有 Elastic 数据基础，团队熟悉查询、映射与集群运行，继续使用 Elastic Stack 更容易保留这些投入。采用能满足当前需求的接入方式即可，没有必要因为“ELK”三个字母就固定安装三个组件。

选择会随着工作变化。日常查询用顺了，只是偶尔一张图不够方便，未必值得迁移；每天都在为解析、权限和恢复问题返工，才值得重新安排整条日志处理路径。

在观测云中继续看日志上下文

这也是日志平台提供关联入口的意义。观测云的日志详情页可以沿字段查看相关主机、容器和链路等上下文，减少从孤立错误记录重新找线索的过程。相关数据必须已经采集，字段也要配置正确，才有可继续调查的内容。