2018.10.9 上线发现elasticsearch写入速度超级慢，原来罪魁祸首是阿里云服务的OSS的锅

问题描述：

• 按照项目计划，今天上线部署日志系统（收集线上的所有日志，便于问题排查）。
• 运维按照以前的部署过程，部署elasticsearch,部署结束之后，通过x-pack的monitor发现elasticsearch的索引速度只有几百/秒的索引速度，远远小于同样的配置，没有做优化的另一个es集群。问题就产生了，什么原因呢

问题定位：

• 下午比较忙，没有时间排查问题，就让另个同事，排查，下午下班的时候去问什么原因，同事告诉我说是，logstash问题，我信了，因为他对比了以前的logstash 配置，消费kafka主题的配置从以前的topics_pattern=>["server1.history","server2.history"]变更为了topics_pattern => [".*history"]；对于这个回答我信了，我问他对比测试过了？，回答说给了肯定的回答。那好，找到问题，可以去吃饭了。
• 结果到了晚上，8点从公司外面回来，同事过来和我说，还是有问题。
• 正好我有空，我就自己来排查，虽然过程麻烦了点
• 首先我排查：同事说的kafka的数据产生的慢的问题；我自己用消费命令消费一个产数据很多的topic的最新数据，kafka-console-consumer.sh --bootstrap-server:localhost:9092 --topic server.history ;肉眼看明显数据产生并不慢。那么问题并不是kafka的问题。我也没见过kafka会出现大问题
• 然后，我排查logstash的消费快慢问题；我把logstash的output配置成stdout.肉眼看明显消费也不慢。那么问题也不是logstash的消费慢的问题
• 剩下的排查点就是logstash的output的问题了。改成elasticsearch之后，发现进入elasticsearch的数据几百/秒，可见问题很大在elasticsearch这边
• 我果断的把一个logstash的output的目标给为另一个正常的，速度较快elasticsearch集群。马上发现，这个集群elasticsearch的索引速度一下就是几千每秒（还没做优化，后期优化之后是几万每秒）。说明问题在新的elasticsearch集群
• 简单对比了一下集群配置，没有什么大的区别，发了个问题在群里“新的elasticsearch集群和以前的有什么区别”。我以为会得到答案：“没有区别”，
• 结果答案是“这次的使用的磁盘是阿里云的oss磁盘”。我反正不懂这是什么磁盘。然后我登到elasticsearch服务器上看

[root@online-log-elasticsearch-002 ~]# top

top - 21:53:28 up 1 day, 10:30,  1 user,  load average: 2.16, 1.98, 1.65

Tasks:  94 total,   2 running,  92 sleeping,   0 stopped,   0 zombie

%Cpu(s):  15.4/12.0   27[|||||||||||||||||||||||||||                                                                         ]

KiB Mem :  8010196 total,   507524 free,  7048124 used,   454548 buff/cache

KiB Swap:        0 total,        0 free,        0 used.   702952 avail Mem

add filter #1 (ignoring case) as: [!]FLD?VAL

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                               

21285 elastic   20   0 1850420  36896   1812 S 102.2  0.5 736:00.98 ossfs online-all-log /data/ -ourl=http://oss-cn-hangzhou-internal.aliyuncs.com                        

16719 elastic   20   0  9.857g 6.518g  11656 S  11.0 85.3   3:24.11 /usr/jdk1.8.0_162/bin/java -Xms6g -Xmx6g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75+

• 从top中可以看到，21285 elastic   20   0 1850420  36896   1812 S 102.2  0.5 736:00.98 ossfs online-all-log /data/ -ourl=http://oss-cn-hangzhou-internal.aliyuncs.com ossfs 服务占了100%上下的cpu 。问题定位到了。发了个邮件出来。
• 第二天，运维重新换磁盘。换了磁盘之后。问题解决。

问题解决过程反思：

• 排查问题，要一步一步来，确定问题点，才能解决问题。猜测是没有办法解决问题的。而且猜测了要去论证