前阵子做了一次日志收集系统压测，我们的全链路日志收集系统采用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站点，感兴趣的可以留言索取