记录一次flume线上环境的吞吐量瓶颈排查和解决方案。
1、线上Flume集群架构简介
Flume线上架构图如下：
目前线上部署flume的服务器有六十台左右，主要分外网环境和内网环境，这些都是游戏的服务器集群，每个游戏的服务器集群可能单独有一套外网环境（包含flume跳板机）。外网环境A和内网环境B的flume都会往内网跳板机发送数据，分发方式是负载均衡模式，两个内网跳板机收集所有数据再发送给kafka，最后由Hadoop和Spark等进行存储消费。（其中kafka sink是自定义开发的，根据日志内容动态分配topic。）
2、问题描述
外网环境的部分服务器数据量突增时候，发现kafka写出的速度很慢，每小时吞吐量只有6G左右，数据量大时产生的延迟对数据仓库及线上报表的统计有不良影响。
3、排查过程
根据整个架构来看有两个可能：Flume问题或者Kafka问题。由于kafka集群服务没有进程及资源问题，正常情况吞吐量不会这么小，所以首先排查flume传输架构。
（1）在内网的测试服务器起Flume进程，传入大量测试日志进行吞吐量测试，发现吞吐量很高。可以排除内网两台跳板机出问题的可能。
（2）在外网某台日志采集服务器放大量测试日志，发现kafka写出速度依然是6G左右。由于外网日志采集服务器有多台，如果单台日志采集服务器的瓶颈是6G，那多台时候集群瓶颈应该是6的n倍，所以可以肯定采集服务器无问题，瓶颈在于外网跳板机。
（3）锁定外网跳板机之后，首先想到的是外网带宽，带宽不足会影响瓶颈，外网服务器单台带宽是100M，两台服务器加起来的带宽是200M，吞吐量带宽瓶颈应该在90G/小时左右，所以排除带宽不足问题。
确定完外网Flume的agent问题，就要判断具体是哪个组件的问题（source、channel、sink），通过flume的数据监控（使用方法：启动时候加监控参数 $ bin/flume-ng agent --conf-file example.conf --name a1 -Dflume.monitoring.type=http -Dflume.monitoring.port=34545）可以发现，agent的channel组件，空间占用率一直是百分之百，配合其他组件数据指标基本可以判断source速度较快，sink速度较慢，主要瓶颈在于sink组件。
4、优化过程
在外网flume跳板机服务器上起测试flume进程，开始调试flume参数，调试过程配合flume的数据监控会事半功倍，通过调整avor sink的batch-size=900等参数发现速度明显加快，新的瓶颈又转移到了source组件，然后又调整avro source的最大线程数threads=10等参数，提高了source的速度，最后吞吐量达到外网跳板机吞吐量要求后，优化完成。
（下一篇文章分享flume的自定义数据监控功能 Custom Reporting，由flume进程主动向监控平台汇报各组件数据传输情况。）