Graylog 集中日志管理

这是 Graylog 系列最后一篇。 日志集中保存到 Graylog 后就可以方便的使用搜索了。不过有时候还是需要对数据进行近一步的处理。主要有两个途径： 直接访问 Elastic 中保存的数据 通过 Graylog 的 Output 转发到其它服务…

Graylog 通过 Input 搜集日志，每个 Input 单独配置 Extractors 用来做字段转换。 Graylog 中日志搜索的基本单位是 Stream，每个 Stream 可以有自己单独的 Elastic Index Set，也可以共享一个 Index Set。用 Set 是因为日志的保存会使用一个前缀然后滚动创建新的 Index。Stream 通过配置条件匹配日志，满足条件的日志添加 stream ID 标识字段并保存到对应的 Elastic Index Set 中。同一个 Input 中的日志可以属于不同的 Stream，不同 Input 中的日志可以属于同一个 Stream，就是同一条日志也可以属于多个 Stream。 系统会有一个默认的 Stream，所有日志默认都会保存到这个 Stream 中，除非匹配了某个 Stream，并且这个 Stream 里配置了不保存日志到默认 Stream。 下图是日志处理流程图 Graylog 日志处理 后文会分别分享各个步骤需要注意的一些地方。

Graylog 通过 Inputs 收集日志，方式以被动接收为主，需要在产生日志的地方将日志发送给 Graylog。比较常用的一些方式： 程序中直接集成可以发送日志给 Graylog 的库，在 Github 中搜索 GELF 可以找到大量各种语言、框架、环境下的库。 采用传统的文件来记录日志，在机器上启动一个 agent 程序抓取日志文件新的内容然后发给 Graylog。 使用 syslog 写日志，利用 rsyslog 的转发功能把日志发给 Graylog。 服务器端日志个人推荐最后一种方式，优点有 不依赖 Graylog，可以替换成任何能接收 syslog 的其它方案。 容易 Fallback，rsyslog 可以配置成同时保存到本地文件和转发 Graylog。当 Graylog 出现问题至少还有本地日志文件可以用。 rsyslog 的日志保存，转发已经非常成熟和稳定。 缺点是 rsyslog 日志会把整条日志作为 message 字段保存。Graylog 内部每条日志是作为 Elastic 的 Document 保存的，细化出更多的字段能满足复杂查询和数据分析的需求。所以 Graylog 基于 JSON 制定了 GELF 协议，使用 GELF 协议的 Input 可以在产生日志时直接设置各种字段。不过 Graylog 还提供了 Extractor，和 fluentd, logstash 中的 filter 相似，可以从日志中提取结构化字段出来，比如 JSON Extractor 可以解析 JSON 格式日志。使用过类似工具的应该对 Grok 很熟悉，Graylog 也提供了支持。所以使用 rsyslog 也只需要制定下日志格式，然后配置下 Extractor。 Graylog 自带了丰富的 Inputs 可供使用，同时可以通过插件扩展，可以结合自己的使用场景选择合适的方式。 本文接下来会介绍日志收集需要注意的地方，以及如何基于 rsyslog 来打造集中日志系统。

使用 Graylog 之前试过很多方案，包括流行的 ELK，也用过 fluentd 搭配各种存储，influxdb, mongodb 等等。但这些方案在日志量大了之后出现性能瓶颈都没有提供解决方案。而 Graylog 作为整合方案，使用 elasticsearch 存储，mongodb 缓存，带流量控制 (throttling)，简单易用的查询界面，方便的管理界面，易于扩展。转移到 Graylog 省心了不少。在使用过程中积累了些经验，准备陆续分享出来。 第一篇是关于如何安装 Graylog。