Flume定制实战——日志平台架构解析

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方面，当时并没有为a