内容


Flume NG:Flume 发展史上的第一次革命

Comments

背景

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 架构图
FLUM OG 架构图
图 2. OG 节点组成图
OG 节点组成图
OG 节点组成图

对应于 OG 的特点,FLUM NG 的特点是:

  • NG 只有一种角色的节点:代理节点(agent)。
  • 没有 collector、master 节点。这是核心组件最核心的变化。
  • 去除了 physical nodes、logical nodes 的概念和相关内容。
  • agent 节点的组成也发生了变化。如图 4,NG agent 由 source、sink、channel 组成。
图 3. FLUM NG 架构图
FLUM NG 架构图
FLUM NG 架构图
图 4. NG 节点组成图
NG 节点组成图
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
example.conf
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
example.conf
example.conf
表 1. flume-conf.xml
Properties NameDescription
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
NG console
图 8. hdfs
hdfs
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.servershost2
flume.master.storezookeeper
flume.master.serverid0
flume.master.zk.use.externaltrue
flume.master.zk.servershost2:2181
图 9. OG 配置
OG 配置
OG 配置
图 10. OG console
OG console
OG console

结束语

本文通过对比,从核心组件和用户的角度,阐述了 Flume NG 给 Flume 带来的第一次革命。从核心组件来讲,NG 简化核心组件,移除了 OG 版本代码工程臃肿、核心组件设计不合理、核心配置不标准等缺点;另外 NG 脱离了 Flume 稳定性对 zookeeper 的依赖。从用户角度来讲,NG 版本对用户要求大大降低:安装过程除了 java 无需配置复杂的 Flume 相关属性,也无需搭建 zookeeper 集群,安装过程几乎零工作量;数据流的配置过程更加简单、合理,只需要实现 source、sink、channel 的简单配置即可。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=967894
ArticleTitle=Flume NG:Flume 发展史上的第一次革命
publish-date=04082014