Flume日志采集应用架构升级与重构

转眼新的一年又来了，趁着这段时间总结下2017这一年的工作经验，避免重复踩坑。MOB数据采集平台升级也快经历了半年时间，目前重构后线上运行稳定，在这过程中挖过坑，填过坑，为后续业务的实时计算需求打下了很好的基础。

一、升级与重构的原因

上图为旧有架构，主要服务于Hadoop2.x离线计算(T+1)以及Spark的实时计算（T+0），但在数据采集、数据流动、作业调度以及平台监控等几个环节存在的一些问题和不足。

数据采集：

数据采集平台与数据统计分析系统分离，不能统一管理数据流向，并且消耗服务资源

数据收集接口众多，数据格式杂乱：基本每个业务都有自己的上报接口，存在较大的重复开发成本，不能汇总上报，消耗客户端资源，以及网络流量，每个接口收集数据项和格式不统一，加大后期数据统计分析难度。

Flume采集单一channel的使用，可能导致高峰期队列堵塞，数据丢失的问题

平台监控：

只有系统层面的监控，数据平台方面的监控等于空白

针对以上问题，结合在大数据中，数据的时效性越高，数据越有价值的理念，因此，开始大重构数据采集平台架构。

二、升级后的架构设计

这张图是升级后的数据采集架构图，从图中可以了解到大数据采集过程以及数据走向：数据源，数据缓存，存储计算等环节。

将原来数据采集与数据计算架构进行聚合解耦，节省了服务资源，加强了数据采集的数据流的监管，对文件传输及数据完整性监控都有所补充，有利于后期离线或实时运算的可插拔接入。

Flume channel升级

数据传输上，将Flume Memory channel改为Kafka channel，可以缓存数据的同时，弥补日志高峰期，原来Memory channel队列不够的问题，减少重启Flume带来的数据丢失问题

三、监控

- 文件传输监控

Flume: 定制的zabbix监控，在flume里添加了zabbix监控模块

Kafka: 通过监控kafka consumer消费状态，当Lag达到一定值时，进行告警

数据完整监控

比如源数据与目标数据之差，相差超过1%,告警针对告警信息，采取数据补偿措施

四、参数优化

根据业务场景做节点参数调优

调大FlumeServer MemoryChannel的capacity，尽量利用MemoryChannel快速的处理能力；

调大HdfsSink的batchSize，增加吞吐量，减少hdfs的flush次数；

适当调大HdfsSink的callTimeout，避免不必要的超时错误（当然Hdfs也要做配合）

接收消息参数调优

内存调优

修改conf/flume-env.sh文件

五、结语

一个健壮强大的分布式日志采集系统无疑是整个大数据业务的重要枢纽，在实践中的一些关键的设计和思想，希望能抛砖引玉，在未来之路越走越好。

文/Mob开发者平台 Java高级工程师 恒恒