聊聊Flume和Logstash的那些事儿

 

转载：http://blog.csdn.net/jek123456/article/details/65658790

在某个Logstash的场景下，我产生了为何不能用Flume代替Logstash的疑问，所以查阅了很多材料在这里总结，大部分都是前人的工做经验下，加了一些我本身的思考在里面，但愿对你们有帮助。

本文适合有必定大数据基础的读者朋友们阅读，但若是你没有技术基础，照样能够继续看（这就比如你看《葵花宝典》第一页：欲练此功，必先自宫，而后翻到第二页：若不自宫，也可练功，没错就是这种感受→_→）。

大数据的数据采集工做是大数据技术中很是重要、基础的部分，数据不会无缘无故地跑到你的数据平台软件中，你得用什么东西把它从现有的设备（好比服务器，路由器、交换机、防火墙、数据库等）采集过来，再传输到你的平台中，而后才会有后面更加复杂高难度的处理技术。

目前，Flume和Logstash是比较主流的数据采集工具（主要用于日志采集），可是不少人还不太明白二者的区别，特别是对用户来讲，具体场景使用合适的采集工具，能够大大提升效率和可靠性，并下降资源成本。

---

嗑瓜子群众：喂喂，上面全都是没用的废话，说好的故事呢=。=

咳咳，好吧，如今咱们开始讲正事。首先咱们给出一个通用的数据采集模型，主要是让不太懂计算机或者通讯的读者们了解一下。

普适环境的数据采集

其中，数据采集和存储是必要的环节，其余并不必定须要。是否是很简单？原本编程其实就是模块化的东西，没有那么难。可是这毕竟只是一个粗略的通用模型，不一样开源社区或者商业厂家开发的时候都会有本身的考虑和目的。咱们在本文要讨论的Flume和Logstash原则上都属于数据采集这个范畴，尽管二者在技术上或多或少都自带了一些缓冲、过滤等等功能。

---

好，咱们先来看Logstash，而后看Flume，等你所有看完你就知道我为何这么安排了。

Logstash是ELK组件中的一个。所谓ELK就是指，ElasticSearch、Logstash、Kibana这三个组件。那么为何这三个组件要合在一块儿说呢？第一，这三个组件每每是配合使用的（ES负责数据的存储和索引，Logstash负责数据采集和过滤转换，Kibana则负责图形界面处理）；第二，这三个组件又前后被收购于Elastic.co公司名下。是否是很巧合？这里说个题外话，原ELK Stack在5.0版本加入Beats（一种代理）套件后改称为Elastic Stack，这两个词是一个意思，只不过由于增长了Beats代理工具，改了个名字。

Logstash诞生于2009年8有2日，其做者是世界著名的虚拟主机托管商DreamHost的运维工程师乔丹 西塞（Jordan Sissel）。Logstash的开发很早，对比一下，Scribed诞生于2008年，Flume诞生于2010年，Graylog2诞生于2010年，Fluentd诞生于2011年。2013年，Logstash被ElasticSearch公司收购。这里顺便提一句，Logstash是乔丹的做品，因此带着独特的我的性格，这一点不像Facebook的Scribe，Apache的Flume开源基金项目。

你说的没错，以上都是废话。（手动滑稽→_→）

Logstash的设计很是规范，有三个组件，其分工以下：

一、Shipper 负责日志收集。职责是监控本地日志文件的变化，并输出到 Redis 缓存起来；二、Broker 能够看做是日志集线器，能够链接多个 Shipper 和多个 Indexer；三、Indexer 负责日志存储。在这个架构中会从 Redis 接收日志，写入到本地文件。

这里要说明，由于架构比较灵活，若是不想用 Logstash 的存储，也能够对接到 Elasticsearch，这也就是前面所说的 ELK 的套路了。

Flume结构图

若是继续细分，Logstash也能够这么解剖来看

Logstash三个工做阶段

貌似到这里。。。好像就讲完了。。。读者朋友们不要骂我，由于Logstash就是这么简约，所有将代码集成，程序员不须要关内心面是如何运转的。

Logstash最值得一提的是，在Filter plugin部分具备比较完备的功能，好比grok，能经过正则解析和结构化任何文本，Grok 目前是Logstash最好的方式对非结构化日志数据解析成结构化和可查询化。此外，Logstash还能够重命名、删除、替换和修改事件字段，固然也包括彻底丢弃事件，如debug事件。还有不少的复杂功能供程序员本身选择，你会发现这些功能Flume是绝对没有（以它的轻量级线程也是不可能作到的）。固然，在input和output两个插件部分也具备很是多相似的可选择性功能，程序员能够自由选择，这一点跟Flume是比较类似的。

大大的分割线，读者朋友们能够去上个厕所，而后再买一包瓜子了。

---

Logstash由于集成化设计，因此理解起来其实不难。如今咱们讲讲Flume，这块内容就有点多了。

最先Flume是由Cloudrea开发的日志收集系统，初始的发行版本叫作Flume OG（就是original generation的意思），做为开源工具，一经公布，实际上是很受关注的一套工具，可是后面随着功能的拓展，暴露出代码工程臃肿、核心组件设计不合理、核心配置不标准等各类缺点。尤为是在Flume OG的最后一个发行版本0.94.0中，日志传输不稳定的现象特别严重。咱们来看看Flume OG到底有什么问题。

Flume OG架构图

直到如今，你在网络上搜索Flume相关资料的时候还会常常出现Flume OG的结构图，这对新人来讲是很不友好的，很容易引发误导，请读者朋友们必定要注意！咱们能够看到Flume OG有三种角色的节点：代理节点（agent）、收集节点（collector）、主节点（master）。

流程理解起来也并不困难：agent 从各个数据源收集日志数据，将收集到的数据集中到 collector，而后由收集节点汇总存入 hdfs。master 负责管理 agent，collector 的活动。agent、collector 都称为 node，node 的角色根据配置的不一样分为 logical node（逻辑节点）、physical node（物理节点）。对logical nodes和physical nodes的区分、配置、使用一直以来都是使用者最头疼的地方。

Flume OG中节点的构成

agent、collector 由 source、sink 组成，表明在当前节点数据是从 source 传送到 sink。

就算是外行人，看到这里也以为很头大，这尼玛是谁设计出来的破玩意？

各类问题的暴露，迫使开发者痛下决心，抛弃原有的设计理念，完全重写Flume。因而在2011 年 10 月 22 号，Cloudera 完成了 Flume-728，对 Flume 进行了里程碑式的改动：重构核心组件、核心配置以及代码架构，重构后的版本统称为 Flume NG（next generation下一代的意思）；改动的另外一缘由是将 Flume 归入 apache 旗下，Cloudera Flume 更名为 Apache Flume，因此如今Flume已是Apache ETL工具集中的一员。

这里说个题外话，你们都知道，一般状况下大公司，特别是大型IT公司是比较排斥使用一些不稳定的新技术的，也不喜欢频繁变换技术，这很简单，由于变化很容易致使意外。举个例子，Linux发展了二十多年了，大部分公司都在使用RedHat、CentOS和Ubuntu这类旨在提供稳定、兼容好的版本，若是你看到一家公司用的是Linux新内核，那多半是一家新公司，须要用一些新技术在竞争中处于上风。

好，了解了一些历史背景，如今咱们能够放上Flume NG的结构图了

Flume NG结构图

卧槽，是否是很简单？！对比一下OG的结构，外行人都会惊叹：so easy！

此次开发者吸收了OG的血淋林教训，将最核心的几块部分作了改动：

一、NG 只有一种角色的节点：代理节点（agent），而不是像OG那么多角色；

二、没有collector，master节点。这是核心组件最核心的变化；

三、去除了physical nodes、logical nodes的概念和相关内容；

四、agent 节点的组成也发生了变化，NG agent由source、sink、channel组成。

那么这么作有什么好处呢？简单归纳有这么三点：

一、NG 简化核心组件，移除了 OG 版本代码工程臃肿、核心组件设计不合理、核心配置不标准等缺点，使得数据流的配置变得更简单合理，这是比较直观的一个改进点；

二、NG 脱离了 Flume 稳定性对 zookeeper 的依赖。在早期的OG版本中，Flume 的使用稳定性依赖 zookeeper。它须要 zookeeper 对其多类节点（agent、collector、master）的工做进行管理，尤为是在集群中配置多个 master 的状况下。固然，OG 也能够用内存的方式管理各种节点的配置信息，可是须要用户可以忍受在机器出现故障时配置信息出现丢失。因此说 OG 的稳定行使用是依赖 zookeeper 的。

三、NG 版本对用户要求大大下降：安装过程除了java无需配置复杂的Flume相关属性，也无需搭建zookeeper集群，安装过程几乎零工做量。

有人很不解，怎么忽然冒出来一个Zookeeper这个概念，这是个啥玩意？简单的说，Zookeeper 是针对大型分布式系统的可靠协调系统，适用于有多类角色集群管理。你能够把它理解为整个Hadoop的总管家，负责整个系统全部组件之间的协调工做管理。这个组件平时很不起眼，但很是重要。比如一支篮球队，五个队员个个都是巨星，因此咱们平时都习惯关注这五我的，可是整个球队的获胜缺不了教练的协调组织、战术安排，Zookeeper就比如是整个Hadoop系统的教练。比喻虽然有些生硬，只是想说明Zookeeper的重要性，也侧面说明NG在摆脱了Zookeeper的依赖后变得更加轻便，灵活。

说个题外话，OG版本的使用文档有90多页，而NG只用 20 多页的内容就完成了新版 Flume 的使用说明。可见在科学研究领域，人类老是在追求真理，而真理老是能够用最简单的语言描述出来。

到这里差很少Flume就讲的差很少了，由于这个线程工具从原理上讲真的很简单，三段式的结构：源（Source输入）——存储（Channel管道）——出口（Sink目标输出）。但也由于涉及到这三个结构，因此作配置就比较复杂，这里举个例子，咱们看看Flume在一些场景下是如何搭建布置的。

Flume集群部署

这里要纠正几个不少初学Flume朋友们的误区。首先，Flume已经能够支持一个Agent中有多个不一样类型的channel和sink，咱们能够选择把Source的数据复制，分发给不一样的目的端口，好比：

Flume的多重复用

其次，Flume还自带了分区和拦截器功能，所以不是像不少实验者认为的没有过滤功能（固然我认可Flume的过滤功能比较弱）。

读者可能会隐约感受到，Flume在集群中最擅长的事情就是作路由了，由于每个Flume Agent相连就构成了一条链路，这也是众多采集工具中Flume很是出色的亮点。可是也正由于如此，若是有一个Flume Agent出了问题，那么整个链路也会出现问题，因此在集群中须要设计分层架构等来实现冗余备份。但这么一来，配置又会变得很麻烦。

最后一个大大的分隔线

---

把Logstash和Flume都讲完了，咱们最后能够对比总结一下了。

首先从结构对比，咱们会惊人的发现，二者是多么的类似！Logstash的Shipper、Broker、Indexer分别和Flume的Source、Channel、Sink各自对应！只不过是Logstash集成了，Broker能够不须要，而Flume须要单独配置，且缺一不可，但这再一次说明了计算机的设计思想都是通用的！只是实现方式会不一样而已。

从程序员的角度来讲，上文也提到过了，Flume是真的很繁琐，你须要分别做source、channel、sink的手工配置，并且涉及到复杂的数据采集环境，你可能还要作多个配置，这在上面提过了，反过来讲Logstash的配置就很是简洁清晰，三个部分的属性都定义好了，程序员本身去选择就行，就算没有，也能够自行开发插件，很是方便。固然了，Flume的插件也不少，但Channel就只有内存和文件这两种（其实如今不止了，但经常使用的也就两种）。读者能够看得出来，二者其实配置都是很是灵活的，只不过看场景取舍罢了。

其实从做者和历史背景来看，二者最初的设计目的就不太同样。Flume自己最初设计的目的是为了把数据传入HDFS中（并非为了采集日志而设计，这和Logstash有根本的区别），因此理所应当侧重于数据的传输，程序员要很是清楚整个数据的路由，而且比Logstash还多了一个可靠性策略，上文中的channel就是用于持久化目的，数据除非确认传输到下一位置了，不然不会删除，这一步是经过事务来控制的，这样的设计使得可靠性很是好。相反，Logstash则明显侧重对数据的预处理，由于日志的字段须要大量的预处理，为解析作铺垫。

回过来看我当初为何先讲Logstash而后讲Flume？这里面有几个考虑，其一：Logstash其实更有点像通用的模型，因此对新人来讲理解起来更简单，而Flume这样轻量级的线程，可能有必定的计算机编程基础理解起来更好；其二：目前大部分的状况下，Logstash用的更加多，这个数据我本身没有统计过，可是根据经验判断，Logstash能够和ELK其余组件配合使用，开发、应用都会简单不少，技术成熟，使用场景普遍。相反Flume组件就须要和其余不少工具配合使用，场景的针对性会比较强，更不用提Flume的配置过于繁琐复杂了。

最后总结下来，咱们能够这么理解他们的区别：Logstash就像是买来的台式机，主板、电源、硬盘，机箱（Logstash）把里面的东西所有装好了，你能够直接用，固然也能够本身组装修改；Flume就像提供给你一套完整的主板，电源、硬盘，Flume没有打包，只是像说明书同样指导你如何组装，才能运行的起来。

讲完，收工。

---

参考文献：

《Flume日志收集与Map Reduce模式》张龙 译

《ELK stack权威指南》 饶琛琳 编著

www.2cto.com/kf/201607/530428.html  Flume综述与实例

www.dataguru.cn/thread-477981-1-1.html  Flume日志收集

www.ibm.com/developerworks/cn/data/library/bd-1404flumerevolution/index.html  Flume NG

shiyanjun.cn/archives/1497.html  Flume日志收集分层架构应用实践

www.cnblogs.com/xing901022/p/5631445.html  Flume日志采集系统

www.tuicool.com/articles/BJRz22V  Logstash指南

tchuairen.blog.51cto.com/3848118/1840596/  Logstash讲解与实战应用