Cloudera 开发的分布式日志收集系统 Flume,可以实时的将分布在不同节点、机器上的日志收集到 存储系统中。
Flume 初始的发行版本统称为 Flume OG(original generation),属于 cloudera。
但随着 Flume 功能的扩展,Flume OG 代码工程臃肿、核心组件设计不合理、核心配置不标准等缺点暴露出来,尤其 Flume OG 的最后一个发行版本 0.94.0 中,日志传输不稳定
的现象尤为严重。
为了解决这些问题,cloudera 对Flume 进行了里程碑式的改动:重构核心组件、核心配置以及代码架构,重构后的版本统称为 Flume NG(next generation);
改动的另一原因是将 Flume 纳入 Apache 旗下,cloudera Flume 改名为 Apache Flume。
从核心组件变化、角色变化、用户配置变化等方面阐述 Flume NG 相对于 Flume OG 所发生的革命性变化。
1、核心组件变化
Flume og 架构图
Flume og 的特点是:
Flume og 有三种角色的节点:代理节点(agent)、收集节点(collector)、主节点(master)。
agent 从各个数据源收集日志数据,将收集到的数据集中到 collector,然后由收集节点汇总存入 hdfs。master 负责管理 agent,collector 的活动。
agent、collector 都称为 node,node 的角色根据配置的不同分为 logical node(逻辑节点)、physical node(物理节点)。
agent、collector 由 source、sink 组成,代表在节点上数据是从 source 传送到 sink。
Flume og 节点组成图:
Flume ng 架构图
Flume ng 的特点是:
只有一种角色的节点:代理节点(agent)。
没有 collector、master 节点。这是核心组件最核心的变化。
去除了 physical node、logical nodes的概念和相关内容。
agent 节点的组成也发生了变化。agent 由 source、sink、channel 组成。
Flume ng 节点组成图:
大大的降低了对用户的要求,如核心组件的变化使得 Flume 的稳定不再依赖 zookeeper,用户无需去搭建 zookeeper 集群;
另外用户也不用纠结于 OG 中的模糊概念(尤其是 physical node、logical node,agent、collector)。
删减节点角色,脱离 zookeeper。
在 NG 版本中,节点角色的数量由 3 缩减到 1,不存在多类角色的问题,所以就不再需要 zookeeper 对各类节点协调的作用了,由此脱离了对 zookeeper 的依赖。
2、用户配置变化
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。
Flume 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 的配置。
实战 Flume
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。本次用的是 apache-flume-1.2.0-bin.tar.gz
生成配置文件 example.conf。
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 收集到的数据存放的文件以此为前缀。
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。
进入 bin 目录,命令启动 Flume。
./flume-ng agent --conf-file ../example.conf --name agent_ff -Dflume.root.logger=INFO,cnsole
控制台信息:
hdfs信息:
使用 og 搭建日志传输场景:flume+zookeeper+hadoop
下载 zookeeper 安装包,并在 host2 上安装 zookeeper-3.4.3。
下载 flume-0.94.0,并解压在 host2 上。
配置文件 conf/flume-conf.xml
flume.master.servers host2
flume.master.store zookeeper
flume.master.serverid 0
flume.master.zk.use.external true
flume.master.zk.servers host2:2181
进入 bin 目录,使用一下命令启动 flume master、agent。
master: ./flume-daemon.sh start master
agent: ./flume node -n agent-ff
进入 master 页面:http://host2:35871/flumemaster.jsp。配置 source、sink。
控制台: