Flume定制实战

最新推荐文章于 2022-03-04 08:51:43 发布
最新推荐文章于 2022-03-04 08:51:43 发布
阅读量1.1k 收藏 1
点赞数
分类专栏： 架构 文章标签： hadoop flume
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/beyond59241/article/details/73719265
版权

flume是我2015年为前公司主导开发【统一日志平台】时采用的技术(主要技术栈：flume+ES+Redis+mongoBD+Kafka+Hadoop+Netty )，期间也积累了不少经验（挖坑、踩坑、填坑）。

在我离开前，我们的日志平台数据量为8亿/天，高峰为8500万/小时、800万/5分钟。 flume agent单机压测15000/s数据量，未出现程序异常、资源占用过高与日志明显丢失情况。

离开前东家后，便没有再从事该类型的工作，因此当时的一些关于日志平台的想法也不再有机会去实践，暂且认为这是0.1版本吧。

本文将主要介绍我们在flume上做的一些定制开发与压测，另外时间已经过去了一年多，有一些细节难免有点忘却。

1.Flume介绍

1.1 架构介绍

image.png

agent本身是一个Java进程，运行在日志收集节点—所谓日志收集节点就是服务器节点。 

agent里面包含3个核心的组件：source—->channel—–>sink,类似生产者、仓库、消费者的架构。 

source：source组件是专门用来收集数据的，可以处理各种类型、各种格式的日志数据,包括avro、thrift、exec、jms、spooling directory、netcat、sequence generator、syslog、http、legacy、自定义。 

channel：source组件把数据收集来以后，临时存放在channel中，即channel组件在agent中是专门用来存放临时数据的——对采集到的数据进行简单的缓存，可以存放在memory、jdbc、file等等。
 
sink：sink组件是用于把数据发送到目的地的组件，目的地包括hdfs、logger、avro、thrift、ipc、file、null、Hbase、solr、自定义。 

event：将传输的数据进行封装，是flume传输数据的基本单位，如果是文本文件，通常是一行记录，event也是事务的基本单位。event从source，流向channel，再到sink，本身为一个字节数组，并可携带headers(头信息)信息。event代表着一个数据的最小完整单元，从外部数据源来，向外部的目的地去。

2.背景说明

我们的需求是将Java 应用的log信息进行收集，达到日志采集的目的，agent目前主要有flume、Logstash，技术选型详情在此就不表了，最终选择的flume。

由于当时公司内部推行技术组件一直有难度，且也无法借助行政手段，因此我们在设计时很多时候考虑都是尽量对应用透明，比如我们的flume source使用的是基于log文件的，而未使用应用与flume agent采用长连接的方式（该方式需要修改log4j配置，并且引入我们的jar），比如我们agent进行日志等级判断时 需要兼容各种日志格式，因为我们难以推动各个应用方统一日志格式……

sre方面，当时并没有为agent预留内存等资源，所以一旦我们的agent出现资源占用过多，都会比较敏感。

整个日志平台1.0版本的架构图如下：

image.png

可以看到我们使用kafka将log信息做转储，消息消费者主要有HDFS、ES、Queue等。

3.定制开发

从我们的实际情况出发，我们做定制开发部分主要是source和sink部分。同时我们也开发了一套agent自动部署工具。

3.1 source定制

3.1.1 dirSource

基于文件的dirSource在flume高版本里已经去除了，原生的dirSource也存在很多性能和功能上的问题，为了在我们使用的flume1.6版本里继续使用dirSource，我们就基于1.6实现了一版dirSource。

dirSource特性
  • 基于NIO的WatchEvent进行log文件内容的写操作监听，同时有能动态的监听文件的创建和删除。我们丰富了这部分的匹配模式，可以实现灵活的文件监听。
  • 文件的读取基于RandomAccessFile，按行读取
  • 将获取内容进行处理封装Event，存入Channel。
存在的问题
  • 无论是WatchEvent还是RandomAccessFile在log疯狂输出时，CPU占用会居高不下。

3.1.2 execSource

execSource为flume新版本推出的用来替代dirSource的一种实现方式，主要是通过Java执行shell命令，并且获取shell命令的输出信息，如tail、cat等。

我们在原生的execSource基础上，实现了文件的自动监听，实现了多命令模式，并且会自动回收长时间无内容产出的命令，优化了原有的线程关闭的操作及进程钩子等。

execSource特性
  • 基于NIO的WatchEvent进行log文件内容的写操作监听，同时有能动态的监听文件的创建和删除。我们丰富了这部分的匹配模式，可以实现灵活的文件监听
  • 多命令模式
  • 自动回收长时间无内容产出的命令
  • 重启时自动清理无用的shell命令
存在的问题
  • flume agent进程被kill -9 时，对导致执行的shell命令无法退出，进而导致句柄得不到释放，积累下来对服务器造成影响。

3.2 sink定制

我们采用的是kafka sink，flume原生的kafka sink使用的是老版本kafka producer client，发送消息时需要手动实现批量与异步，并且是消息发送的实现上存在一些不足，在大数据量时存在明显的性能瓶颈，并且会由于集合中消息数量太多而报异常，进而丢失消息。

我们定制的版本使用的new kafka producer client ，并且对消息发送做了优化，同时对Channel参数做了大量的压测，最终确定了最优配置。

kafkaSink特性
  • 使用new kafka producer client ，默认异步批量发送
  • 优化了消息体序列化方式

4.压测

下文描述的压测都是在建设日志平台过程中对flume的相关测试。
测试环境都是mac book pro ，这里只关注各个测试项的对比信息。

测试一

类型日志总数生产频率cpucpu平均mem数据丢失用时
tailDirSource+New kafka sink50万2000/s16-27%20%230M几百条以内280s
tailDirSource+Old kafka sink50万2000/s16-27%19%230M较上一种丢失少280s
tailDirSource+New kafka sink50万4000/s34-60%40%230M<2000145s
tailDirSource+Old kafka sink50万4000/s34-57%41%230M<200145s
execSource+Old kafka sink50万4000/s<8%7.5%230M<200145s
execSource+Old kafka sink+Spillable Memory Channel50万4000/s8-10%9.5%230M<200145s
execSource+Old kafka sink+File Channel50万4000/s40-55%45%230M<200145s

说明：
* 类型New kafka sink为：原生sink，使用kafka旧client，只定制了从head中获取配置参数，拼接字符串
* 类型Old kafka sink为：深度定制版，使用kafka新client

结论：
* flume 资源占用从kafka发送部分目前没有太好的优化方案，且旧kafka client数据丢失更加严重。
* 因此flume kafka sink 维持不变，后续可从flume source入手优化

测试二

类型日志总数生产频率cpu占用cpu平均内存占用数据丢失用时JVM配置
tailDirSource+ kafka api sink50万3100/s34-60%40%230M<200163s512M
tailDirSource+ kafka sink50万3100/s34-57%41%230M<200163s512M
execSource+ kafka sink50万3100/s<8%7.5%230M<200163s512M
execSource+ kafka sink+Spillable Memory Channel50万3100/s8-10%9.5%230M<200163s512M
execSource+ kafka sink+File Channel50万3100/s40-55%45%230M<200163s512M
execSource+ kafka sink+MemoryChannel500万31074/s30-100%40%1G<200163s1G
execSource+ kafka sink+MemoryChannel250万15337/s15-20%18%450M<200163s1G
execSource+ kafka sink+MemoryChannel+FastJSON250万15337/s18-22%20%420M<200163s1G
custom execSource+ kafka sink+MemoryChannel+FastJSON250万15432/s18-25%21%420M<200162s1G
custom execSource+ kafka sink+MemoryChannel+FastJSON125万+125万7661/s+7668/s20-26%24%440M<500163s1G

测试三

配置说明一
    a1.sinks.k1.batch.num.messages = 5000
    a1.sinks.k1.block.on.buffer.full = true
    a1.sinks.k1.buffer.memory = 167108864


    a1.channels.c1.type = memory
    a1.channels.c1.capacity = 100000
    a1.channels.c1.transactionCapacity = 1000

    flume -Xmx256M -Xms256M
测试结果一
日志写数量用时线程数QPS日志文件量成功发送到kafka数量topic个数CPU内存序列化方式其他
500万74s5070000/s600m280万（单个topic）2未统计300Mfastjsonagent异常
配置说明二
    a1.sinks.k1.batch.num.messages = 5000
    a1.sinks.k1.block.on.buffer.full = true
    a1.sinks.k1.buffer.memory = 167108864


    a1.channels.c1.type = memory
    a1.channels.c1.capacity = 500000
    a1.channels.c1.transactionCapacity = 500
    a1.channels.c1.byteCapacity = 536870912

    flume -Xmx256M -Xms256M
测试结果二
日志写数量用时线程数QPS日志文件量成功发送到kafka数量topic个数CPU内存序列化方式其他
500万68s5074000/s600m500万（单个topic）2200%以上320Mfastjson无异常
500万68s5074000/s600m500万（单个topic）1100%-200%320Mfastjson无异常
500万68s5074000/s600m500万（单个topic）1小于100%280MStringBuild拼接无异常
总结

  1. 数据量过大时，sink中kafka client 缓存被存满，kafka会报异常，设置block=true后，存入缓存会被阻塞，kafka不报异常，但是由于sink从channel中消费的速度远低于source存入channel的速度，channel会报Unable to put event on required channel，flume停止提供服务。继续写入日志，会重复发送错误。

  2. 该异常可通过增大channel的byteCapacity参数或者调大JVM的参数值（byteCapacity默认为JVM的80%）来提高报错的阀值，且减小transactionCapacity 的值来减缓传输到sink的数据量。

  3. JVM内存参数在7万每秒的压力下，设置为256M较为合适，byteCapacity设置为512M较为合适，当增加channel个数或者增大channel向sink传输的数据量时，都会导致sink消费过慢报异常（总结1中异常），单个channel内存消耗在300M左右。

4. 对于数据量较大的应用，建议只发送单个topic。

本文首发在 高广超的简书博客 转载请注明！

image.png

高广超
关注
专栏目录
Flume定制实战——日志平台架构解析
高广超的博客
04-19 323
flume是我2015年为前公司主导开发【统一日志平台】时采用的技术(主要技术栈：flume+ES+Redis+mongoBD+Kafka+Hadoop+Netty )，期间也积累了不少经验（挖坑、踩坑、填坑）。 在我离开前，我们的日志平台数据量为8亿/天，高峰为8500万/小时、800万/5分钟。 flume agent单机压测15000/s数据量...
Flume日志收集
weixin_33828101的博客
05-25 373
一、Flume介绍 Flume是一个分布式、可靠、和高可用的海量日志聚合的系统，支持在系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。 设计目标： (1) 可靠性 当节点出现故障时，日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障，从强到弱依次分别为：end-to-end（收到数据agent首先...
大数据Flume企业开发实战
赵广陆
11-26 1002
目录1 复制和多路复用1.1 案例需求1.2 需求分析：单数据源多出口案例（选择器）1.3 实现步骤2 负载均衡和故障转移2.1 案例需求2.2 需求分析:故障转移案例2.3 实现步骤3 聚合3.1 案例需求3.2 需求分析:多数据源汇总案例3.3 实现步骤 1 复制和多路复用 1.1 案例需求 使用 Flume-1 监控文件变动，Flume-1 将变动内容传递给 Flume-2，Flume-2 负责存储 到 HDFS。同时 Flume-1 将变动内容传递给 Flume-3，Flume-3 负责输出到
【Flume】（五）Flume 企业开发实战（自定义 Interceptor、自定义 Source、自定义 Sink）
云祁QI
04-08 1119
文章目录一、复制和多路复用二、负载均衡和故障转移三、聚合四、自定义 Interceptor五、自定义 Source六、自定义 Sink 一、复制和多路复用 1）案例需求 使用 Flume-1 监控文件变动，Flume-1 将变动内容传递给 Flume-2，Flume-2 负责存储 到 HDFS。同时 Flume-1 将变动内容传递给 Flume-3，Flume-3 负责输出到 Local File...
Flume实战开发配置
axiaoboge的博客
09-17 440
example 1. 实际开发中我们常用的是把Flume采集的日志按照指定的格式传到HDFS上，为我们的离线分析提供数据支撑 我们使用二个主机进行数据的生产与采集，简单的了写了一个脚本, 服务器 hadoop1 #!/bin/bash #打印100次文本到dynamic.log文本中 for((i=1;i<=100;i++)) do echo $i hello,wolrd &...
Apache Flume实战：Hadoop日志收集与定制
此外，书中的内容详细介绍了如何设计和实现一系列定制的Flume agent，以便根据实际需求调整数据传输流程。 对于每个组件，书籍提供了详尽的实现和配置选项，使得读者能够灵活地调整Flume的工作模式，满足不同的业务...
Flume Source组件实战—Avro、Spool、Exec（详细图文）
夏天小厨的博客
12-11 6543
在Flume原理剖析和安装部署章节，我们最后提到NetCat Source的实例，实现了监听一个指定的网络端口，只要在应用程序向这个端口里面写数据，这个NetCat Source组件就能获取到信息。本章内容继续讲解Flume Source的其他几个常用组件，Avro Source、Spool Source、Exec Source，后两者是属于自动监控读取文件的source组件。因为本文只测试Sou...
Flume实战：灵活构建高效大数据实时流处理
同时，它也为开发者提供了宝贵的实践指导，教会他们如何编写Flume插件和定制组件，以适应特定的应用场景。 对于希望在大数据领域实现快速、连续的数据摄入，并充分利用Hadoop生态系统的企业或团队，这本1积分英文...
Apache Flume实战：弹性、可扩展的数据流传输
6. **拦截器、通道选择器、接收器组和接收器处理器**：这些组件允许对数据进行定制处理，如过滤、转换和格式化。 7. **向Flume发送数据**：通过API接口从自定义应用程序中发送数据到Flume代理的详细方法。 8. **...
Flume日志收集系统详解----硬核解析
我玩的很开心的博客
08-17 1886
Flume日志收集系统详解一、Flume简介1.1 Flume特点1.1.1 可靠性1.1.2 可恢复性1.2 Flume架构二、Flume原理2.1 主要组件2.2 工作流程三、flume创建实例3.1 Exec Source 类型3.2 Exec Source 类型 一、Flume简介 Apache Flume是一个 分布式的、可靠的、可用的 数据收集系统 ，它可以有效地收集、聚合和移动大量的 日志数据 ，这些数据可以从许多不同的来源转移到一个集中的数据存储中。 Apache Flume不仅仅限于日志数
Flume最佳实践手册
09-10
Flume最佳实践手册，总结自自己的实战开发，分享给大家共通交流。
实战Flume基础
05-13
实战flume基础，带你入门，分布式、高可靠的和高可用的日志采集系统，用 来从不同来源的系统中采集、汇总和搬移大容量的日志数据到一个集中式的数据存储中
storm、kafka、flume性能测试
08-16
storm、kafka、flume性能测试相关收集
大数据最佳实践-flume
program哲学
04-21 579
目录概述系统要求架构代码实战Properties 概述 flume是一个分布式的、可靠的、可用的系统，用于有效地收集、聚合大量的日志数据，并将这些数据从许多不同的源移动到一个集中的数据存储区。 apacheflume的使用不仅限于日志数据聚合。由于数据源是可定制的，Flume可以用来传输大量的事件数据，包括但不限于网络流量数据、社交媒体生成的数据、电子邮件和几乎所有可能的数据源。 系统要求 Java运行时环境-Java 1.8或更高版本 内存—为源、通道或接收器使用的配置提供足够的内存 磁盘空间-足够的磁盘
Flume12：Flume的各种自定义组件
weixin_40612128的博客
03-04 441
各种自定义组件 咱们前面讲了很多组件，有核心组件和高级组件 source、channel、sink以及Source Interceptors，Channel Selectors、Sink Processors 针对这些组件，Flume都内置提供了组件的很多具体实现，在实际工作中，95%以上的数据采集需求都是可以满足的，但是谁也不敢保证100%都能满足，因为什么奇葩的需求都会有，那针对系统内没有提供的一些组件怎么办呢？ 假设我们想把flume采集到的数据输出到mysql中，那这个时候就需要有针对mysql的s
采集框架Flume
huangyinzhao的博客
04-25 314
1. 日志采集框架Flume1.1 Flume介绍1.1.1 概述u Flume是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统。u Flume可以采集文件，socket数据包等各种形式源数据，又可以将采集到的数据输出到HDFS、hbase、hive、kafka等众多外部存储系统中u 一般的采集需求，通过对flume的简单配置即可实现u Flume针对特殊场景也具备良好的自定义扩展能力...
使用Flume+Kafka+SparkStreaming进行实时日志分析
热门推荐
Trigl的博客
05-24 5万+
每个公司想要进行数据分析或数据挖掘，收集日志、ETL都是第一步的，今天就讲一下如何实时地（准实时，每分钟分析一次）收集日志，处理日志，把处理后的记录存入Hive中，并附上完整实战代码1. 整体架构思考一下，正常情况下我们会如何收集并分析日志呢？首先，业务日志会通过Nginx（或者其他方式，我们是使用Nginx写入日志）每分钟写入到磁盘中，现在我们想要使用Spark分析日志，就需要先将磁盘中的文件上
flume详解
qq_45048256的博客
12-29 4934
flume详解
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值