filebeat+kafka+logstash+elasticsearch全链路日志收集系统压测分享

前阵子做了一次日志收集系统压测，我们的全链路日志收集系统采用filebeat+kafka+logstash+elasticsearch，今天主要分享原始日志入库ES的压测经验，并不涉及storm的实时日志处理。压测目标是120万条日志/分钟，压测团队由本人、自动压测同事、SRE、众多PO、领导组成。压测的目标是明确的，却不太好下手。经过优化后，大概摸索出了方案。真是团队协作才完成，手上排满了别的活，这个压测算是挤进来的。很多操作都是同事在帮忙操作。无论如何，也算是出了一个压测报告，与持续优化的经验。

初始压测环境

1.yue.ma    ES-9100-9200-9300
2.yue.ma    logstash-  zookerper-2182 storm  ui-8080  nimbus-16627
3.yue.ma    kafka-9092   redis-63705
4.yue.ma    mysql5.7-3306
5.yue.ma    iis、filebeat、LogGenerator服务、WebGenerator站点
6.yue.ma    iis、filebeat、LogGenerator服务、WebGenerator站点
7.yue.ma    压测客户端
8.yue.ma    压测客户端

以上机器均为8核16G内存，[1-8].yue.ma为脱敏host，仅做示例

压测优化思路

依据120万条日志/分钟的要求，我们通过ES查看工具，配合自己写的ES入库速率实时分析显示工具，实时观察入库速度，未达到要求，就分析，调整，直到满足目标。

日志生成

我们采用了服务生成日志、站点生成日志两种不同的方式，分别代别了实时业务中的场景。LogGenerator服务生成服务类日志，WebGenerator站点生成站点日志，站点的日志生成需要压测机器发起大量的请求​。有同事基于jmeter做好了压测工具​。​

优化后的压测环境

1.yue.ma    ES-9100-9200-9300  logstash-
2.yue.ma    logstash-  zookerper-2182 storm  ui-8080  nimbus-16627
3.yue.ma    kafka-9092   redis-63705 
4.yue.ma    mysql5.7-3306 logstash-
5.yue.ma    iis、filebeat、LogGenerator服务、WebGenerator站点
6.yue.ma    iis、filebeat、LogGenerator服务、WebGenerator站点
7.yue.ma    压测客户端
8.yue.ma    压测客户端

实时优化措施

优化操作	优化来源	未优化前	执行	优化后
logstash节点增加到2个	实时观察	kafkak中可以查看到logstash消费存在堆积 查看命令： ./kafka-consumer-groups.sh --bootstrap-server 3.yue.ma:9092 --describe --group  sss	SRE执行	有所缓解
调整kafka的topic的partion数量	实时观察	每个topic只有一个partion，仅能被一个logstash consumer线程消费。这个时候有2个logstash，因此每个topic的partion数量配置为2 通过./kafka-consumer-groups.sh --bootstrap-server 3.yue.ma:9092 --describe --group  sss可查看到消费者情况	通过图形化工具http://10.14.71.5:9000/调整kafka每个topic的partion .此kafka工具由SRE安装	单个topic可以被多个logstash consumer线程消费
调整logstash consumer线程数量	实时观察	发现有的logstash服务器未工作，有的服务器全抢占了partion 通过./kafka-consumer-groups.sh --bootstrap-server 3.yue.ma:9092 --describe --group  sss可查看到消费者情况	SRE调整logstash配置,将原来5个线程调整为2个线程	每个logstash服务器都参与进来
1.logstash节点增加到3个 2.调整kafka中topic的partion数量为3 3.Logstash的Consumer线程数保持为2，因为只有2个topic	实时观察	发现有服务器上的LogStash在处理Common日志上还是不够快，能查看到kafka日志堆积 通过./kafka-consumer-groups.sh --bootstrap-server 3.yue.ma:9092 --describe --group  sss可查看到消费者情况	SRE执行	3个logstash服务器同时工作

历史经验

优化LogStash批量写
调整ES模板

没有设计任何场景与验证，直接向同事打听到去年压测的经验。

压测结论

短日志场景	单条日志长度22个字符
入库ES峰值	140万条日志/分钟
长日志场景	单条日志长度7143个字符
入库ES峰值	40万条日志/分钟
瓶颈分析	1.kafka中显示logstash消息正常无积压 2.网络为1.5 Gbps , 250MB/s，到达网络瓶颈
进一步优化方案	可增加kakfa节点，预计需要新增加2个节点，才能达到120万/分钟日志入库ES要求

测压解读，我们压到40万长日志/分钟的时候，就停止了进一步压测。依据长短日志的压测优化经验，日志系统的吞吐量可以通过调整kafka、logstash、ES的节点数来适应目标容量要求。Kafka的节点数大概为每分钟日志量的大小除以每分钟带宽满载的传输量，Logstash的数量可以观察消费堆积情况，增加数量。本次压测的经验是将kafka中topic的partion数量配置为logstash消费线程数，这样子，每个logstash都能保持工作状态。然后，每种topic的日志量占比不尽相同，可以在实战中进一步优化配置。ES侧的优化未进行，依据这次优化的经验，同样可从日志传输量与带宽角度，推测出ES节点数要求。有一个合理的初始配置，再在初始配置的基础上进行优化。

干货

kafka的图形管理工具，是开源WEB管理工具

ES入库速率实时分析显示工具，这个工具是DIY的，能实时显示当前入库到ES的日志速度，感兴趣的可以留言索取。

本次压测收集到的命令集合，感兴趣的可以留言索取

LogGenerator服务，感兴趣的可以留言索取

WebGenerator站点，感兴趣的可以留言索取

欢迎关注公众号