日志采集框架Flume
1 Flume介绍
1.概述
Flume是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统。
有问题：并未实现高可用，老版本的flumeOG依赖zookeeper构建了一个master+各个agent的架构，用来管理各个agent的工作，但是这样做可以说毫无意义，高可用需要保证的是agent的高可用，目前已经取消了这种架构，并且并不支持agent高可用
Flume可以采集文件，socket数据包等各种形式源数据，又可以将采集到的数据输出到HDFS、hbase、hive、kafka等众多外部存储系统中
一般的采集需求，通过对flume的简单配置即可实现
Flume针对特殊场景也具备良好的自定义扩展能力，因此，flume可以适用于大部分的日常数据采集场景
flume的数据流由事件(Event)贯穿始终。事件是Flume的基本数据单位，它携带日志数据(字节数组形式)并且携带有头信息，这些Event由Agent外部的Source生成，当Source捕获事件后会进行特定的格式化，然后Source会把事件推入(单个或多个)Channel中。你可以把Channel看作是一个缓冲区，它将保存事件直到Sink处理完该事件。Sink负责持久化日志或者把事件推向另一个Source。
（1）flume的可靠性
当节点出现故障时，日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障，从强到弱依次分别为：end-to-end（收到数据agent首先将event写到磁盘上，当数据传送成功后，再删除；如果数据发送失败，可以重新发送。），Store on failure（这也是scribe采用的策略，当数据接收方crash时，将数据写到本地，待恢复后，继续发送），Besteffort（数据发送到接收方后，不会进行确认）。
（2）flume的可恢复性
还是靠Channel。推荐使用FileChannel，事件持久化在本地文件系统里(性能较差)。
一些核心概念：
Client：Client生产数据，运行在一个独立的线程。
Event： 一个数据单元，消息头和消息体组成。（Events可以是日志记录、 avro 对象等。）
Flow： Event从源点到达目的点的迁移的抽象。
Agent： 一个独立的Flume进程，包含组件Source、 Channel、 Sink。（Agent使用JVM 运行Flume。每台机器运行一个agent，但是可以在一个agent中包含多个sources和sinks。）
Source： 数据收集组件。（source从Client收集数据，传递给Channel）
Channel： 中转Event的一个临时存储，保存由Source组件传递过来的Event。（Channel连接 sources 和 sinks ，这个有点像一个队列。）
Sink： 从Channel中读取并移除Event， 将Event传递到FlowPipeline中的下一个Agent（如果有的话）（Sink从Channel收集数据，运行在一个独立线程。）
1.2运行机制
1、 分布式系统中最核心的角色是agent，flume采集系统就是由一个个agent所连接起来形成
2、 每一个agent相当于一个数据传递员，内部有三个组件：
Source：Source是数据的收集端，负责将数据捕获后进行特殊的格式化，将数据封装到事件（event） 里，然后将事件推入Channel中。Flume提供了各种source的实现，包括Avro Source、Exce Source、Spooling Directory Source、NetCat Source、Syslog Source、Syslog TCP Source、Syslog UDP Source、HTTP Source、HDFS Source，etc。如果内置的Source无法满足需要， Flume还支持自定义Source。
Sink：下沉地，采集数据的传送目的，用于往下一级agent传递数据或者往最终存储系统传递数据。 Flume Sink取出Channel中的数据，进行相应的存储文件系统，数据库，或者提交到远程服务器。Flume也提供了各种sink的实现，包括HDFS sink、Logger sink、Avro sink、File Roll sink、Null sink、HBase sink，etc。Flume Sink在设置存储数据时，可以向文件系统中，数据库中，hadoop中储数据，在日志数据较少时，可以将数据存储在文件系中，并且设定一定的时间间隔保存数据。在日志数据较多时，可以将相应的日志数据存储到Hadoop中，便于日后进行相应的数据分析。
Channel：Channel是连接Source和Sink的组件，大家可以将它看做一个数据的缓冲区（数据队列），它可以将事件暂存到内存中也可以持久化到本地磁盘上， 直到Sink处理完该事件。Flume对于Channel，则提供了Memory Channel、JDBC Chanel、File Channel，etc。
MemoryChannel可以实现高速的吞吐，但是无法保证数据的完整性。
MemoryRecoverChannel在官方文档的建议上已经建义使用FileChannel来替换。
FileChannel保证数据的完整性与一致性。在具体配置不限的FileChannel时，建议FileChannel设置的目录和程序日志文件保存的目录设成不同的磁盘，以便提高效率。
Source到 Channel 到 Sink之间传递数据的形式是Event事件；Event事件是一个数据流单元。
1.3 Flume采集系统结构图
1.简单结构
单个agent采集数据
2.流的合并（多个Agent的数据汇聚到同一个Agent ）
这种情况应用的场景比较多，比如要收集Web网站的用户行为日志，Web网站为了可用性使用的负载集群模式，每个节点都产生用户行为日志，可以为每 个节点都配置一个Agent来单独收集日志数据，然后多个Agent将数据最终汇聚到一个用来存储数据存储系统，如HDFS上。
3.多路复用流（多级流）
Flume还支持多级流，什么多级流？来举个例子，当syslog，java，nginx、tomcat等混合在一起的日志流开始流入一个agent后，可以agent中将混杂的日志流分开，然后给每种日志建立一个自己的传输通道。
4.load balance功能
下图Agent1是一个路由节点，负责将Channel暂存的Event均衡到对应的多个Sink组件上，而每个Sink组件分别连接到一个独立的Agent上 。
2.Flume的source类型
配置参考：http://flume.apache.org/FlumeUserGuide.html#flume-sources
3.Flume的sink类型
参考配置：http://flume.apache.org/FlumeUserGuide.html#flume-sinks
4.Flume的channel类型
参考配置：http://flume.apache.org/FlumeUserGuide.html#flume-channels
5.Flume的Interceptors类型
讲解：https://www.cnblogs.com/Transkai/p/10645067.html
参考：http://flume.apache.org/FlumeUserGuide.html#flume-interceptors
6.实际操作：Flume的配置方式
参考链接：https://www.cnblogs.com/qingyunzong/p/8996155.html
7.结合kafka
要结合具体场景：
二者都可以提供日志采集的功能，而flume功能更加特定，kafka更加通用，通用的代价就是在实现各种业务场景时都需要手动实现provider和consumer，所以当你单纯是想将日志数据采集传输给hdfs、hbase时，单独使用flume就可以（读取日志进行分析往往是多数据源的，如果Kafka构建多个生产者使用文件流的方式向主题写入数据再供消费者消费的话，无疑非常的不方便）；如果Flume直接对接实时计算框架，当数据采集速度大于数据处理速度，很容易发生数据堆积或者数据丢失，而kafka可以当做一个消息缓存队列，从广义上理解，把它当做一个数据库，可以存放一段时间的数据。一般使用Flume+Kafka架构都是希望完成实时流式的日志处理，后面再连接上Flink/Storm/Spark Streaming等流式实时处理技术，从而完成日志实时解析的目标；另，如果需要多个应用来消费数据，比如一边将数据导入hdfs，一边进行数据实时计算，还是用flume+kafka结合较好。
