1. 为什么需要集中的日志系统？
在分布式系统中，众多服务分散部署在数十台甚至是上百台不同的服务器上，要想快速方便的实现查找、分析和归档等功能，使用Linux命令等传统的方式查询到想要的日志就费时费力，更不要说对日志进行分析与归纳。
如果有一个集中的日志系统，便可以将各个不同的服务器上面的日志收集在一起，不仅能方便快速查找到相应的日志，还有可能在众多日志数据中挖掘到一些意想不到的关联关系。
作为DevOps工程师，会经常收到分析生产日志的需求。在机器规模较少、生产环境管理不规范时，可以通过分配系统账号，采用人肉的方式登录服务器查看日志。然而高可用架构中，日志通常分散在多节点，日志量也随着业务增长而增加。当业务达到一定规模、架构变得复杂，靠人肉登录主机查看日志的方式就会变得混乱和低效。解决这种问题的方法，需要构建一个日志管理平台：对日志进行汇聚和分析，并通过Web UI授权相关人员查看日志权限。
2. 日志系统选择与对比
关于企业级日志管理方案，比较主流的是ELK stack和Graylog。
常见的分布式日志系统解决方案有经典的ELK和商业的splunk。为什么没有选择上面的两种方案呢，原因主要是如下两种：
ELK目前很多公司都在使用，是一种很不错的分布式日志解决方案，但是需要的组件多，部署和维护相对复杂，并且占用服务器资源多，此外kibana也在高版本中开始商业化。
splunk是收费的商业项目，不在考虑范围。
3. 认识graylog
3.1 简介
graylog是一个简单易用、功能较全面的日志管理工具，graylog也采用Elasticsearch作为存储和索引以保障性能，MongoDB用来存储少量的自身配置信息，master-node模式具有很好的扩展性，UI上自带的基础查询与分析功能比较实用且高效，支持LDAP、权限控制并有丰富的日志类型和标准（如syslog，GELF）并支持基于日志的报警。
在日志接收方面通常是网络传输，可以是TCP也可以是UDP，在实际生产环境量级较大多数采用UDP，也可以通过MQ来消费日志。
3.2 优势
部署维护简单
资源占用较少
查询语法简单易懂(对比ES的语法…)
内置简单的告警
可以将搜索结果导出为 json
UI 比较友好
3.3 graylog单机架构图
3.4 graylog集群架构
4.2 Graylog优缺
4.2.1、Graylog优点
- 一体化方案，安装方便，不像ELK有3个独立系统间的集成问题。
- 采集原始日志，并可以事后再添加字段，比如http_status_code，response_time等等。
- 自己开发采集日志的脚本，并用curl/nc发送到Graylog Server，发送格式是自定义的GELF，Flunted和Logstash都有相应的输出GELF消息的插件。自己开发带来很大的自由度。实际上只需要用inotify_wait监控日志的MODIFY事件，并把日志的新增行用curl/nc发送到Graylog Server就可。
- 搜索结果高亮显示，就像google一样。
- 搜索语法简单，比如： source:mongo AND reponse_time_ms:>5000 ，避免直接输入elasticsearch搜索json语法搜索条件可以导出为elasticsearch的搜索json文本，方便直接开发调用elasticsearch rest api的搜索脚本。
3.2.2、Graylog缺点
- 控制台操作页面是英文的，针对国内开发使用者使用起来不方便，还得额外汉化，汉化可能失败
- 使用网络传输，可能会占用项目网络
