淺談某運(yùn)維平臺(tái)ES優(yōu)化之路

IT那活兒發(fā)布于2023-01-11 13:19 / 3368人閱讀

點(diǎn)擊上方“IT那活兒”公眾號(hào)，關(guān)注后了解更多內(nèi)容，不管IT什么活兒，干就完了！！！

近期的某一天凌晨三點(diǎn)我收到一條ES異常告警，登錄環(huán)境發(fā)現(xiàn)ES節(jié)點(diǎn)數(shù)在正常和異常間反復(fù)橫跳，查看日志發(fā)現(xiàn)數(shù)據(jù)節(jié)點(diǎn)與master節(jié)點(diǎn)通信異常，出現(xiàn)數(shù)據(jù)節(jié)點(diǎn)頻繁上下線的情況，ES集群壓力山大，處理恢復(fù)后續(xù)又多次出現(xiàn)了該問(wèn)題，ES優(yōu)化刻不容緩，以下我就此分享下ES的優(yōu)化方案。

優(yōu)化方案

1. 索引分片數(shù)優(yōu)化

首先我們先看一下ES集群的整體情況，ES共24個(gè)節(jié)點(diǎn)，其中6個(gè)master節(jié)點(diǎn)，18個(gè)data節(jié)點(diǎn)，數(shù)據(jù)量11.9TB，但是索引數(shù)達(dá)到了12817，分片數(shù)量達(dá)到了53617，了解ES的同學(xué)肯定知道，這樣的分片數(shù)肯定是遠(yuǎn)超了官方建議的。

我們先看看為什么會(huì)有這么多索引和分片數(shù)，索引設(shè)置是否合理。

以索引domp_10000_zhuji-messages為例，可見(jiàn)索引分片數(shù)為1，副本數(shù)為1，數(shù)據(jù)量最大的不過(guò)10M，一般來(lái)說(shuō)日志類的索引一個(gè)分片可以承載30G左右的數(shù)據(jù)，可見(jiàn)domp_10000_zhuji-messages這樣數(shù)據(jù)量的索引完全沒(méi)有必要做日索引。

與應(yīng)用溝通得知索引domp_10000_zhuji-messages保留周期為90天，意味著domp_10000_zhuji-messages索引就能占180個(gè)分片，如果我們將其改造為月索引，單個(gè)索引數(shù)據(jù)量預(yù)估在300M左右，一個(gè)分片也是完全夠用，那么此時(shí)在保留周期內(nèi)我們只需要6個(gè)分片就可以滿足需求，分片數(shù)量直接減少了30倍。

應(yīng)用到整個(gè)集群，索引數(shù)和分片數(shù)量將大幅度的減少，從而可減輕ES集群不小的壓力。

2. 減少監(jiān)控采集頻率

查看日志會(huì)發(fā)現(xiàn)ES監(jiān)控索引數(shù)據(jù)寫(xiě)入被拒絕，監(jiān)控這塊的寫(xiě)入比較大。

查看監(jiān)控索引大小，居然能達(dá)到40G以上，這對(duì)ES的壓力可想而知還是比較大的。

ES默認(rèn)的采集頻率為10S，我們將調(diào)整采集頻率調(diào)整為60S，減少監(jiān)控對(duì)ES產(chǎn)生的壓力。

curl  -u elastic:elastic -H Content-Type: application/json -XPUT 
http://XXX.XXX.XXX.101:9206/_cluster/settings  -d {"persistent": {"xpack.monitoring.collection.interval":"60s"}}

ES在7.0后需要在kibana.yml配置文件中加入xpack.monitoring.min_interval_seconds參數(shù)，需與ES集群配置的采集頻率相同，加了之后可別忘了重啟kibana。

必要的話也可以放棄對(duì)索引的監(jiān)控，只收集集群元數(shù)據(jù)，調(diào)整參數(shù)xpack.monitoring.collection.indices":".*"，指定需要監(jiān)控的索引，默認(rèn)是監(jiān)控所有索引。

查詢優(yōu)化

ES集群壓力如此之大，當(dāng)時(shí)在跑什么查詢？

我們可以通過(guò)查看慢查詢?nèi)罩荆榭串?dāng)時(shí)的查詢情況。

/*
慢查詢?nèi)罩咎砑臃绞?時(shí)間級(jí)別可根據(jù)實(shí)際情況而定。
PUT _all/_settings {
"index.indexing.slowlog.threshold.index.warn": "10s",
"index.indexing.slowlog.threshold.index.info": "5s",
"index.indexing.slowlog.threshold.index.debug": "2s",
"index.indexing.slowlog.threshold.index.trace": "500ms",
"index.indexing.slowlog.level": "info",
"index.indexing.slowlog.source": "true"
}
**/

通過(guò)慢日志，我們可以發(fā)現(xiàn)當(dāng)時(shí)主要語(yǔ)句為:

以上查詢使用用了ES中的in查詢，in中id數(shù)量遠(yuǎn)超1024，默認(rèn)情況下參數(shù)indices.query.bool.max_clause_count值為1024，此參數(shù)限制大查詢占用過(guò)多的CPU和內(nèi)存，此查詢遠(yuǎn)超此限制將占用大量的CPU和內(nèi)存資源。

整改方法：采用循環(huán)查詢，一次取100個(gè)id的數(shù)據(jù)，經(jīng)測(cè)試查詢總耗時(shí)與原方法無(wú)較大差異，資源消耗卻大大減少。

并且針對(duì)大索引的查詢，應(yīng)用程序之前是使用from-size，from-size的工作原理是：如size=10&from=100，那么ElasticSearch會(huì)從每個(gè)Shard里取出100條數(shù)據(jù)，然后再排序，取出前10條。

由此觀之，當(dāng)索引非常大時(shí)，from-size查詢對(duì)集群的壓力會(huì)特別高，相對(duì)于from和size的分頁(yè)來(lái)說(shuō)，使用scroll可以模擬一個(gè)傳統(tǒng)數(shù)據(jù)的游標(biāo)，記錄當(dāng)前讀取的文檔信息位置。所以scroll查詢能大大降低集群的壓力。