分享

什么是 flume 日志收集,flume的原理是什么,flume会遇到什么问题

可以带着下面问题阅读本文章:
1.Flume为什么能够收集日志
2.如何定义Flume
3.Flume安装应该注意什么问题
一、Flume介绍
Flume是一个分布式、可靠、和高可用的海量日志聚合的系统,支持在系统中定制各类数据发送方,用于收集数据;同时,Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。
  1. flume可以搜集数据,合并数据。合并到什么地方,可以是hdfs。也就是flume可以与hadoop相结合
复制代码
设计目标:
(1) 可靠性

当节点出现故障时,日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障,从强到弱依次分别为:end-to-end(收到数据agent首先将event写到磁盘上,当数据传送成功后,再删除;如果数据发送失败,可以重新发送。),Store on failure(这也是scribe采用的策略,当数据接收方crash时,将数据写到本地,待恢复后,继续发送),Best effort(数据发送到接收方后,不会进行确认)。

(2) 可扩展性

采用了三层架构,分别为agent,collector和storage,每一层均可以水平扩展。其中,所有agent和collector由master统一管理,这使得系统容易监控和维护,且master允许有多个(使用ZooKeeper进行管理和负载均衡),这就避免了单点故障问题。

(3) 可管理性

所有agent和colletor由master统一管理,这使得系统便于维护。多master情况,Flume利用ZooKeeper和gossip,保证动态配置数据的一致性。用户可以在master上查看各个数据源或者数据流执行情况,且可以对各个数据源配置和动态加载。Flume提供了web 和shell script command两种形式对数据流进行管理。

(4) 功能可扩展性

用户可以根据需要添加自己的agent,collector或者storage。此外,Flume自带了很多组件,包括各种agent(file, syslog等),collector和storage(file,HDFS等)。
  1. Flume的四个特性:需要明白功能可扩展与三层可扩展,Flume多个master怎么管理的
复制代码
二、Flume架构
flume的逻辑架构:

2012052509592437.jpg

正如前面提到的,Flume采用了分层架构:分别为agent,collector和storage。其中,agent和collector均由两部分组成:source和sink,source是数据来源,sink是数据去向。

Flume使用两个组件:Master和Node,Node根据在Master shell或web中动态配置,决定其是作为Agent还是Collector。

(1) agent
agent的作用是将数据源的数据发送给collector。

Flume自带了很多直接可用的数据源(source),如:

text(“filename”):将文件filename作为数据源,按行发送
tail(“filename”):探测filename新产生的数据,按行发送出去
fsyslogTcp(5140):监听TCP的5140端口,并且接收到的数据发送出去
tailDir("dirname"[, fileregex=".*"[, startFromEnd=false[, recurseDepth=0]]]):监听目录中的文件末尾,使用正则去选定需要监听的文件(不包含目录),recurseDepth为递归监听其下子目录的深度
更多可参见这位朋友的整理:http://www.cnblogs.com/zhangmiao ... /05/18/2050465.html

同时提供了很多sink,如:

console[("format")] :直接将将数据显示在consolr上
text(“txtfile”):将数据写到文件txtfile中
dfs(“dfsfile”):将数据写到HDFS上的dfsfile文件中
syslogTcp(“host”,port):将数据通过TCP传递给host节点
agentSink[("machine"[,port])]:等价于agentE2ESink,如果省略,machine参数,默认使用flume.collector.event.host与flume.collector.event.port作为默认collecotr
agentDFOSink[("machine" [,port])]:本地热备agent,agent发现collector节点故障后,不断检查collector的存活状态以便重新发送event,在此间产生的数据将缓存到本地磁盘中
agentBESink[("machine"[,port])]:不负责的agent,如果collector故障,将不做任何处理,它发送的数据也将被直接丢弃
agentE2EChain:指定多个collector提高可用性。 当向主collector发送event失效后,转向第二个collector发送,当所有的collector失败后,它会非常执着的再来一遍
更多可参见这位朋友的整理:http://www.cnblogs.com/zhangmiao ... /05/18/2050472.html
  1. $wget http://cloud.github.com/downloads/cloudera/flume/flume-distribution-0.9.4-bin.tar.gz
  2. $tar -xzvf flume-distribution-0.9.4-bin.tar.gz
  3. $cp -rf flume-distribution-0.9.4-bin /usr/local/flume
  4. $vi /etc/profile  #添加环境配置
  5.     export FLUME_HOME=/usr/local/flume
  6.     export PATH=.:$PATH::$FLUME_HOME/bin
  7. $source /etc/profile
  8. $flume #验证安装
复制代码
(2) collector
collector的作用是将多个agent的数据汇总后,加载到storage中。

它的source和sink与agent类似。

数据源(source),如:

collectorSource[(port)]:Collector source,监听端口汇聚数据
autoCollectorSource:通过master协调物理节点自动汇聚数据
logicalSource:逻辑source,由master分配端口并监听rpcSink
sink,如:

collectorSink( "fsdir","fsfileprefix",rollmillis):collectorSink,数据通过collector汇聚之后发送到hdfs, fsdir 是hdfs目录,fsfileprefix为文件前缀码
customdfs("hdfspath"[, "format"]):自定义格式dfs
(3) storage
storage是存储系统,可以是一个普通file,也可以是HDFS,HIVE,HBase,分布式存储等。

(4) Master
Master是管理协调agent和collector的配置等信息,是flume集群的控制器。



在Flume中,最重要的抽象是data flow(数据流),data flow描述了数据从产生,传输、处理并最终写入目标的一条路径。


2.jpg



对于agent数据流配置就是从哪得到数据,把数据发送到哪个collector。
对于collector是接收agent发过来的数据,把数据发送到指定的目标机器上。
注:Flume框架对hadoop和zookeeper的依赖只是在jar包上,并不要求flume启动时必须将hadoop和zookeeper服务也启动。



三、Flume分布式环境部署
1.实验场景
操作系统版本:RedHat 5.6
Hadoop版本:0.20.2
Jdk版本:jdk1.6.0_26
安装flume版本:flume-distribution-0.9.4-bin
部署flume在集群上,按照如下步骤:

在集群上的每台机器上安装flume
选择一个或多个节点当做master
修改静态配置文件
在至少一台机器上启动一个master ,所有节点启动flume node
动态配置
需要在集群的每台机器上部署Flume。

注意:flume集群整个集群的网络环境要保证稳定,可靠,否则会出现一些莫名错误(比如:agent端发送不了数据到collector)。

1.Flume环境安装
  1. $wget http://cloud.github.com/downloads/cloudera/flume/flume-distribution-0.9.4-bin.tar.gz
  2. $tar -xzvf flume-distribution-0.9.4-bin.tar.gz
  3. $cp -rf flume-distribution-0.9.4-bin /usr/local/flume
  4. $vi /etc/profile  #添加环境配置
  5.     export FLUME_HOME=/usr/local/flume
  6.     export PATH=.:$PATH::$FLUME_HOME/bin
  7. $source /etc/profile
  8. $flume #验证安装
复制代码
2.选择一个或多个节点当做master
对于master的选择情况,可以在集群上定义一个master,也可以为了提高可用性选择多个节点做为master。

单点master模式:容易管理,但在系统的容错和扩展性有缺陷
多点master模式:通常是运行3/5个master,能很好的容错
Flume master数量的选择原则:

      分布式的master能够继续正常工作不会崩溃的前提是正常工作的master数量超过总master数量的一半。

Flume master 的作用主要有两个:

跟踪各节点的配置情况,通知节点配置的改变;
跟踪来自flow的结尾操控在可靠模式下(E2E)的信息,以至于让flow的源头知道什么时候停止传输event。

3.修改静态配置文件
site-specific设置对于flume节点和master通过在每一个集群节点的conf/flume-site.xml是可配置的,如果这个文件不存在,设置的属性默认的在conf/flume--conf.xml中,在接下来的例子中,在flume的节点上设置master名,让节点自己去寻找叫“master”的flume Master。
  1. <?xml version="1.0"?>
  2.     <?xml-stylesheet type="text/xsl"  href="configuration.xsl"?>
  3.     <configuration>
  4.         <property>
  5.             <name>flume.master.servers</name>
  6.             <value>master</value>
  7.          </property>
  8.     </configuration>
复制代码
在多master的情况下需要如下配置:
  1. <property>
  2.     <name>flume.master.servers</name>
  3.    <value>hadoopmaster.com,hadoopedge.com,datanode4.com</value>
  4.     <description>A comma-separated list of hostnames, one for each machine in the Flume Master.</description>
  5. </property>
  6. <property>
  7.     <name>flume.master.store</name>
  8.     <value>zookeeper</value>
  9.     <description>How the Flume Master stores node configurations. Must be either 'zookeeper' or 'memory'.</description>
  10. </property>
  11. <property>
  12.     <name>flume.master.serverid</name>
  13.     <value>2</value>
  14.     <description>The unique identifier for a machine in a Flume Master ensemble. Must be different on every master instance.</description>
  15. </property>
复制代码
注意:flume.master.serverid 属性的配置主要是针对master,集群上Master节点的flume.master.serverid 必须是不能相同的,该属性的值以0开始。

当使用agent角色时,你可以通过添加下面的配置文件在flume-conf.xml中,来设置默认的collector主机:
  1. property>
  2.     <name>flume.collector.event.host</name>
  3.     <value>collector</value>
  4.     <description>This is the host name of the default "remote"  collector.</description>
  5. </property>
  6. <property>
  7.     <name>flume.collector.port</name>
  8.     <value>35853</value>
  9.     <description>This default tcp port that the collector listens to in order to receive events it is collecting.</description>
  10. </property>
复制代码
4.启动集群
集群上节点启动:

在命令行输入:flume master 启动master节点
在命令行输入:flume node –n nodeName 启动其他节点,nodeName最好根据集群逻辑的划分来取名子,这样在 master进行配置的时候比较清晰。
名字规则自己定义,方便记忆和动态配置即可(后续会有介绍动态配置)



5.基于flume shell的动态配置
关于flume shell 中的command参见:http://www.cnblogs.com/zhangmiao ... /05/18/2050461.html

假设我们目前部署的Flume集群结构如下:

4.jpg


我们想将A-F所在的机器的系统日志收集到HDFS中,怎么样在flume shell中配置达到我们的目的呢?

1. 设置逻辑节点(logical node)
  1. $flume shell
  2. >connect localhost
  3. >help
  4. >exec map 192.168.0.1 agentA
  5. >exec map 192.168.0.2 agentB
  6. >exec map 192.168.0.3 agentC
  7. >exec map 192.168.0.4 agentD
  8. >exec map 192.168.0.5 agentE
  9. >exec map 192.168.0.6 agentF
  10. >getnodestatus
  11.         192.168.0.1 --> IDLE
  12.         192.168.0.2 --> IDLE
  13.         192.168.0.3 --> IDLE
  14.         192.168.0.4 --> IDLE
  15.         192.168.0.5 --> IDLE
  16.         192.168.0.6 --> IDLE
  17.         agentA --> IDLE
  18.         agentB --> IDLE
  19.         agentC --> IDLE
  20.         agentD --> IDLE
  21.         agentE --> IDLE
  22.         agentF --> IDLE
  23. >exec map 192.168.0.11 collector
复制代码
这里你也可以打开web master界面查看。

2.启动Collector的监听端口
  1. >exec config collector 'collectorSource(35853)' 'collectorSink("","")'#collector节点监听35853端口过来的数据,这一部非常重要
复制代码
登陆到collector服务器进行端口检测
  1. $netstat -nalp|grep 35853
复制代码
如果在master中未进行上述配置,在collector上检测不到此打开端口

3.设置各节点的source和sink
  1. >exec config collector 'collectorSource(35853)' 'collectorSink("hdfs://namenode/flume/","syslog")'
  2. >exec config agentA 'tail("/tmp/log/message")' 'agentBESink("192.168.0.11")' #经过实验,好像一个逻辑节点,最多只能有一个source和sink.
  3. >...
  4. >exec config agentF 'tail("/tmp/log/message")' 'agentBESink("192.168.0.11")'
复制代码
这时的配置情况可从master web中一目了然,此时已经可以达到我们最初的目的了。

以上通过flume shell进行的动态配置,在flume master web中都可以进行,在此不做进一步说明。



四、高级动态配置
高级配置其实就是在上述简单配置中增加了以下几个特性来保证系统更好的运行:

多Master(Master节点的高可用)
Collector Chain(Collector的高可用)
多Master的情况在上面已经有过介绍,包括用途和master个数等。下面来简单看一下Collector Chain,其实也很简单,就是在动态配置时,使用agent*Chain来指定多个Collector来保证其日志传输的可用性。看一下一般正式环境中flume的逻辑图:

5.jpg


这里agentA和agentB指向collectorA,如果CollectorA crach了,根据配置的可靠性级别agent会有相应的动作,我们很可能为了保障高效传输而没有选择E2E(即使是这种方式,Agent本地日志累积过多依然是一个问题),一般会配置多个Collector,形成collector chain。
  1. >exec config agentC 'tail("/tmp/log/message")' 'agentE2EChain("collectorB:35853","collectorA:35853")'
  2. >exec config agentD 'tail("/tmp/log/message")' 'agentE2EChain("collectorB:35853","collectorC:35853")'
复制代码
这样collectorB在出问题时:
6.jpg








来自群组: Hadoop技术组

本帖被以下淘专辑推荐:

没找到任何评论,期待你打破沉寂

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

推荐上一条 /2 下一条