背景
Cloudera 开发的分布式日志收集系统 Flume,是 hadoop 周边组件之一。其可以实时的将分布在不同节点、机器上的日志收集到 hdfs 中。Flume 初始的发行版本目前被统称为 Flume OG(original generation),属于 cloudera。但随着 FLume 功能的扩展,Flume OG 代码工程臃肿、核心组件设计不合理、核心配置不标准等缺点暴露出来,尤其是在 Flume OG 的最后一个发行版本 0.94.0 中,日志传输不稳定的现象尤为严重,这点可以在 BigInsights 产品文档的 troubleshooting 板块发现。为了解决这些问题,2011 年 10 月 22 号,cloudera 完成了 Flume-728,对 Flume 进行了里程碑式的改动:重构核心组件、核心配置以及代码架构,重构后的版本统称为 Flume NG(next generation);改动的另一原因是将 Flume 纳入 apache 旗下,cloudera Flume 改名为 Apache Flume。
下面将从核心组件变化、角色变化、用户配置变化以及实战等方面阐述 Flume NG 相对于 Flume OG 所发生的革命性变化。
核心组件变化
图 1 和图 3 是两个版本的架构图。
FLUM OG 的特点是:
- FLUM OG 有三种角色的节点,如图 1:代理节点(agent)、收集节点(collector)、主节点(master)。
- agent 从各个数据源收集日志数据,将收集到的数据集中到 collector,然后由收集节点汇总存入 hdfs。master 负责管理 agent,collector 的活动。
- agent、collector 都称为 node,node 的角色根据配置的不同分为 logical node(逻辑节点)、physical node(物理节点)。对 logical nodes 和 physical nodes 的区分、配置、使用一直以来都是使用者最头疼的地方。
- agent、collector 由 source、sink 组成,代表在当前节点数据是从 source 传送到 sink。如图 2。
图 1. FLUM OG 架构图
![FLUM OG 架构图](https://i-blog.csdnimg.cn/blog_migrate/0dba066b2515df4ef9e3a0a7e863f22b.png)
图 2. OG 节点组成图
![OG 节点组成图](https://i-blog.csdnimg.cn/blog_migrate/7701ac3c555851e2ec93a47b8c8cbb4d.png)
对应于 OG 的特点,FLUM NG 的特点是:
- NG 只有一种角色的节点:代理节点(agent)。
- 没有 collector、master 节点。这是核心组件最核心的变化。
- 去除了 physical nodes、logical nodes 的概念和相关内容。
- agent 节点的组成也发生了变化。如图 4,NG agent 由 source、sink、channel 组成。
图 3. FLUM NG 架构图
![FLUM NG 架构图](https://i-blog.csdnimg.cn/blog_migrate/4762f9148ccee743352ee117792bc805.png)
图 4. NG 节点组成图
![NG 节点组成图](https://i-blog.csdnimg.cn/blog_migrate/7d2d3200062e4fd598b83b702b637400.png)
从整体上讲,NG 在核心组件上进行了大规模的调整,核心组件的数目由 7 删减到 4。由于 Flume 的使用涉及到众多因素,如 avro、thrift、hdfs、jdbc、zookeeper 等,而这些组件和 Flume 的整合都需要关联到所有组件。所以核心组件的改革对整个 Flume 的使用影响深远:
- 大大降低了对用户的要求,如核心组件的变化使得 Flume 的稳定使用不再依赖 zookeeper,用户无需去搭建 zookeeper 集群;另外用户也不再纠结于 OG 中的模糊概念(尤其是 physical nodes、logical nodes,agent、collector)。
- 有利于 Flume 和其他技术、hadoop 周边组件的整合,比如在 NG 版本中,Flume 轻松实现了和 jdbc、hbase 的集成。
- 将 OG 版本中复杂、大规模、不稳定的标签移除,Flume 实现了向灵活、轻便的转变,而且在功能上更加强大、可扩展性更高,这一点主要表现在用户使用 Flume 搭建日志收集集群的过程中,后面的章节会详细介绍。
删减节点角色,脱离 zookeeper
Zookeeper 是针对大型分布式系统的可靠协调系统,适用于有多类角色集群管理。比如在 hbase 中,对 HMaster、HRegionServer 的管理。
在 OG 版本中,Flume 的使用稳定性依赖 zookeeper。它需要 zookeeper 对其多类节点(agent、collector、master)的工作进行管理,尤其是在集群中配置多个 master 的情况下。当然,OG 也可以用内存的方式管理各类节点的配置信息,但是需要用户能够忍受在机器出现故障时配置信息出现丢失。所以说 OG 的稳定行使用是依赖 zookeeper 的。
而在 NG 版本中,节点角色的数量由 3 缩减到 1,不存在多类角色的问题,所以就不再需要 zookeeper 对各类节点协调的作用了,由此脱离了对 zookeeper 的依赖。由于 OG 的稳定使用对 zookeeper 的依赖表现在整个配置和使用过程中,这就要求用户掌握对 zookeeper 集群的搭建极其使用(尤其是要熟悉 zookeeper 数据文件夹 data,Flume 节点配置信息存放在此文件夹中);掌握 Flume 中和 zookeeper 相关的配置。对初次接触 Flume 的用户来讲,这是非常痛苦的事。
用户配置变化
从用户角度来讲,配置过程无疑是整个集群搭建的核心步骤。Flume 的配置分为两个部分:安装和数据传输配置。
安装
OG 在安装时:
- 在 flume-env.sh 中设置$JAVA_HOME。
- 需要配置文件 flume-conf.xml。其中最主要的、必须的配置与 master 有关。集群中的每个 Flume 都需要配置 master 相关属性(如 flume.master.servers、flume.master.store、flume.master.serverid)。
- 如果想稳定使用 Flume 集群,还需要安装 zookeeper 集群,这需要用户对 zookeeper 有较深入的了解。
- 安装 zookeeper 之后,需要配置 flume-conf.xml 中的相关属性,如 flume.master.zk.use.external、flume.master.zk.servers。
- 在使用 OG 版本传输数据之前,需要启动 master、agent。
NG 在安装时,只需要在 flume-env.sh 中设置$JAVA_HOME。
数据传输配置
OG 版本的配置途径有两个:
- shell 命令:需要用户掌握 Flume shell 命令;
- master console 页面:这是 OG 用户最常用的配置方式;弊端在于,除非用户熟悉复杂的各类 source,sink 配置函数以及格式(source:大约 25 个,sink:大约 46 个),否则在复杂的集群环境下,用户每次只能配置一个节点(指定 source、sink)来保证配置的准确性;
NG 的配置只需要一个配置文件,这个配置文件中存放 source、sink、channel 的配置。如图 5 中是配置文件 example.conf 里面的内容,其中 agent_foo 是 agent 名字。然后在启动 agent 时,使用一下命令指定这个配置文件:
$ bin/flume-ng agent --conf-file example.conf \ --name agent_foo \ -Dflume.root.logger=INFO,console
图 5. example.conf
![example.conf](https://i-blog.csdnimg.cn/blog_migrate/842055d2d1a7c67e1fb95077c202eab4.png)
实战 Flume NG
Flume 最常用的使用场景是,从节点收集日志数据,并以一定的格式存放到分布式文件系统 hdfs(hadoop 文件系统)中。下面介绍如何使用 Flume NG 从一个节点收集实时日志,并存放到 hdfs 中。
场景说明:
- 场景中有两台主机 host1、host2。
- 数据源是 host2 上的系统日志文件“/var/log/secure”(登录到系统存取资料的记录,本机的测试系统有多人使用,所以记录在不断的生成)。数据目的地是 hadoop 文件系统 hdfs。
- 在 host1、host2 上搭建 hadoop 集群。其中 host1 为 namenode、jobtracker,host2 为 datanode、tasktracker。
使用 ng 搭建日志传输场景:flume+hadoop
场景搭建步骤:
- 下载 flume-ng 安装包,并解压到 host2。
Flume 发布了两类包:source 和 bin。Source 包用于开发工作,bin 包用于安装 Flume 搭建日志收集场景。本次实验用的是 apache-flume-1.2.0-bin.tar.gz
- 生成配置文件 example.conf。内容如图 6。整个配置分为四部分。表 1 是配置说明。
- 进入 bin 目录,使用一下命令启动 Flume,开始日志收集,控制台输出如图 7,传输到 hdfs 的文件如图 8。
./flume-ng agent \ --conf-file ../example.conf \ --name agent_ff \ -Dflume.root.logger=INFO,cnsole
图 6. example.conf
![example.conf](https://i-blog.csdnimg.cn/blog_migrate/69200c0d99dbc0bcf79cb495d1f6e21f.png)
表 1. flume-conf.xml
Properties Name | Description |
---|---|
agent_ff | 用来收集日志信息的 agent 节点名称 |
agent_ff.source | 需要收集的信息源,名字:tailsource-ff |
agent_ff.sinks | 日志需要被收集到此处,名字:hdfsSink-ff。 |
agent_ff.channels | 日志的收集需要通过此管道,名字:memoryChannel-ff。 |
tailsource-ff.type | 定义 source 的类型,此处 exec 代表数据源是 exec 命令 |
tailsource-ff.command | 定义具体命令,此处是对文件/var/log/secure 做 tail |
tailsource-ff.channels | 数据传输的管道,此处的管道名称应该和 sink 相同。从而将 source、sink 通过 channels 进行连接。 |
memoryChannel-ff.type | 管道类型,代表事件存储的方式。Source 产生事件,sink 移除事件,以此代表数据传输完成。目前 Flume 支持 6 种 channel。此处是 momery,代表事件是存在内存里 |
memoryChannel-ff.capacity | 管道里可以存放的最多的事件数目。此处代表 memoryChannel-ff 最多可存放 1000 个事件。 |
hdfsSink-ff.type | 数据目的地的类型,此处是将数据存放在 hdfs 中。 |
hdfsSink-ff.channel | 定义和 source 相关联的管道。 |
hdfsSink-ff.hdfs.path | 数据存放在 hdfs 中的位置。 |
hdfsSink-ff.hdfs.filePrefix | 收集到的数据存放的文件以此为前缀。如图 8。 |
hdfsSink-ff.hdfs.round, hdfsSink-ff.hdfs.roundValue, hdfsSink-ff.hdfs.roundUnit | 定义在 hdfs 中生成的文件的时间戳。此处代表将 hdfs 中的文件的时间戳,向下取整到上一个十分钟内。比如说,在 2012 年 6 月 12 号上午 11:54:34 生成的事件,在 hdfs 中生成的路径将是/flume/events/2012-06-12/1150/00。 |
图 7. NG console
![NG console](https://i-blog.csdnimg.cn/blog_migrate/4bbedaf13f6640042e8edf726aab2c9c.png)
图 8. hdfs
![hdfs](https://i-blog.csdnimg.cn/blog_migrate/4314f213b36279a7982b8d9ae2cef679.png)
Flume OG vs Flume NG:用户体验对比
整体上看,NG 的用户体验要比 OG 好得多,这一点从用户文档上就可见一斑。OG 版本的使用文档有 90 多页,而 OG 只用 20 多页的内容就完成了新版 Flume 的使用说明。对应于上一节“实战 Flume NG”,我们使用和 NG 中同样的场景说明,下面介绍如何使用 OG 搭建同样的日志收集场景。用户可以从场景的搭建上明显的看出差别:NG 的整个过程只涉及到 hadoop、agent,而 OG 则需要涉及到 hadoop、zookeeper、master、agent、flume-conf.xml。
使用 og 搭建日志传输场景:flume+zookeeper+hadoop
场景搭建步骤:
- 下载 zookeeper 安装包,并在 host2 上安装 zookeeper-3.4.3。请参考:zookeeperStarted。
- 下载 flume-0.94.0(OG),并解压在 host2 上。
- 配置文件 conf/flume-conf.xml,必须配置的信息如表 2。
- 进入 bin 目录,使用一下命令启动 flume master、agent。
master: ./flume-daemon.sh start master agent: ./flume node -n agent-ff
- 进入 master 页面:http://host2:35871/flumemaster.jsp。配置 source、sink。如图 9。“Submit Query”后 Flume 便开始收集数据。
- agent-ff 控制台输出如图 10。
表 2. flume-conf.xml
属性(Property) | 赋值(Value) |
---|---|
flume.master.servers | host2 |
flume.master.store | zookeeper |
flume.master.serverid | 0 |
flume.master.zk.use.external | true |
flume.master.zk.servers | host2:2181 |
图 9. OG 配置
![OG 配置](https://i-blog.csdnimg.cn/blog_migrate/35840372a11f11b0583713351c3ea750.png)
图 10. OG console
![OG console](https://i-blog.csdnimg.cn/blog_migrate/45e0fef6ca686a859311de0b57601006.png)
结束语
本文通过对比,从核心组件和用户的角度,阐述了 Flume NG 给 Flume 带来的第一次革命。从核心组件来讲,NG 简化核心组件,移除了 OG 版本代码工程臃肿、核心组件设计不合理、核心配置不标准等缺点;另外 NG 脱离了 Flume 稳定性对 zookeeper 的依赖。从用户角度来讲,NG 版本对用户要求大大降低:安装过程除了 java 无需配置复杂的 Flume 相关属性,也无需搭建 zookeeper 集群,安装过程几乎零工作量;数据流的配置过程更加简单、合理,只需要实现 source、sink、channel 的简单配置即可。