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。
控制台：
