Flume总结文档

一、概述

主要用来采集日志，文本。图片和音频不可以

hdfs中的put是静态的，而flume是动态采集，流式架构

1、基础架构

• 主要是agent，是一个 JVM 进程，它以事件的形式将数据从源头送至目的。主要有 3 个部分组成，Source、Channel、Sink
• 数据传输的基本单元：event，包括头header和body两部分

2、配置

// 见讲义第3页

一般是聚合操作，所以就是所有服务器都安装flume，然后收集本地日志信息
最后传到一台flume做聚合，之后这台flume再把数据上传到hdfs或者其他文件系统中

1. 下载tar.gz安装包
2. 解压到module目录下
3. 将 lib 文件夹下的 guava-11.0.2.jar 删除以兼容 Hadoop 3.1.3【会自动配置环境变量里面装好的hadoop】

二、4个本地案例，4个source

// 在flume文件夹下创建job,里面创建配置文件
配置文件里面，设置好路径
还有端口号，hadoop102:8020
还有注意agent里的sources,sinks，channels名字

//然后再flume文件下，执行命令启动flume
bin/flume-ng agent -c conf/ -n [agent的名字，比如a1] -f [配置文件的路径]
    // 执行命令的讲解在讲义的第5页

// 这里主要涉及三种source，channnel都是memory，sink都是到hdfs
netcat source exec source    spooldir source   taildir source
    
   //讲义的3-5页、6-8页、8-10页、10-12页

1、netcat source监控端口

// 讲义的第3-5页

2、exec source监控hive的单个追加文件

这个说的是在官网中找此类型的名字

实际sources的type，sources.k2.type = exec

//讲义的6-8页

具体看讲义中配置文件的讲解

3、spooldir source监控目录下多个文件

只是监控目录中文件的变化

不涉及文件内部的追加和变化

//讲义的8-10页

实际sources的type，sources.k2.type = spooldir

4、taildir source监控目录下多个追加文件

//讲义的10-12页

Exec source 适用于监控一个实时追加的文件，不能实现断点续传；【断点续传就是进程突然中断，之后再开启后，还能继续上传，不用重新从头上传】

Spooldir Source 适合用于同步新文件，但不适合对实时追加日志的文件进行监听并同步；

而 Taildir Source 适合用于监听多个实时追加的文件，并且能够实现断点续传

但是这里面有一个问题，在讲义的第13页有讲解。可以更改源码打包后上传使用，其实就是文件名如果突然更改后，他会把原来文件中的所有数据又上传一遍，很没有意义。这是因为源码中他对文件判断是inode+文件名，它判断只要这两个有一个变化了，就说明涉及到了新数据。所以会在文件更名后重新对文件内的数据加载一次。

更改源码就是把这个文件判断的标准，只要inode，不要文件名了

三、Flume事务 & agent内部原理

// 讲义的13-14页

1、事务

• source将数据推给channel
• sink从channel处拉取数据

事务中传输的就是事件

主要记住doput、doTake

其中涉及判断和回滚

2、agent内部原理

明确：

1. **拦截器链：**对数据进行一些调整

2. **channel selector：**涉及两种类型：

   • 副本机制同一个event发往多个channel，就是一个source对应多个channel
   • Multiplexing，根据事件的头信息决定发往哪个channel

3. sink processor：

   上面的source可以一个对应多个channel，但是sink不可以，只能一个sink对应一个channel

   不过可以一个channel对应多个sink

   有三种：DefaultSinkProcessor 、 LoadBalancingSinkProcessor 和 FailoverSinkProcessor
   

四、拓扑结构

//见讲义的第15-16页

简单串联、复制和多路复用、负载均衡和故障转移、聚合

主要是聚合：

这种模式是我们最常见的，也非常实用，日常 web 应用通常分布在上百个服务器，大者 甚至上千个、上万个服务器。产生的日志，处理起来也非常麻烦。用 flume 的这种组合方式 能很好的解决这一问题，每台服务器部署一个 flume 采集日志，传送到一个集中收集日志的flume，再由此 flume 上传到 hdfs、hive、hbase 等，进行日志分析。

五、企业开发案例

就是简单实现一下上面的后三种不同agent之间的关系

之所以没有尝试第一个，是因为其实每一种方法都包括了简单串联，就是两个agent之间，通过Avro sink 和 Avro source

// 具体见讲义的第17-26 页

下面的所有案例，也是实际生产中需要注意的就是!!!！！！！！！！！！！！！！！！！！！！！！！！！！

// 1、要明确谁是客户端和服务端。配置好相关配置文件

// 2、明确后，需要先开启服务端的flume，再开启客户端的
不需要往别的机器传数据的就被当作是服务器

// 3、然后端口号要设置成服务端的端口号，因为客户端可以远程连接【其实就是设置了客户端的主机名和端口号】。而服务器在avro source中设置自己的主机名和端口号

1、复制和多路复用

//讲义的17-20页

这一步部分就是涉及到channel 选择器，在前面的内部原理部分可以知道有两种策略，一种是副本机制，一种是多路复用multiplexing

这里就是举例子副本机制，两个sink两个channel，一个source传给两个channel的内容是一样的

2、负载均衡和故障转移

// 讲义的第20-23页

这一部分的内容其实就是涉及到sink processors

有三种机制，其中第一种默认的一个channel连一个sink，不需要尝试，基本不会使用

这里主要是轮循：LoadBalancingProcessor，和故障转移FailoverSinkProcessor

3、聚合【常用】

// 讲义的第23-26页

涉及到了多台机器，其实也是企业开发中常用的

不同机器采集日志，最后传给一个机器上传到控制台或者某个文件或者hdfs

注意分清楚谁是服务器就行，端口号设置好

六、自定义Interceptor【重点】

自定义拦截器，在工作中会用到的比较多，比自定义source和自定义sink用的要多

因为基本数据的类型已经定义的比较全面了

主要是根据业务逻辑对数据进行处理，就是拦截器Interceptor的作用了

// 主要是在讲义的第26-30页

多路复用Multiplexing会用到拦截器，就是在channel选择器中告诉这个机器哪些数据应该发往哪些channel

其实就是对event的头信息和body信息进行修改和处理

其实主要涉及四个方法和最后的builder构建。四个方法中最重要的还是单个事件拦截的方法，和批量事件的处理方法。不过批量事件处理的方法可以用循环使用单个事件拦截的方法

1、事件拦截方法

在java代码中重点处理事件拦截代码

哪个机器用到拦截器，就把打包好的程序发到哪个机器。比如讲义中的就是用到Hadoop102

思路就是：

• 获取事件的头信息和body信息，一般头信息默认是空的，我们要基于其body信息的判断
• 对header信息进行添加
• 之后在配置文件中，就是基于头信息中的key进行判断，然后基于value选择分发哪个channel
• 可以好好看看下面的java中定义的方法内容和配置文件的内容之间的联系

//1.获取事件中的头信息
 Map<String, String> headers = event.getHeaders();

 //2.获取事件中的 body 信息
 String body = new String(event.getBody());           //之所以加了一个string,因为getbody返回的是字节数组，进行过序列化了

 //3.根据 body 中是否有"atguigu"来决定添加怎样的头信息
 if (body.contains("atguigu")) {
     
 //4.添加头信息
 headers.put("type", "first");            //要注意，所有的header的key要一样！！！！！！！！
 } else {
     
 //4.添加头信息
 headers.put("type", "second");
 }
 return event;

// a1.sources.r1.bind = localhost
// a1.sources.r1.port = 44444
a1.sources.r1.interceptors = i1
a1.sources.r1.interceptors.i1.type = com.atguigu.flume.interceptor.CustomInterceptor$Builder  //这个是自己的全类名
a1.sources.r1.selector.type = multiplexing
a1.sources.r1.selector.header = type
a1.sources.r1.selector.mapping.first = c1     //first就是上面代码中定义的，不带atgugu内容的value值
a1.sources.r1.selector.mapping.second = c2

    // 好好看看没有注释的这几行

2、builder别忘了写

    public static class Builder implements Interceptor.Builder {  //这里的builder要用flume下面的
        @Override
        public Interceptor build() {
            return new TypeInterceptor();       // 自己定义的那个类名！！！！！！！！！！！！
        }
        @Override
        public void configure(Context context) {
        }
    }

七、自定义source

//见讲义的第30-33页

使用场景：读取 MySQL 数据或者其他文件系统。

不过其实一般用的不是比较多。

1. 自定义 MySource 需要继承 AbstractSource 类并实现 Configurable 和 PollableSource 接口

2. 在java中主要对process和configure【就是编写在配置文件中类似type，bind,这些名字】进行编写。

   //初始化配置信息
    @Override
    public void configure(Context context) {
        delay = context.getLong("delay");
        field = context.getString("field", "Hello!");
    }
   
   
   //看配置信息
   # Describe/configure the source
   a1.sources.r1.type = com.atguigu.MySource    
   a1.sources.r1.delay = 1000					//上面代码定义的delay,field
   #a1.sources.r1.field = atguigu
   

3. 在配置文件中自定义的source的type，就是全类名

八、自定义sink

//讲义的33-37页

类似source。

Sink 是完全事务性的。在从 Channel 批量删除数据之前，每个 Sink 用 Channel 启动一 个事务。批量事件一旦成功写出到存储系统或下一个 Flume Agent，Sink 就利用 Channel 提 交事务。事务一旦被提交，该 Channel 从自己的内部缓冲区删除事件。

流程如下：

source不涉及到推送事务，就是不涉及把这些数据事件推送到channel。因为这个是source processor做的，后面有类去实现，已经封装好的，这个不涉及自定义。

但是sink涉及到拉取事务，所以在代码中还要开启事务，判断是否sink不能使用需要事务回归，或者关闭事务。

如果正常的话，就拉取channel中的事件，然后提交事务

// 讲义中的代码process 从 Channel 读取获取数据（event），这个方法将被循环调用。
所以相当于展示的是拉取一个事件。也可以批量处理一批事件【数据】
但是讲义中展示的就是一个数据【一个事件】用Logger打印到桌面
    
//开启和提交事务：在自定义 sink 的 process 方法中，通常会有如下步骤：
开启事务：在读取事件之前开启一个新事务。
读取并处理事件：从 Channel 中读取事件，并执行必要的处理。
提交事务：如果所有事件都被成功处理，则提交事务。
回滚事务：如果在处理事件过程中遇到错误，则回滚事务。
    
    

九、数据流监控

这里用到的是 Ganglia

监控数据上传成功或者失败的数据条数

// 主要见讲义的37-40页

1、介绍

Ganglia 由 gmond、gmetad 和 gweb 三部分组成。

• gmod：收集数据
• gmetad：存储数据
• gweb：展示数据

所以hadoop102 hadoo103 hadoop103，都要布局收集数据的gmod，hadoop102有namennode，所以再布局上存储数据和展示数据

注意gweb，和Linux中一个安全校验是天敌。由于gweb是php编写的，所以之后要关一个服务。在讲义里有写

2、配置

• 安装epel-release,所有机器都安装
• 根据配置计划安装上述的 gmond、gmetad 和 gweb 三部分
• 修改配置文件。主要修改102机器上gweb配置文件中需要展示的机器ip地址，这里就是用hadoop102的浏览器所以用hadoop102的ip，如果想要用windows，则需要用自己win电脑的vnet8中的ipv4的地址
• 配置102的gmetad存储数据的配置文件中的主机和名字，这样可以在102，103，104上配置gmod中的名字，和要将采集到的数据发往哪台主机的主机地址，和bind
• 之后就可以打开浏览器去监控了，如果配置在Hadoop102上了gweb，那就是网http://hadoop102/ganglia
• 根据监控到的字段显示的数据，可以知道成功和失败的情况，失败的比较多的话说明机器性能不太好，需要配置。也可以看到有没有丢失数据。