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

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

1、升级与重构的缘由

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

• 数据采集：

  • 数据采集平台与数据统计分析系统分离，不能统一管理数据流向，而且消耗服务资源
  • 数据收集接口众多，数据格式杂乱：基本每一个业务都有本身的上报接口，存在较大的重复开发成本，不能汇总上报，消耗客户端资源，以及网络流量，每一个接口收集数据项和格式不统一，加大后期数据统计分析难度。
  • Flume采集单一channel的使用，可能致使高峰期队列堵塞，数据丢失的问题

• 平台监控：

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

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

2、升级后的架构设计

这张图是升级后的数据采集架构图，从图中能够了解到大数据采集过程以及数据走向：数据源，数据缓存，存储计算等环节。
将原来数据采集与数据计算架构进行聚合解耦，节省了服务资源，增强了数据采集的数据流的监管，对文件传输及数据完整性监控都有所补充，有利于后期离线或实时运算的可插拔接入。

• Flume channel升级
  

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

3、监控

- 文件传输监控

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

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

• 数据完整监控
  好比源数据与目标数据之差，相差超过1%,告警针对告警信息，采起数据补偿措施

4、参数优化

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

  • 调大FlumeServer MemoryChannel的capacity，尽可能利用MemoryChannel快速的处理能力；
  • 调大HdfsSink的batchSize，增长吞吐量，减小hdfs的flush次数；
  • 适当调大HdfsSink的callTimeout，避免没必要要的超时错误（固然Hdfs也要作配合）
  • 接收消息参数调优
• 内存调优
  修改conf/flume-env.sh文件

5、结语

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