flume分布式数据收集

时间  2019-11-08
标签 flume 分布式 数据 收集 栏目 日志分析 繁體版
原文   原文链接

Flume是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统。支持在系统中定制各种数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各类数据接受方（可定制）的能力。Flume 初始的发行版本目前被统称为 Flume OG（original generation），属于 cloudera。但随着 Flume 功能的扩展，Flume OG 代码工程臃肿、核心组件设计不合理、核心配置不标准等缺点暴露出来，尤为是在 Flume OG 的最后一个发行版本 0.94.0 中，日志传输不稳定的现象尤其严重。为了解决这些问题，2011 - 10 - 22 号，cloudera 完成了 Flume-728，对 Flume 进行了里程碑式的改动：重构核心组件、核心配置以及代码架构，重构后的版本统称为 Flume NG（next generation）；改动的另外一缘由是将 Flume 归入 apache 旗下，cloudera Flume 更名为 Apache Flume。IBM 的这篇文章：Flume NG：Flume 发展史上的第一次革命，从基本组件以及用户体验的角度阐述 Flume OG 到 Flume NG 发生的革命性变化。html

1、Flume OGjava

Flume OG的设计目标：node

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

  2. 可扩展性：Flume采用了三层架构，分别为agent，collector和storage，每一层都可以水平扩展。其中，全部agent和collector由master统一管理，这使得系统容易监控和维护，且master容许有多个（使用ZooKeeper进行管理和负载均衡），这就避免了单点故障问题。github

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

  4. 功能可扩展性：用户能够根据须要添加本身的agent，collector或者storage。此外，Flume自带了不少组件，包括各类agent（file，syslog等），collector和storage（file，HDFS等）。shell

Flume OG的架构：数据库

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

  • 对于agent数据流配置就是从哪获得数据，把数据发送到哪一个collector。json

  • 对于collector是接收agent发过来的数据，把数据发送到指定的目标机器上。

Flume框架对hadoop和zookeeper的依赖只是在jar包上，并不要求flume启动时必须将hadoop和zookeeper服务也启动。

如前面提到的，Flume采用了分层架构：分别为Agent，Collector和Storage。Agent用于采集数据，Agent是Flume中产生数据流的地方。同时，Agent会将产生的数据流传输到Collector。Collector用于对数据进行聚合，每每会产生一个更大的流，而后传输到Storage。其中，Agent和Collector均由两部分组成：source和sink，source是数据来源，sink是数据去向。Flume使用两个组件：Master和Node，Node根据在Master shell或web中动态配置，决定其是做为Agent仍是Collector。

一、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-chp/archive/2011/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-chp/archive/2011/05/18/2050472.html

二、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集群的控制器。

2、Flume NG

对于Flume OG ,能够说他是一个分布式日志收集系统，有Mater概念，依赖于Zookeeper，Agent用于采集数据，Agent是Flume中产生数据流的地方，同时，Agent会将产生的数据流传输到Collector。对应的，collector用于对数据进行聚合，每每会产生一个更大的流。而对于Flume NG，它摒弃了Master和zookeeper，collector也没有了，web配置台也没有了，只剩下source，sink和channel，此时一个Agent的概念包括source、channel和sink，彻底由一个分布式系统变成了传输工具。不一样机器之间的数据传输再也不是OG那样由agent->collector，而是由一个Agent端的sink流向另外一个agent的source。

Flume NG中的核心概念：

  • Client：生产数据，运行在一个独立的线程。

  • Source：从Client收集数据，传递给Channel。能够接收外部源发送过来的数据。不一样的 source，能够接受不一样的数据格式。好比有目录池(spooling directory)数据源，能够监控指定文件夹中的新文件变化，若是目录中有文件产生，就会马上读取其内容。

  • Channel：是一个存储地，接收source的输出，直到有sink消费掉channel中的数据。Channel中的数据直到进入到下一个channel中或者进入终端才会被删除。当sink写入失败后，能够自动重启，不会形成数据丢失，所以很可靠。

  • Sink：会消费channel中的数据，而后送给外部源或者其余source。如数据能够写入到HDFS或者HBase中。

  • Agent：使用JVM 运行Flume。每台机器运行一个agent，可是能够在一个agent中包含多个sources和sinks。

  • Events：Flume NG传输的数据的基本单位是event，若是是文本文件，一般是一行记录，这也是事务的基本单位。

Flume NG相对于Flume OG的主要变化：

  • sources和sinks 使用channels 进行连接

  • 两个主要channel：in-memory channel，非持久性支持，速度快； JDBC-based channel 持久性支持。

  • 再也不区分逻辑和物理node，全部物理节点统称为agents,每一个agents 都能运行0个或多个sources 和sinks

  • 再也不须要master节点和对zookeeper的依赖，配置文件简单化。

  • 插件化，一部分面对用户，工具或系统开发人员。

  • 使用Thrift、Avro Flume sources 能够从flume0.9.4 发送 events 到flume 1.x

Flume OG节点组成图：

Flume NG节点组成图：

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

  • NG 只有一种角色的节点：代理节点（agent）。

  • 没有 collector、master 节点。这是核心组件最核心的变化。

  • 去除了 physical nodes、logical nodes 的概念和相关内容。

  • agent 节点的组成也发生了变化。

Flume NG 以agent为最小的独立运行单位。一个agent就是一个JVM。单agent由Source、Sink和Channel三大组件构成。

Flume的数据流由事件(Event)贯穿始终。事件是Flume的基本数据单位，它携带日志数据(字节数组形式)而且携带有头信息，这些Event由Agent外部的Source，好比上图中的Web Server生成。当Source捕获事件后会进行特定的格式化，而后Source会把事件推入(单个或多个)Channel中。能够把Channel看做是一个缓冲区，它将保存事件直到Sink处理完该事件。Sink负责持久化日志或者把事件推向另外一个Source。值得注意的是，Flume提供了大量内置的Source、Channel和Sink类型。不一样类型的Source、Channel和Sink能够自由组合。组合方式基于用户设置的配置文件，很是灵活。好比：Channel能够把事件暂存在内存里，也能够持久化到本地硬盘上。Sink能够把日志写入HDFS, HBase，甚至是另一个Source等等。Flume支持用户创建多级流，也就是说，多个agent能够协同工做，而且支持Fan-in、Fan-out、Contextual Routing、Backup Routes。以下图：

flume-ng-2

Flume 容许多个 agent 连在一块儿，造成先后相连的多级跳：

一、 source

Flume 支持 Avro，log4j，syslog 和 http post(body为json格式)。可让应用程序同已有的Source直接打交道，如AvroSource，SyslogTcpSource。也能够 写一个 Source，以 IPC 或 RPC 的方式接入本身的应用，Avro和 Thrift 均可以(分别有 NettyAvroRpcClient 和 ThriftRpcClient 实现了 RpcClient接口)，其中 Avro 是默认的 RPC 协议。具体代码级别的 Client 端数据接入，能够参照官方手册。对现有程序改动最小的使用方式是使用是直接读取程序原来记录的日志文件，基本能够实现无缝接入，不须要对现有程序进行任何改动。 对于直接读取文件 Source,有两种方式：

  • ExecSource: 以运行 Linux 命令的方式，持续的输出最新的数据，如 tail -F 文件名 指令，在这种方式下，取的文件名必须是指定的。 ExecSource 能够实现对日志的实时收集，可是存在Flume不运行或者指令执行出错时，将没法收集到日志数据，没法保证日志数据的完整性。

  •  SpoolSource: 监测配置的目录下新增的文件，并将文件中的数据读取出来。须要注意两点：拷贝到 spool 目录下的文件不能够再打开编辑；spool 目录下不可包含相应的子目录。SpoolSource 虽然没法实现实时的收集数据，可是可使用以分钟的方式分割文件，趋近于实时。若是应用没法实现以分钟切割日志文件的话， 能够两种收集方式结合使用。在实际使用的过程当中，能够结合 log4j 使用，使用 log4j的时候，将 log4j 的文件分割机制设为1分钟一次，将文件拷贝到spool的监控目录。log4j 有一个 TimeRolling 的插件，能够把 log4j 分割文件到 spool 目录。基本实现了实时的监控。Flume 在传完文件以后，将会修改文件的后缀，变为 .COMPLETED（后缀也能够在配置文件中灵活指定）

二、Channel

当前有几个 channel 可供选择，分别是 Memory Channel, JDBC Channel , File Channel，Psuedo Transaction Channel。比较常见的是前三种 channel。

  • MemoryChannel 能够实现高速的吞吐，可是没法保证数据的完整性。

  • MemoryRecoverChannel 在官方文档的建议上已经建义使用FileChannel来替换。

  • FileChannel保证数据的完整性与一致性。在具体配置FileChannel时，建议FileChannel设置的目录和程序日志文件保存的目录设成不一样的磁盘，以便提升效率。

File Channel 是一个持久化的隧道（channel），它持久化全部的事件，并将其存储到磁盘中。所以，即便 Java 虚拟机当掉，或者操做系统崩溃或重启，再或者事件没有在管道中成功地传递到下一个代理（agent），这一切都不会形成数据丢失。Memory Channel 是一个不稳定的隧道，其缘由是因为它在内存中存储全部事件。若是 java 进程死掉，任何存储在内存的事件将会丢失。另外，内存的空间收到 RAM大小的限制,而 File Channel 这方面是它的优点，只要磁盘空间足够，它就能够将全部事件数据存储到磁盘上。

三、sink

Sink在设置存储数据时，能够向文件系统、数据库、hadoop存数据，在日志数据较少时，能够将数据存储在文件系中，而且设定必定的时间间隔保存数据。在日志数据较多时，能够将相应的日志数据存储到Hadoop中，便于往后进行相应的数据分析。更多sink的内容能够参照官方手册。

从总体上讲，NG 在核心组件上进行了大规模的调整，核心组件的数目由 7 删减到 4。因为 Flume 的使用涉及到众多因素，如 avro、thrift、hdfs、jdbc、zookeeper 等，而这些组件和 Flume 的整合都须要关联到全部组件。因此核心组件的改革对整个 Flume 的使用影响深远：

  • 大大下降了对用户的要求，如再也不依赖 zookeeper，用户无需去搭建 zookeeper 集群

  • 用户也再也不纠结于 OG 中的模糊概念（尤为是 physical nodes、logical nodes，agent、collector）

  • 有利于 Flume 和其余技术、hadoop 周边组件的整合，好比在 NG 版本中，Flume 轻松实现了和 jdbc、hbase 的集成

  • 将 OG 版本中复杂、大规模、不稳定的标签移除，Flume 实现了向灵活、轻便的转变，并且在功能上更增强大、可扩展性更高

参照连接：

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程