你不得不關(guān)注的 Elasticsearch Top X 關(guān)鍵指標(biāo)
0、題記
在寫繁重的業(yè)務(wù)場(chǎng)景下，你是否遇到過 Elasticsearch 集群的性能問題？ 你是否遇到過 Elasticsearch 數(shù)據(jù)索引化速度限制問題？ 你是否遇到過搜索花費(fèi)時(shí)間太長(zhǎng)而無法執(zhí)行的延遲問題？ 你是否遭遇過 Elasticsearch 集群故障排查的挑戰(zhàn)？ 你是否努力嘗試在零停機(jī)情況下提高 Elasticsearch 集群的穩(wěn)定性？ 你是否想過從監(jiān)控的角度去看Elasticsearch 關(guān)鍵指標(biāo)？
如果你對(duì)以上任何一個(gè)問題的回答為“是”，那么本文適合你。
我將介紹一些有關(guān)故障排除和解決 Elasticsearch 性能問題的經(jīng)驗(yàn)。
到本文結(jié)尾，你應(yīng)該對(duì)關(guān)鍵指標(biāo)有一個(gè)很好的了解，以便在你遇到Elasticsearch集群的性能或操作問題時(shí)進(jìn)行監(jiān)視。
那么，要監(jiān)視 Elasticsearch Top X 指標(biāo)是什么呢？本文揭曉答案。
1、集群配置
Elasticsearch 是一個(gè)分布式搜索引擎，可實(shí)現(xiàn)快速的數(shù)據(jù)索引化并具備良好的搜索性能。
開箱即用的 Elasticsearch 配置可以滿足N多業(yè)務(wù)場(chǎng)景。但是，如果你想獲得最佳性能，那么了解索引以及搜索要求并確保集群配置符合Elasticsearch最佳實(shí)踐至關(guān)重要。
Elasticsearch是按業(yè)務(wù)規(guī)模構(gòu)建的，具有最佳配置可確保更好的集群性能。Elasticsearch 集群可拆解為各種可度量的元素，可以將節(jié)點(diǎn)視為運(yùn)行 Elasticsearch 進(jìn)程的機(jī)器。索引本身可以被視為一個(gè)完整的搜索引擎，由一個(gè)或多個(gè)分片組成?？梢詫⒁粋€(gè)分片可視化為 Apache Lucene 的單個(gè)實(shí)例，該實(shí)例保存用于索引和搜索的文檔，并且這些文檔在各個(gè)分片之間均勻分布。
圖為：一個(gè)三節(jié)點(diǎn)集群，其索引分為六個(gè)分片
分片可以提高攝?。╥ngest）和搜索性能，但是分片過多也會(huì)降低速度。適當(dāng)?shù)姆制呗詫?duì)于集群至關(guān)重要。建議單個(gè)分片大小設(shè)置在 30-50 GB?之間。
分片數(shù)高于節(jié)點(diǎn)數(shù)可便于擴(kuò)展集群。但是分片的過度分配可能會(huì)減慢搜索操作，是因?yàn)樗阉魇紫仍?query 階段請(qǐng)求需要命中索引中的每個(gè)分片，然后執(zhí)行 fetch 階段獲取并匯聚結(jié)果。
如果你的分片僅容納了 5 GB數(shù)據(jù)，則可以認(rèn)為未充分利用。
咱們之前 N 多文章都提過，一個(gè)簡(jiǎn)單的查看集群整體健康狀態(tài)的 API 如下：
GET?_cluster/health
返回結(jié)果如下：
{
??"cluster_name"?:?"my-application",
??"status"?:?"yellow",
??"timed_out"?:?false,
??"number_of_nodes"?:?1,
??"number_of_data_nodes"?:?1,
??"active_primary_shards"?:?11,
??"active_shards"?:?11,
??"relocating_shards"?:?0,
??"initializing_shards"?:?0,
??"unassigned_shards"?:?5,
??"delayed_unassigned_shards"?:?0,
??"number_of_pending_tasks"?:?0,
??"number_of_in_flight_fetch"?:?0,
??"task_max_waiting_in_queue_millis"?:?0,
??"active_shards_percent_as_number"?:?68.75
}
開發(fā)人員經(jīng)常問到的一個(gè)問題是：“集群應(yīng)該配置的最佳分片數(shù)是多少？以使得整個(gè)集群性能最優(yōu)。”我要說的是，這個(gè)問題沒有一個(gè)千篇一律的答案。這取決于你的業(yè)務(wù)要求和你要滿足的SLA（網(wǎng)站服務(wù)可用性的保證）。
如下多項(xiàng)統(tǒng)計(jì)信息將幫助你做出正確的容量規(guī)劃決策，包含但不限于：
需要每秒索引的文檔數(shù) 單文檔大小 每秒查詢數(shù) 數(shù)據(jù)集的增長(zhǎng)模式
使用少量數(shù)據(jù)進(jìn)行基準(zhǔn)性能測(cè)試可以幫助你做出正確的決定（劃重點(diǎn)）。
強(qiáng)烈建議你了解您的數(shù)據(jù)和索引、搜索要求，以創(chuàng)建一個(gè)平衡且高效的集群。
2、總可用存儲(chǔ)空間大小
如果你的 Elasticsearch 集群節(jié)點(diǎn)的磁盤空間不足，則會(huì)影響集群性能。
一旦可用存儲(chǔ)空間低于特定閾值限制，它將開始阻止寫入操作，進(jìn)而影響數(shù)據(jù)進(jìn)入集群。
不少同學(xué)可能會(huì)遇到過如下的錯(cuò)誤：
ElasticsearchStatusException[Elasticsearch?exception?[type=cluster_block_exception,?reason=blocked?by:?[FORBIDDEN/12/index?read-only?/?allow
這就是磁盤快滿了做的保護(hù)機(jī)制提示。
再次強(qiáng)調(diào)一下，磁盤的三個(gè)默認(rèn)警戒水位線。
低警戒水位線
cluster.routing.allocation.disk.watermark.low?
默認(rèn)為磁盤容量的85％。Elasticsearch不會(huì)將新的分片分配給磁盤使用率超過85％的節(jié)點(diǎn)。它也可以設(shè)置為絕對(duì)字節(jié)值（如500mb），以防止 Elasticsearch 在小于指定的可用空間量時(shí)分配分片。此設(shè)置不會(huì)影響新創(chuàng)建的索引的主分片，特別是之前從未分配過的分片。
高警戒水位線
cluster.routing.allocation.disk.watermark.high?
默認(rèn)為磁盤容量的90％。Elasticsearch 將嘗試對(duì)磁盤使用率超過90％的節(jié)點(diǎn)重新分配分片（將當(dāng)前節(jié)點(diǎn)的數(shù)據(jù)轉(zhuǎn)移到其他節(jié)點(diǎn)）。它也可以設(shè)置為絕對(duì)字節(jié)值，以便在節(jié)點(diǎn)小于指定的可用空間量時(shí)將其從節(jié)點(diǎn)重新分配。此設(shè)置會(huì)影響所有分片的分配，無論先前是否分配。
洪水警戒水位線
cluster.routing.allocation.disk.watermark.flood_stage?
默認(rèn)為磁盤容量的95％。Elasticsearch對(duì)每個(gè)索引強(qiáng)制執(zhí)行只讀索引塊（index.blocks.read_only_allow_delete）。這是防止節(jié)點(diǎn)耗盡磁盤空間的最后手段。只讀模式待磁盤空間充裕后，需要人工解除。
因此，監(jiān)視集群中的可用存儲(chǔ)空間至關(guān)重要。
3、已刪除的文檔
Elasticsearch中的文檔無法修改，并且是不可變的（immutable）。Elasticsearch 執(zhí)行的刪除或更新文檔操作會(huì)先將文檔標(biāo)記為已刪除（邏輯刪除），不會(huì)立即將其從Elasticsearch中物理刪除。當(dāng)你繼續(xù)索引更多數(shù)據(jù)時(shí)，這些文檔將在后臺(tái)被清理。已邏輯刪除的文檔在搜索操作期間不可見，但是它們繼續(xù)占用磁盤空間。
如果磁盤空間成為瓶頸，則可以強(qiáng)制執(zhí)行段合并操作。段合并會(huì)實(shí)現(xiàn)小段合并為大段并清理已刪除的文檔。
POST?my_index/_forcemerge
如果通過 reindex 將文檔重新索引為新索引，則可以執(zhí)行刪除舊索引操作（delete index），刪除索引的方式會(huì)直接物理刪除掉文檔。
如果你的索引會(huì)定期更新，則待刪除的文檔數(shù)量會(huì)很多。
因此，最好在磁盤空間出現(xiàn)瓶頸問題前制定適當(dāng)?shù)牟呗詠砬謇硪堰壿媱h除的文檔。
4、主節(jié)點(diǎn)指標(biāo)
在生產(chǎn)環(huán)境中，建議你在Elasticsearch集群中配置專用的主節(jié)點(diǎn)。
主節(jié)點(diǎn)通過監(jiān)視集群管理活動(dòng)（例如：跟蹤集群中的所有節(jié)點(diǎn)、索引和分片）來提高集群的穩(wěn)定性。
主節(jié)點(diǎn)還監(jiān)視集群的運(yùn)行狀況，以確保數(shù)據(jù)節(jié)點(diǎn)不會(huì)過載，并使集群具有容錯(cuò)能力。
另一個(gè)建議是：針對(duì)集群規(guī)模大的場(chǎng)景，建議至少有三個(gè)主節(jié)點(diǎn)。這樣可確保在發(fā)生故障事件期間，必要的仲裁已到位，可以在集群中選擇新的主節(jié)點(diǎn)。
你可以通過查看主節(jié)點(diǎn)的CPU / 內(nèi)存利用率和 JVM 內(nèi)存使用百分比來確定主節(jié)點(diǎn)實(shí)例的配置。
以下是：cerebro 監(jiān)控 截圖。
一般來說，由于主節(jié)點(diǎn)專注于集群狀態(tài)，因此通常需要具有較低CPU /內(nèi)存資源的計(jì)算機(jī)。
5、數(shù)據(jù)節(jié)點(diǎn)指標(biāo)
數(shù)據(jù)節(jié)點(diǎn)托管 Elasticsearch 集群中包含索引文檔的分片。數(shù)據(jù)節(jié)點(diǎn)還執(zhí)行搜索和聚合有關(guān)的所有數(shù)據(jù)操作，并處理客戶端請(qǐng)求。
與主節(jié)點(diǎn)相比，數(shù)據(jù)節(jié)點(diǎn)需要具有較高CPU / 內(nèi)存資源的服務(wù)器。
如果你的集群沒有專用的主節(jié)點(diǎn)，則其中一個(gè)數(shù)據(jù)節(jié)點(diǎn)將開始充當(dāng)主節(jié)點(diǎn)。這會(huì)在集群中造成CPU和JVM使用的不平衡。
文檔增、刪、改、查操作和搜索操作占用大量CPU和IO，因此監(jiān)視數(shù)據(jù)節(jié)點(diǎn)利用率指標(biāo)很重要。
從CPU /內(nèi)存的角度來看，您應(yīng)確保數(shù)據(jù)節(jié)點(diǎn)平衡且不會(huì)過載。
6、數(shù)據(jù)寫入性能指標(biāo)
如果您試圖將大量文檔寫入 Elasticsearch 中，則可以監(jiān)視數(shù)據(jù)寫入延遲和數(shù)據(jù)索引化速率指標(biāo)，以驗(yàn)證索引吞吐量是否滿足企業(yè)的需求。
有幾種方法可以提高數(shù)據(jù)寫入速度。可概括為如下四項(xiàng)措施：
6.1 bulk 批量操作或者多線程寫入
利用 Elasticsearch 提供的批量API（bulk）來同時(shí)索引一批文檔。還可以使用多線程寫入 Elasticsearch 以最大化利用所有集群資源。
請(qǐng)注意，文檔大小和集群配置可能會(huì)影響數(shù)據(jù)寫入速度。為了找到集群的最佳吞吐量，你需要運(yùn)行性能測(cè)試并嘗試使用不同的批處理大小和并發(fā)線程值大小。
6.2 合理調(diào)整刷新頻率
Elasticsearch refresh 刷新操作是使文檔可搜索的過程。
默認(rèn)情況下，每秒刷新一次。如果主要目標(biāo)是調(diào)整攝取速度的索引，則可以將 Elasticsearch 的默認(rèn)刷新間隔從1秒更改為30秒。30秒后，這將使文檔可見以供搜索，從而優(yōu)化索引速度。
更新指定索引的刷新頻率，實(shí)現(xiàn)如下：
PUT?my_index/_settings
{
??"index":?{
????"refresh_interval":?"30s"
??}
}
在寫入繁重的業(yè)務(wù)場(chǎng)景或索引速度比搜索性能更關(guān)鍵的業(yè)務(wù)場(chǎng)景下，這可能是一個(gè)很好的實(shí)踐。
6.3 寫入前后動(dòng)態(tài)調(diào)整副本大小
副本能提升集群的高可用并且作為主分片數(shù)據(jù)的備份能一定程度防止數(shù)據(jù)丟失，但帶來了相應(yīng)的成本。
在初始數(shù)據(jù)加載期間，你可以禁用副本以實(shí)現(xiàn)較高的索引寫入速度。
PUT?my_index/_settings
{
??"index":?{
????"number_of_replicas":?0
??}
}
為保證集群高可用，一旦完成初始加載，就可以重新啟用副本。
6.4 合理的數(shù)據(jù)建模
不要索引業(yè)務(wù)層面不需搜索的字段。可通過不索引冗余字段來節(jié)省存儲(chǔ)空間（舉例：設(shè)置 index:false）。
如下示例，可以將 cont 字段的 index 屬性值設(shè)置為 false，這樣，cont 字段將不會(huì)被搜索。
PUT?blog_index
{
??"mappings":?{
????"properties":?{
??????"cont":?{
????????"type":?"text",
????????"index":?false
??????}
????}
??}
}
如果執(zhí)意要檢索 cont 字段上的數(shù)據(jù)，會(huì)報(bào)錯(cuò)并返回如下內(nèi)容：
??"reason":?"Cannot?search?on?field?[cont]?since?it?is?not?indexed."
一圖勝千言，建模的時(shí)候仔細(xì)過一遍如下這張圖。
因此，強(qiáng)烈建議你根據(jù)實(shí)際業(yè)務(wù)場(chǎng)景，以最小化存儲(chǔ)、最大化集群寫入和搜索性能為前提對(duì)數(shù)據(jù)進(jìn)行合理的建模、合理的設(shè)置 Mapping 中的各個(gè)字段的類型。
推薦：
論Elasticsearch數(shù)據(jù)建模的重要性
Elasticsearch 內(nèi)部數(shù)據(jù)結(jié)構(gòu)深度解讀
7、數(shù)據(jù)搜索性能指標(biāo)
Elasticsearch 中的搜索請(qǐng)求將發(fā)送到索引中的所有分片（主分片或副本分片）。然后，接收到該請(qǐng)求的節(jié)點(diǎn)將匯集所有分片的結(jié)果，并將結(jié)果返回給調(diào)用的應(yīng)用程序。
分片會(huì)消耗 CPU / 內(nèi)存資源。因此，如果分片過多，則可能降低查詢性能。
如果集群的更新操作頻繁，則可能會(huì)影響搜索 SLA。通過適當(dāng)?shù)嘏渲煤退綌U(kuò)展集群，可以提升數(shù)據(jù)寫入和集群檢索性能。
7.1 使用過濾限定返回文檔數(shù)量
根據(jù)我搜索性能調(diào)優(yōu)的經(jīng)驗(yàn)，強(qiáng)烈建議你通過添加適當(dāng)?shù)倪^濾器（filters）來限制從搜索查詢中返回的文檔數(shù)量。應(yīng)用過濾器后，僅針對(duì)有限的一組文檔計(jì)算分?jǐn)?shù)，這將提高查詢性能。
你還應(yīng)該監(jiān)視搜索延遲和搜索速率指標(biāo)，以調(diào)查與搜索功能相關(guān)的性能問題。
這里說的核心是：不要?jiǎng)硬粍?dòng)就返回全量數(shù)據(jù)，而是發(fā)揮倒排索引和搜索的優(yōu)勢(shì)，根據(jù)業(yè)務(wù)場(chǎng)景最小化返回滿足給定條件的數(shù)據(jù)。
7.2 啟用慢查詢?nèi)罩?/span>
建議你在 Elasticsearch 集群中啟用慢速查詢?nèi)罩?，以解決性能問題并捕獲運(yùn)行時(shí)間較長(zhǎng)或超過設(shè)置閾值的查詢。
例如，如果您的搜索SLA為 2 秒，則可以按以下方式配置搜索查詢，超過該閾值的任何查詢都將被記錄。
PUT?my_index/_settings
{
????"index.search.slowlog.threshold.query.warn"?:?"2s"
}
8、小結(jié)
在本文中，介紹了一些從搜索和索引角度優(yōu)化 Elasticsearch 性能的最關(guān)鍵的指標(biāo)?？偨Y(jié)一下，關(guān)鍵要點(diǎn)如下：
集群中具有專用的主節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)，以確保最佳的集群性能。 通過在集群中添加數(shù)據(jù)節(jié)點(diǎn)并增加副本分片數(shù)量來提升集群的高可用性。 搜索查詢必須命中每個(gè)分片（主分片或者副本分片），因此分片過多會(huì)使搜索變慢。 慢查詢和索引日志可用來解決搜索和索引性能問題。 確保你的Elasticsearch集群在分片、數(shù)據(jù)節(jié)點(diǎn)和主節(jié)點(diǎn)的數(shù)量上合理性和正確性。 通過利用批量請(qǐng)求、使用多線程寫入并水平擴(kuò)展集群來優(yōu)化 Elasticsearch 索引性能。
注：這是一篇翻譯文章，原文地址：
https://iamondemand.com/blog/top-5-elasticsearch-metrics-to-monitor/?
我結(jié)合業(yè)務(wù)實(shí)踐進(jìn)行了擴(kuò)充和完善。
推薦閱讀
更短時(shí)間更快習(xí)得更多干貨！
中國?40%+?Elastic 認(rèn)證工程師出自于此！
和全球 800+?Elastic 愛好者一起死磕 Elasticsearch！