Flume环境部署和配置详解及案例大全

　　一、什么是Flume? 　　flume 作为 cloudera 开发的实时日志收集系统，受到了业界的认可与广泛应用。Flume 初始的发行版本目前被统称为 Flume OG（original generation），属于 cloudera。但随着 FLume 功能的扩展，Flume OG 代码工程臃肿、核心组件设计不合理、核心配置不标准等缺点暴露出来，尤其是在 Flume OG 的最后一个发行版本 0.94.0 中，日志传输不稳定的现象尤为严重，为了解决这些问题，2011 年 10 月 22 号，cloudera 完成了 Flume-728，对 Flume 进行了里程碑式的改动：重构核心组件、核心配置以及代码架构，重构后的版本统称为 Flume NG（next generation）；改动的另一原因是将 Flume 纳入 apache 旗下，cloudera Flume 改名为 Apache Flume。   flume的特点： 　　flume是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统。支持在日志系统中定制各类数据发送方，用于收集数据;同时，Flume提供对数据进行简单处理，并写到各种数据接受方(比如文本、HDFS、Hbase等)的能力 。 　　flume的数据流由事件(Event)贯穿始终。事件是Flume的基本数据单位，它携带日志数据(字节数组形式)并且携带有头信息，这些Event由Agent外部的Source生成，当Source捕获事件后会进行特定的格式化，然后Source会把事件推入(单个或多个)Channel中。你可以把Channel看作是一个缓冲区，它将保存事件直到Sink处理完该事件。Sink负责持久化日志或者把事件推向另一个Source。   flume的可靠性  　　当节点出现故障时，日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障，从强到弱依次分别为：end-to-end（收到数据agent首先将event写到磁盘上，当数据传送成功后，再删除；如果数据发送失败，可以重新发送。），Store on failure（这也是scribe采用的策略，当数据接收方crash时，将数据写到本地，待恢复后，继续发送），Besteffort（数据发送到接收方后，不会进行确认）。   flume的可恢复性： 　　还是靠Channel。推荐使用FileChannel，事件持久化在本地文件系统里(性能较差)。    　　flume的一些核心概念： Agent使用JVM 运行Flume。每台机器运行一个agent，但是可以在一个agent中包含多个sources和sinks。 Client生产数据，运行在一个独立的线程。 Source从Client收集数据，传递给Channel。 Sink从Channel收集数据，运行在一个独立线程。 Channel连接 sources 和 sinks ，这个有点像一个队列。 Events可以是日志记录、 avro 对象等。   　　Flume以agent为最小的独立运行单位。一个agent就是一个JVM。单agent由Source、Sink和Channel三大组件构成，如下图：

　　值得注意的是，Flume提供了大量内置的Source、Channel和Sink类型。不同类型的Source,Channel和Sink可以自由组合。组合方式基于用户设置的配置文件，非常灵活。比如：Channel可以把事件暂存在内存里，也可以持久化到本地硬盘上。Sink可以把日志写入HDFS, HBase，甚至是另外一个Source等等。Flume支持用户建立多级流，也就是说，多个agent可以协同工作，并且支持Fan-in、Fan-out、Contextual Routing、Backup Routes，这也正是NB之处。如下图所示:

　　二、flume的官方网站在哪里？ 　　http://flume.apache.org/

　　三、在哪里下载？

　　http://www.apache.org/dyn/closer.cgi/flume/1.5.0/apache-flume-1.5.0-bin.tar.gz

　　四、如何安装？ 　　　　1)将下载的flume包，解压到/home/hadoop目录中，你就已经完成了50%：）简单吧

　　　　2)修改 flume-env.sh 配置文件,主要是JAVA_HOME变量设置

　　　　3)验证是否安装成功

　　　　出现上面的信息，表示安装成功了     　　五、flume的案例 　　　　1)案例1：Avro 　　　　Avro可以发送一个给定的文件给Flume，Avro 源使用AVRO RPC机制。 　　　　　　a)创建agent配置文件

　　　　　　b)启动flume agent a1

　　　　　　c)创建指定文件

　　　　　　d)使用avro-client发送文件

　　　　　　f)在m1的控制台，可以看到以下信息，注意最后一行：

　　　　2)案例2：Spool 　　　　Spool监测配置的目录下新增的文件，并将文件中的数据读取出来。需要注意两点： 　　　　1) 拷贝到spool目录下的文件不可以再打开编辑。 　　　　2) spool目录下不可包含相应的子目录 　　　　　　a)创建agent配置文件

　　　　　　b)启动flume agent a1

　　　　　　c)追加文件到/home/hadoop/flume-1.5.0-bin/logs目录

　　　　　　d)在m1的控制台，可以看到以下相关信息：

　　　　3)案例3：Exec 　　　　EXEC执行一个给定的命令获得输出的源,如果要使用tail命令，必选使得file足够大才能看到输出内容 　　　　　　a)创建agent配置文件

　　　　　　b)启动flume agent a1

　　　　　　c)生成足够多的内容在文件里

　　　　　　e)在m1的控制台，可以看到以下信息：

　　　　4)案例4：Syslogtcp 　　　　Syslogtcp监听TCP的端口做为数据源 　　　　　　a)创建agent配置文件

　　　　　　b)启动flume agent a1

　　　　　　c)测试产生syslog

　　　　　　d)在m1的控制台，可以看到以下信息：

　　　　5)案例5：JSONHandler 　　　　　　a)创建agent配置文件

　　　　　　b)启动flume agent a1

　　　　　　c)生成JSON 格式的POST request

　　　　　　d)在m1的控制台，可以看到以下信息： /

　　　　6)案例6：Hadoop sink 　　　　其中关于hadoop2.2.0部分的安装部署，请参考文章《ubuntu12.04+hadoop2.2.0+zookeeper3.4.5+hbase0.96.2+hive0.13.1分布式环境部署》 　　　　　　a)创建agent配置文件

　　　　　　b)启动flume agent a1

　　　　　　c)测试产生syslog

　　　　　　d)在m1的控制台，可以看到以下信息：

　　　　　　e)在m1上再打开一个窗口，去hadoop上检查文件是否生成

　　　　7)案例7：File Roll Sink 　　　　　　a)创建agent配置文件

　　　　　　b)启动flume agent a1

　　　　　　c)测试产生log

　　　　　　d)查看/home/hadoop/flume-1.5.0-bin/logs下是否生成文件,默认每30秒生成一个新文件

　　　　8)案例8：Replicating Channel Selector 　　　　Flume支持Fan out流从一个源到多个通道。有两种模式的Fan out，分别是复制和复用。在复制的情况下，流的事件被发送到所有的配置通道。在复用的情况下，事件被发送到可用的渠道中的一个子集。Fan out流需要指定源和Fan out通道的规则。 　　　　这次我们需要用到m1,m2两台机器 　　　　　　a)在m1创建replicating_Channel_Selector配置文件

　　　　　　b)在m1创建replicating_Channel_Selector_avro配置文件

　　　　　　c)在m1上将2个配置文件复制到m2上一份

　　　　　　d)打开4个窗口，在m1和m2上同时启动两个flume agent

　　　　　　e)然后在m1或m2的任意一台机器上，测试产生syslog

　　　　　　f)在m1和m2的sink窗口，分别可以看到以下信息,这说明信息得到了同步：

　　　　                  9)案例9：Multiplexing Channel Selector 　　　　　　a)在m1创建Multiplexing_Channel_Selector配置文件

　　　　　　b)在m1创建Multiplexing_Channel_Selector_avro配置文件

　　　　　　c)将2个配置文件复制到m2上一份

　　　　　　d)打开4个窗口，在m1和m2上同时启动两个flume agent

　　　　　　e)然后在m1或m2的任意一台机器上，测试产生syslog

　　　　　　f)在m1的sink窗口，可以看到以下信息：

　　　　　　g)在m2的sink窗口，可以看到以下信息：

　　　　可以看到，根据header中不同的条件分布到不同的channel上   　　　　10)案例10：Flume Sink Processors 　　　　failover的机器是一直发送给其中一个sink，当这个sink不可用的时候，自动发送到下一个sink。   　　　　　　a)在m1创建Flume_Sink_Processors配置文件

　　　　　　b)在m1创建Flume_Sink_Processors_avro配置文件

　　　　　　c)将2个配置文件复制到m2上一份

　　　　　　d)打开4个窗口，在m1和m2上同时启动两个flume agent

　　　　　　e)然后在m1或m2的任意一台机器上，测试产生log

　　　　　　f)因为m2的优先级高，所以在m2的sink窗口，可以看到以下信息，而m1没有：

　　　　　　g)这时我们停止掉m2机器上的sink(ctrl+c)，再次输出测试数据：

　　　　　　h)可以在m1的sink窗口，看到读取到了刚才发送的两条测试数据：

　　　　　　i)我们再在m2的sink窗口中，启动sink：

　　　　　　j)输入两批测试数据：

　　　　　k)在m2的sink窗口，我们可以看到以下信息，因为优先级的关系，log消息会再次落到m2上：

  　　　　11)案例11：Load balancing Sink Processor 　　　　load balance type和failover不同的地方是，load balance有两个配置，一个是轮询，一个是随机。两种情况下如果被选择的sink不可用，就会自动尝试发送到下一个可用的sink上面。   　　　　　　a)在m1创建Load_balancing_Sink_Processors配置文件

　　　　　　b)在m1创建Load_balancing_Sink_Processors_avro配置文件

　　　　　　c)将2个配置文件复制到m2上一份

　　　　　　d)打开4个窗口，在m1和m2上同时启动两个flume agent

　　　　　　e)然后在m1或m2的任意一台机器上，测试产生log，一行一行输入，输入太快，容易落到一台机器上

　　　　　　f)在m1的sink窗口，可以看到以下信息：

　　　　　　g)在m2的sink窗口，可以看到以下信息：

　　　　说明轮询模式起到了作用。   　　　　12)案例12：Hbase sink   　　　　　　a)在测试之前，请先参考《ubuntu12.04+hadoop2.2.0+zookeeper3.4.5+hbase0.96.2+hive0.13.1分布式环境部署》将hbase启动   　　　　　　b)然后将以下文件复制到flume中：

　　　　　　c)确保test_idoall_org表在hbase中已经存在，test_idoall_org表的格式以及字段请参考《ubuntu12.04+hadoop2.2.0+zookeeper3.4.5+hbase0.96.2+hive0.13.1分布式环境部署》中关于hbase部分的建表代码。   　　　　　　d)在m1创建hbase_simple配置文件

　　　　　　e)启动flume agent

　　　　　　f)测试产生syslog

　　　　　　g)这时登录到hbase中，可以发现新数据已经插入

　　　　经过这么多flume的例子测试，如果你全部做完后，会发现flume的功能真的很强大，可以进行各种搭配来完成你想要的工作，俗话说师傅领进门，修行在个人，如何能够结合你的产品业务，将flume更好的应用起来，快去动手实践吧