Flume学习3_Flume NG：Flume 发展史上的第一次革命

Flume 作为 cloudera 开发的实时日志收集系统，已经受到越来越多的关注。比如 IBM BigInsights 已经将 Flume 作为产品的一部分。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 OG 到 Flume NG 发生的革命性变化。

背景

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 架构图

图 2. OG 节点组成图

对应于 OG 的特点，FLUM NG 的特点是：

• NG 只有一种角色的节点：代理节点（agent）。
• 没有 collector、master 节点。这是核心组件最核心的变化。
• 去除了 physical nodes、logical nodes 的概念和相关内容。
• agent 节点的组成也发生了变化。如图 4，NG agent 由 source、sink、channel 组成。

图 3. FLUM NG 架构图

图 4. NG 节点组成图

从整体上讲，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

实战 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

表 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

图 8. hdfs

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 配置

图 10. OG console

结束语

本文通过对比，从核心组件和用户的角度，阐述了 Flume NG 给 Flume 

带来的第一次革命。从核心组件来讲，NG 简化核心组件，

移除了 OG 版本代码工程臃肿、核心组件设计不合理、核心配置不标准

等缺点；另外 NG 脱离了 Flume 稳定性对 zookeeper 的

依赖。从用户角度来讲，NG 版本对用户要求大大降低：安装过程除了

 java 无需配置复杂的 Flume 相关属性，也无需搭建

 zookeeper 集群，安装过程几乎零工作量；数据流的配置过程

更加简单、合理，只需要实现 source、sink、channel 的简单配置即可。