2018.10.9 上線發現elasticsearch寫入速度超級慢，原來罪魁禍首是阿里雲服務的OSS的鍋
阿新 • • 發佈：2018-11-11
問題描述：
- 按照專案計劃，今天上線部署日誌系統（收集線上的所有日誌，便於問題排查）。
- 運維按照以前的部署過程，部署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伺服器上看
[[email protected] ~]# 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 。問題定位到了。發了個郵件出來。
- 第二天，運維重新換磁碟。換了磁碟之後。問題解決。
問題解決過程反思：
- 排查問題，要一步一步來，確定問題點，才能解決問題。猜測是沒有辦法解決問題的。而且猜測了要去論證