背景
随着业务的快速发展，各种服务和组件也要随着增加或扩容，服务器的台数随之增加，这样给日志运维带来很大的问题。如果你要查阅某个项目的日志，服务器数十上百台的话，这将是一件非常繁琐和低效的事。另外，如果你想对这些日志进行实时的分析统计，也无从下手。因此，我们需要一种数据收集框架，它可以将不同服务器上的日志数据，高效地收集汇总在一起，供在线或者离线查阅和分析，并且还可以对系统实施监控和故障告警。
本文档通过介绍Flume NG、Scribe、Kafka、Chukwa和ELK的特点，结构模型，使用时的优势和劣势，以及我们自定义的指标项对比，最后得出它们各自的应用场景，为框架选型提供技术参考。
数据收集系统
Flume NG
Flume NG的介绍
Flume NG 是Cloudera提供的分布式数据收集系统，它能够将不同数据源的海量日志数据进行高效的收集、聚合、移动，最后存储到存储中心。Flume NG支持（故障转移）failover和负载均衡。
Flume NG的结构
Flume NG传输数据的基本单元是event，如果是文件，通常是一行记录。运行的核心是Agent，包含三个核心组件，分别是Source、Channel和Sink，其结构模型图如下：
- Source：接收外部源发送过来的数据，支持Avro、Thrift、JMS、Syslog、Kafka和Http post（自己代码实现）等多种方式的日志接收。提供ExecSource以tail -f等命令的方式实现实时日志收集；提供SpoolSource以读取新增的文件的方式实现低延时的日志收集。
- Channel：是一个存储池，接收Source的输出。有MemoryChannel、JDBC Channel、MemoryRecoverChannel和FileChannel等主要类型。其中MemoryChannel可以实现高速吞吐，但无法保证数据的完整性。FileChannel能实现数据的完整性和一致性。Channel中的数据仅会在数据保存在下一个Channel或最终的存储中心时，才会被删除。
- Sink：消费Channel中的数据，然后发送给数据存储系统（HDFS、Elasticsearch或者HBase等)。一个Agent可以存在多个Sink，Sink支持负载均衡和failover。
Flume NG的结构图：
-
多个Agent顺序连接：
最简单的部署方式，通过多个Agent连接，将原始数据传送到下一个Agent或者是最终的存储中心，适合初学者。
- 多个Agent的数据汇聚在同一个Agent中：
最常见的部署方式，比如在各个应用服务器上部署Flume NG，将原始数据同步到一台agent上。
- 多路Agent连接：
包括分流和复制两种方式，分流是根据header信息进行数据的分类存储数据，复制是将数据复制多份。
- 负载均衡数据模型：
Agent1负责路由，每个Sink连接一个Agent，Sink支持负载均衡和Failover。
Flume NG的优势劣势
- 优势：Flume NG通过事务保证数据的完整性和一致性；支持负载均衡；很容易进行水平扩展；社区活跃度高；文档资料比较丰富；依赖第三方库少；部署简单；支持多种存储系统。
- 劣势：Flume NG需要自己实现客户端代码；ExecSource方式会存在数据丢失的可能，SpoolSource方式做不到监控文件的新增记录；对数据的过滤能力较差。
Scribe
Scribe介绍
Scribe是Facebook开源的一个基于thrift框架的日志收集系统，在facebook内部已经得到大量的应用。Scribe可以从不同数据源，不同机器上收集日志，然后将它们存入存储中心，目前Facebook已停止对Scribe的更新和维护。
Scribe结构
- Scribe结构图：
- Scribe 客户端：需要自己基于Thrift框架实现，每条消息包含一个category和一个message信息，Scribe Server根据category将数据存储在不同的存储系统。
- Scribe Server：根据配置，将各个category类型的日志发到不同的存储系统。Scribe Server收集到数据后，将数据放到共享队列，然后Push到存储中心，当存储中心出现故障时，Scribe 会将数据保存在本地文件中，待存储中心恢复后再Push数据。
- 存储中心：包括HDFS、File和Scribe。
Scribe优势和劣势
- 优势：具有很高的容错性；支持水平扩展；
- 劣势：依赖zookeeper或Hash等其他工具；需要自己实现客户端代码；社区活跃度低；文档资料极少；依赖第三方库多；部署较为复杂；存储系统类型较少；数据过滤解析能力差；Facebook公司已停止更新和技术支持。
Kafka
Kafka的介绍
Kafka 是一个基于分布式的消息系统，开发自 LinkedIn ['lɪŋktɪn]，作为 LinkedIn 的活动流和运营数据处理管道。活动流数据包括页面访问量、被查看内容方面的信息以及搜索情况等。运营数据指服务器的性能数据，包括CPU、IO使用率、请求时间、服务日志等。
Kafka结构模型：
- Producer：消息发送者，负责发送消息给Broker。
- Kafka Cluster：由多个Kafka实例组成，每个实例（Server）成为Broker。集群的搭建依赖Zookeeper。
- Consumer：消息消费者，从Kafka读取消息。
- Topic：一类消息，类似Queue的概念，Topic在物理上是分节点存储。
- Consumer Group：实现一个Topic消息单播和广播的一个手段。要实现广播，只要每个consumer有一个独立的Group就可以。要实现单播，只要所有的Consumer在同一个Group里即可。
Kafka的优势和劣势
Kafka 通过系统解耦、Partition（分片存储）、复制备份、持久化、缓存、集群和异步通信等策略提供了一个高性能、高可靠、可扩展的数据管道和消息系统。
- 优势：高性能；高可靠；通过Kafka Conenector对接HDFS、Elasticsearch、JDBC等其它系统；支持水平扩展；社区活跃度高；文档资料丰富；依赖第三方库较少。
- 劣势：依赖Zookeeper；需要自己实现客户端代码；数据过滤解析能力差。
Chukwa
Chukwa的介绍
chukwa 是一个用于监控大型分布式系统的数据收集系统，构建在 Hadoop 的 HDFS 和 map/reduce 框架之上的，继承了 hadoop 的扩展性和健壮性，还包含HICC，可用于展示、监控和分析已收集的数据。
Chukwa的结构
- Agent：负责采集数据，并发送给Collector。agent采用“watchdog”的机制，自动重启终止的数据采集进程，防止数据丢失。
- Adaptor：直接采集数据的接口和工具，支持命令行，log文件和httpSender输出,可以按自己的需求实现Adaptor，一个Agent可以管理多个Adaptor的数据采集。
- Collectors：负责收集Agents发送过来的数据，并定时写入集群。
- Map/Reduce jobs：定时启动，在此阶段，Chukwa提供了demux [dɪm'ju:ks]和archive [ˈɑ:kaɪv]两种内置的作业类型，其中，demux作为负责对数据分类、排序、去重，archive作业负责把同类型的数据合并。
- HICC：负责数据的展示。
Chukwa的优势和劣势
- 优势：高可靠，易扩展；社区活跃度较高；文档资料较丰富；
- 劣势：依赖hadoop。
ELK
ELK的介绍
ELK 不是一款软件，而是Elasticsearch、Logstash和Kibana首字母的缩写。这三者是开源软件，通常配合一起使用，而且先后归于Elasic.co公司的名下，所以简称ELK Stack。根据Google Trend的信息显示，ELK已经成为目前最流行的的集中式日志解决方案。
Elasticsearch：是一个分布式搜索和分析引擎，具有高可伸缩、高可靠和易管理等特点。基于Apache Lucene构建，能对大容量的数据进行接近实时的存储、搜索和分析操作。通过简单的配置，Elasticsearch就会帮你管理集群、分片、故障转移、主节点选举等，还提供集群状态的监控接口。
Logstash：数据收集引擎。它支持从各种数据源收集数据，并对数据进行过滤、分析、丰富、统一格式等操作，然后存储到用户指定的位置。Logstash支持file、syslog、tcp、stdin、redis和kafka等多种接收方式。支持elasticrsearch、email、exec、nagios、tcp、hdfs等多种方式输出。
Kibana：数据分析和可视化平台。通常与Elasticsearch配合使用，对其中的数据进行搜索、分析并能以图表的方式显示。
Filebeat：ELK协议栈的新成员，一个轻量级开源日志文件数据搜集器。我们在需要采集日志数据的服务器上安装Filebeat，并指定日志目录或日志文件后，Filebeat就能读取数据，迅速发送到Logstash进行解析，亦或直接发送到Elasticsearch进行集中式存储和分析。FileBeat可以监听指定目录下是否新增文件，监听文件是否新增记录，文件在一定时间内没更新取消监听，支持批量数据传送，支持负载均衡的方式传送数据到Logstash或Elasticsearch。支持SSL/TLS协议传送。
ELK的结构
- 最简单的结构模型：
这种结构很简单，适合初学者。初学者可以搭建此结构，了解ELK如何工作。
- Logstash作为日志收集器：
这种结构模型需要在各个应用服务器上部署Logstash，但Logstash比较消耗CPU和内存资源，所以比较适合资源丰富的服务器，否则可能会导致应用服务器无法工作。
- Beats作为日志收集器，Beats包括四种：
- Packetbeat(搜集网络流量数据)
- Topbeat(搜集系统、进程、文件系统级别的CPU和内存使用情况等数据)
- Filebeat(收集文件数据)
- Winlogbeat(收集Window时间日志数据)
这种结构解决了Logstash在各服务器节点上占用资源高的问题。另外，数据格式规范的情况下，可以移出Logstash节点,Beats直接发送数据到Elasticsearch，解决Logstash占用资源高的问题。
- 引入消息队列机制
这种结构适合日志规模比较大的情况。引入消息队列，将上下游服务解耦，减轻下游服务的压力，解决在巨量日志下，网络阻塞延迟、数据丢失的问题，使得网络传输更稳定、更高效，避免级联效应。在巨量日志的情况下，Logstash节点和Elasticsearch节点负荷比较重，可将它们配置成集群模式，分担负荷。在日志比较规范的情况下，可以去掉Logstash,Beats直接发送数据到Elasticsearch，解决Logstash占用资源高的问题。
ELK的优势和劣势
- 优势：提供一套完整的日志收集、分析、存储和数据展示的解决方案；Logstash支持集群部署和水平扩展；Elasticsearch高可用，支持集群部署和水平扩展；社区活跃度高；文档资料较丰富；部署简单。
- 劣势：Logstash占用资源比较高。
指标项对比
结论
ELK告警策略
参考资料
Flume NG
http://blog.csdn.net/zhaodedong/article/details/52541688
http://www.gegugu.com/2016/04/11/5484.html
Scribe
http://www.itdadao.com/articles/c15a502872p0.html
http://www.36dsj.com/archives/66047
Kafka
http://www.cnblogs.com/likehua/p/3999538.html
http://www.infoq.com/cn/articles/kafka-analysis-part-1
Chukwa
http://www.it165.net/admin/html/201403/2507.html
http://f.dataguru.cn/thread-97612-1-1.html
ELK Stack 中文指南
http://kibana.logstash.es/content/
Logstash最佳实践
http://udn.yyuap.com/doc/logstash-best-practice-cn/index.html
Elasticsearch 权威指南
Elasticsearche配置：
https://my.oschina.net/topeagle/blog/405149
https://my.oschina.net/Yumikio/blog/805877
Filebeat配置：
http://m.blog.csdn.net/article/details?id=53584173
http://michaelkang.blog.51cto.com/1553154/1864225
Search Guard:
https://github.com/floragunncom/search-guard-docs
http://www.cnblogs.com/Orgliny/p/6168986.html
http://kibana.logstash.es/content/elasticsearch/auth/searchguard-2.html
