Flume线上集群的吞吐量瓶颈排查及优化

记录一次flume线上环境的吞吐量瓶颈排查和解决方案。

1、线上Flume集群架构简介

Flume线上架构图如下:

目前线上部署flume的服务器有六十台左右,主要分外网环境和内网环境,这些都是游戏的服务器集群,每个游戏的服务器集群可能单独有一套外网环境(包含flume跳板机)。外网环境A和内网环境B的flume都会往内网跳板机发送数据,分发方式是负载均衡模式,两个内网跳板机收集所有数据再发送给kafka,最后由Hadoop和Spark等进行存储消费。(其中kafka sink是自定义开发的,根据日志内容动态分配topic。)

Flume线上集群的吞吐量瓶颈排查及优化_第1张图片

 

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进程主动向监控平台汇报各组件数据传输情况。)

 

你可能感兴趣的:(大数据)