最近一次在kibana上的跨index搜索後 elasticsearch其中一個node就不斷重啟 而每次reshard的時間也越來越長

最後發現問題原來出自kubernetes上 放es的節點上忘記把他taint了 結果其他POD也分配到上面運行 結果就造成了一個惡性循環 內存佔用太多導致OOM > POD重啟 >　ES節點重新加入到ES cluster > 重新分配shard > 內存佔用太多導致OOM 

雖然說是k8s的設定不當 但es上的確也有些設定問題需要改善

---

1. shard數量太多

首先由於這個ES是用來分析日誌，不同的service的index也不同，而index採用的是[env]-[service]-[YYYY-MM-DD]這個方式，結果每日產生的index數量就是大概 5 x 3 x 2(3個環境 dev/stag/prod，5個服務，每個index兩個shard)

解決方案

會用curator刪掉的index才用YYYY-MM-DD,　其他的用YYYY-MM就可以了，因為通常只查詢兩個月內的數據 而採用YYYY-MM的應該設定成shard: 5, replica: 1，方便負戴管理 也可以利用/index/close的指令來把很少用的index關掉，雖然說會額外增的硬碟容量… https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-open-close.html

2. master/data node 負載不均

因為省錢的關係只開了兩台AWS R4的node,，各自有一個master + data node 低負載環境下沒問題，但每當reschedule的時侯CPU就會衝到很高了

解決方案

多配兩台機來跑master 雖然文檔說master需求不大，但”不大”也只是相對起data node來說…

3. replica設定不當

shard:1 replica:1在只有兩個data node的時侯是相當雞肋的 而且這邊我也不肯定到底是不是hard affinity 有時重reschedule的時便總發現有少部份( ~50/20000)的unassigned_shards

解決方案

最少配置３台data node 而且用原本的配置shard:5 replica:1 但前提index的數量要少但容量要大 log型式的index還是用回shard:1 replica:1的配置

結論

elastic search裡面有很多很多設定 一開始的時侯資料量不大，不會引起太大問題 但當數量增加到某個量級的時侯就會開始造成一堆問題 理想當然是在開始設計架構的時侯就已經考慮到每種index的應用狀況 從而設定好shard/replica等的數量 否則上線之後才更改index或相關的設定可是相當危險的…