節(jié)點(diǎn)間磁盤使用率差距不大，監(jiān)控中節(jié)點(diǎn)CPU使用率或load_1m呈現(xiàn)明顯的負(fù)載不均衡現(xiàn)象。

節(jié)點(diǎn)間磁盤使用率差距很大，監(jiān)控中節(jié)點(diǎn)CPU使用率或load_1m呈現(xiàn)明顯的負(fù)載不均衡現(xiàn)象。

Shard設(shè)置不合理。

Segment大小不均。

存在典型的冷熱數(shù)據(jù)需求場(chǎng)景。

采用負(fù)載均衡及多可用區(qū)架構(gòu)部署時(shí)，由于長(zhǎng)連接不釋放可能會(huì)導(dǎo)致流量不均（很少出現(xiàn)），詳情請(qǐng)參見長(zhǎng)連接不均勻。

場(chǎng)景

分析

1. 優(yōu)先檢查查詢期間的網(wǎng)絡(luò)及ECS情況。如果ECS環(huán)境正常，再查看網(wǎng)絡(luò)流量監(jiān)控。

   根據(jù)監(jiān)控結(jié)果發(fā)現(xiàn)異常期間（16:21）網(wǎng)絡(luò)請(qǐng)求上升，查詢QPS上升，對(duì)應(yīng)的CPU節(jié)點(diǎn)負(fù)載大幅增高。結(jié)合查詢策略，初步判斷負(fù)載高的節(jié)點(diǎn)主要承擔(dān)了查詢請(qǐng)求。

   

2. 使用GET _cat/shards?v，查看索引的shard信息。

   從結(jié)果可以看到test索引的shard在負(fù)載高的節(jié)點(diǎn)上呈現(xiàn)的數(shù)量較多，說明shard分配不均；然后查看磁盤使用率監(jiān)控圖，顯示負(fù)載高的節(jié)點(diǎn)使用率比其他節(jié)點(diǎn)高。由此可以得出，shard分配不均衡導(dǎo)致存儲(chǔ)不均，在業(yè)務(wù)查詢或?qū)懭胫校鎯?chǔ)高的節(jié)點(diǎn)承擔(dān)主要的查詢和寫入。

3. 使用GET _cat/indices?v，查看索引信息。

   從結(jié)果可以看到索引的主shard數(shù)量為5，副shard數(shù)量為1。結(jié)合集群配置，發(fā)現(xiàn)存在節(jié)點(diǎn)shard分配不均的現(xiàn)象，其次集群中存在被刪除的文檔。ES在檢索過程中也會(huì)檢索.del文件，然后過濾標(biāo)記有.del的文檔，大大地降低檢索效率，耗費(fèi)規(guī)格資源，建議在業(yè)務(wù)低峰期進(jìn)行force merge。

   

4. 查看主日志及searching慢日志。

   從結(jié)果可以看到查詢請(qǐng)求都是普通的term查詢，且主日志正常，可以排除ES集群本身出現(xiàn)問題以及存在消耗CPU的查詢語句的情況。

總結(jié)

解決方案

在創(chuàng)建索引時(shí)，合理規(guī)劃shard，詳情請(qǐng)參見Shard評(píng)估建議。

建議在小規(guī)格節(jié)點(diǎn)下，單個(gè)shard大小不要超過30GB。對(duì)于更高規(guī)格的節(jié)點(diǎn)，單個(gè)shard大小不要超過50GB。

對(duì)于日志分析或者超大索引場(chǎng)景，建議單個(gè)shard大小不要超過100GB。

建議shard的個(gè)數(shù)（包括副本）要盡可能等于數(shù)據(jù)節(jié)點(diǎn)數(shù)，或者是數(shù)據(jù)節(jié)點(diǎn)數(shù)的整數(shù)倍。

建議單節(jié)點(diǎn)shard總數(shù)按照單節(jié)點(diǎn)內(nèi)存*30進(jìn)行評(píng)估，如果shard數(shù)量太多，極易引起文件句柄耗盡，導(dǎo)致集群故障。

建議單個(gè)節(jié)點(diǎn)上同一索引的shard個(gè)數(shù)不要超5個(gè)。

如果您使用了自動(dòng)創(chuàng)建索引功能，可通過設(shè)置場(chǎng)景模板，調(diào)整索引shard均衡，詳情請(qǐng)參見修改場(chǎng)景化配置模板。

場(chǎng)景

分析

1. 在查詢body中添加"profile": true。

   根據(jù)結(jié)果可以看到test索引的1號(hào)shard查詢時(shí)間比其他shard長(zhǎng)。

2. 查詢中分別指定preference=_primary和preference=_replica，body中添加"profile": true，分別查看主副shard查詢消耗的時(shí)間。

   根據(jù)結(jié)果定位出索引的1號(hào)shard耗時(shí)主要體現(xiàn)在主shard上，判斷和shard有關(guān)。

3. 使用GET _cat/segments/index?v&h=shard,segment,size,size.memory,ip及GET _cat/shards?v，查看索引的1號(hào)shard的信息。

   從結(jié)果可以看到索引的1號(hào)shard中存在比較大的segment，且doc數(shù)量比正常的副shard多。由此可以判斷負(fù)載不均與segment大小不均有關(guān)。

   說明

   造成主副shard的doc數(shù)量不一致的原因有很多，例如以下兩種情況：

   • 如果一直有doc寫入shard，由于主副數(shù)據(jù)同步有一定延遲，會(huì)導(dǎo)致數(shù)據(jù)不一致。但一般停止寫入后，主副doc數(shù)量是一致的。

   • 如果使用自動(dòng)生成docid的方式寫入doc，由于主shard寫入完成后會(huì)轉(zhuǎn)發(fā)請(qǐng)求到副shard，因此在此期間，如果執(zhí)行了刪除操作，例如并行發(fā)送Delete by Query請(qǐng)求刪除了主分片上剛寫完的doc，那么副shard也會(huì)執(zhí)行此刪除請(qǐng)求；然后主shard又轉(zhuǎn)發(fā)寫入請(qǐng)求到副shard上，對(duì)于自動(dòng)生成的id，doc將直接寫入副shard，不進(jìn)行檢查，最終導(dǎo)致主副shard的doc數(shù)量不一致，同時(shí)在doc.delete中也可以看到主shard中存在大量的刪除文檔。

解決方案（任選一種）

• 在業(yè)務(wù)低峰期進(jìn)行force merge，將緩存中的delete.doc徹底刪除，將小segment合并成大segment。

• 重啟主shard所在節(jié)點(diǎn)，觸發(fā)副shard升級(jí)為主shard。并且重新生成副shard，副shard復(fù)制新的主shard中的數(shù)據(jù)，保持主副shard的segment一致。

場(chǎng)景

分析

1. 觀察近4天兩區(qū)域節(jié)點(diǎn)的CPU監(jiān)控。

   根據(jù)結(jié)果可以看到兩區(qū)域節(jié)點(diǎn)CPU出現(xiàn)較大負(fù)載變動(dòng)。

2. 觀察節(jié)點(diǎn)TCP連接。

   根據(jù)結(jié)果可以看到兩個(gè)區(qū)域下的連接數(shù)相差很大。判定與網(wǎng)絡(luò)不均相關(guān)。

3. 排查客戶端的連接情況。

   客戶端使用長(zhǎng)連接，新建連接比較少，恰恰命中了多可用區(qū)網(wǎng)絡(luò)獨(dú)立調(diào)度的風(fēng)險(xiǎn)（網(wǎng)絡(luò)服務(wù)是基于連接數(shù)獨(dú)立調(diào)度的，每個(gè)調(diào)度單元會(huì)選擇自己認(rèn)為最優(yōu)的節(jié)點(diǎn)進(jìn)行創(chuàng)建，獨(dú)立調(diào)度的性能會(huì)更高，但獨(dú)立調(diào)度的風(fēng)險(xiǎn)是當(dāng)新連接比較少的時(shí)候，有一定概率出現(xiàn)大部分調(diào)度單元都選擇相同的節(jié)點(diǎn)去建立連接）。ES的協(xié)調(diào)節(jié)點(diǎn)對(duì)于請(qǐng)求的轉(zhuǎn)發(fā)是同區(qū)域優(yōu)先，即ES將請(qǐng)求轉(zhuǎn)到其他區(qū)域的可能性較小，這樣就導(dǎo)致當(dāng)前區(qū)域出現(xiàn)負(fù)載不均的問題。

解決方案（任選一種）

• 客戶端配置httpClientBuilder.setConnectionTimeToLive()。例如，配置連接有效時(shí)長(zhǎng)為5分鐘：httpClientBuilder.setConnectionTimeToLive(5, TimeUnit.MINUTES)。詳細(xì)信息，請(qǐng)參見HttpAsyncClientBuilder。

  說明

  客戶端配置鏈接有效時(shí)長(zhǎng)需要使用ES推薦的httpClientBuilder.setConnectionTimeToLive()，配置別的參數(shù)效果可能不太明顯，例如：httpClientBuilder.setKeepAliveStrategy()。

• 并發(fā)重啟客戶端，重新建立連接。

• 使用單獨(dú)的協(xié)調(diào)節(jié)點(diǎn)，通過工作職責(zé)劃分來降低風(fēng)險(xiǎn)。使用協(xié)調(diào)節(jié)點(diǎn)轉(zhuǎn)發(fā)復(fù)雜流量，即使負(fù)載高，也不會(huì)影響到后面的數(shù)據(jù)節(jié)點(diǎn)。

優(yōu)化后的負(fù)載監(jiān)控圖如下。