如何做好 Elasticsearch 性能指標監控

場景描述：本文是較早的一篇關於Elasticsearch性能指標監控的博文，內容總結全面，作者 Emily Chang，由楊文波同學翻譯。

關鍵詞：Elasticsearch 監控

一、Elasticsearch 核心概述

Elasticsearch是一個開源的分佈式文檔存儲和搜索引擎，可以實時存儲和檢索數據。它以結構化JSON文檔的形式表示數據，可以通過RESTful API或者多語言客戶端來訪問並做全文搜索。

 

1、Elasticsearch 簡要組成

在開始探索性能指標之前，讓我們來看看Elasticsearch的工作原理。在Elasticsearch中，羣集由一個或多個節點組成，如下所示：

 

每個節點是Elasticsearch的單一運行實例，其elasticsearch.yml配置文件指定它屬於哪個集羣（cluster.name）以及它可以是什麼類型的節點。配置文件中設置的任何屬性（包括集羣名稱）也可以通過命令行參數指定。上圖中的集羣由一個專用主節點和五個數據節點組成。

Elasticsearch中最常見的三種節點有：

• Master備選節點：默認情況下，除非另有說明，否則每個節點均爲master備選節點。每個集羣都會自動從所有主資源節點中選擇一個主節點。如果當前主節點遇到故障（例如停電，硬件故障或內存不足錯誤），則在符合資格的主節點間選舉出新的主節點。主節點負責協調集羣任務，如跨節點分發shards，以及創建和刪除索引。任何符合主要條件的節點也可以用作數據節點。然而，在較大的集羣中，用戶可能會啓動不存儲任何數據的專用主節點（通過添加）node.data: false到配置文件），以提高可靠性。在使用率高的場景下，將master role從data node上移開，可以幫助確保總是有足夠的資源分配給那些只能由master node處理的任務。（避免高負載的data node去處理master node的任務）

   

 

• 數據節點：默認情況下，每個節點都是數據節點，並且以分片（shards）的形式存儲數據並執行與索引，搜索和聚合數據相關的操作。在較大的集羣中，您可以選擇通過添加node.master: false配置文件來創建專用數據節點，確保這些節點具有足夠的資源來處理與數據相關的請求，而不需要承擔與集羣相關的管理任務的額外工作負載。

   

• 客戶端節點：如果設置node.master和node.data false，則該節點爲client node，其目的是作爲一個負載平衡器，可以幫助優化路徑索引和搜索請求。客戶端節點有助於承擔部分搜索工作負載，以便數據和主節點可以專注於其核心任務。根據用例，客戶機節點可能不是必需的，因爲數據節點能夠自己處理請求路由。但是，如果您的搜索/索引工作負載足夠重，以至於需要專用客戶機節點來幫助處理路由請求，那麼將客戶端節點添加到集羣就很有意義。

 

2、Elasticsearch 如何組織數據

在Elasticsearch中，相關數據通常存儲在相同的索引中，每個索引包含一組JSON格式的相關文檔。Elasticsearch的全文搜索祕訣是Lucene的倒排索引。索引文檔時，Elasticsearch會自動爲每個字段進行分詞，然後創建一個反向索引; 反向索引將分詞器分出來的詞（terms）映射到包含這些術語的文檔。

索引被存儲在一個或多個主分片，和零個或多個副本分片中，並且每個分片是一個完整的Lucene實例，就像一個迷你的搜索引擎。

 

創建索引時，可以指定主分片數，以及每個主分片的副本數。默認值爲每個索引五個主分片，每個主要數據爲一個副本。創建索引後，無法更改主碎片數量，因此請仔細選擇，否則您可能需要稍後重建索引。而副本數則可以根據需要稍後更新。爲了防止數據丟失，主節點確保每個副本分片不會與主分片分配在相同的節點上。

二、Elasticsearch 的關鍵性能指標

 

Elasticsearch提供了大量的指標，可以幫助您檢測到問題的跡象，並在遇到諸如不可靠節點，內存不足錯誤以及長時間垃圾收集時間等問題時採取行動。要監測的幾個關鍵領域是：

• 搜索和索引性能

• 內存和垃圾收集

• 主機級別的系統和網絡指標

• 集羣健康和節點可用性

• 資源飽和度和錯誤

 

本文引用了Monitoring 101系列的標準術語，它爲度量、收集和警報提供了一個框架。所有這些指標都可以通過Elasticsearch的API以及Elastic的Marvel和通用監控服務（如Datadog）等單一目的監控工具訪問。

1、搜索效果指標

搜索請求是Elasticsearch中的兩個主要請求類型之一（另一個是索引請求）。這些請求有時類似於傳統數據庫系統中的讀寫請求。Elasticsearch提供了與搜索過程的兩個主要階段（查詢和獲取）相對應的度量。下圖顯示了從開始到結束的搜索請求的路徑。

 

1. 客戶端向節點2發送搜索請求。

 

2. 節點2（協調節點）將查詢發送到索引中每個分片（主分片或副本）。

 

3. 每個接收到請求的分片本地執行查詢（每個分片都是一個lucene實例）並將結果傳遞給節點2，節點2將其排序並編譯成全局優先級隊列。

 

4. 節點2發現需要獲取哪些文檔，並向相關的分片發送多個GET請求。

 

5. 每個分片加載文檔並將其返回到節點2。

 

6. 節點2將搜索結果傳遞給客戶端。

 

如果您使用Elasticsearch主要用於搜索，或者如果搜索是面向客戶的主要功能，那麼，您應該監視查詢延遲並在超過閾值時採取行動。因此監視關於查詢和提取的相關指標，對於幫助您確定搜索性能隨時間的變化情況是很重要的。例如，您可能希望跟蹤查詢請求的尖峯和長期增長，以便您可以準備好調整配置以優化來獲得更好的性能和可靠性。

度量描述	名稱	公制型
查詢總數	indices.search.query_total	吞吐量
查詢總時間	indices.search.query_time_in_millis	性能
當前正在進行的查詢數量	indices.search.query_current	吞吐量
提取總數	indices.search.fetch_total	吞吐量
花費在提取上的總時間	indices.search.fetch_time_in_millis	性能
當前正在進行的提取數	indices.search.fetch_current	吞吐量

搜索性能指標的要點：

Query load：監視當前正在進行的查詢數量可以讓您瞭解羣集在任何特定時刻處理的請求數量，任何異常的尖峯或陡峭都可能指出潛在的問題。另外，您可能還想監視搜索線程池隊列的大小，稍後我們將在本文中進一步解釋。

Query latency：雖然Elasticsearch沒有明確提供此度量標準，但是監視工具可以幫助您使用可用的度量來計算平均查詢延遲，方法是以定期的時間間隔對總查詢次數和總經過時間進行抽樣。如果延遲超過閾值，請設置警報，如果觸發，請查找潛在的資源瓶頸，或調查是否需要優化查詢。

Fetch latency：搜索過程的第二部分，即提取階段通常比查詢階段花費的時間少得多。如果您注意到這一指標不斷增加，這可能是因爲緩慢的磁盤，文檔的額外加工（比如，高亮顯示搜索結果中的相關文本等）或請求太多結果。

2、索引性能指標

索引請求類似於傳統數據庫系統中的寫入請求。如果您的Elasticsearch工作量很重，那麼監控和分析elasticsearch更新索引的效率是非常重要的。在瞭解指標之前，讓我們來探索Elasticsearch更新索引的過程。當新信息添加到索引中或現有信息被更新或刪除時，索引中的每個分片將通過兩個進程進行更新：refresh(更新到內存中)和flush（更新到硬盤上）。

索引refresh

新索引的文檔不能立即被搜索到。首先，它們被寫入一個內存中的緩衝區，它們等待下一次索引刷新，默認情況下每秒刷新一次。刷新過程（使新索引的文檔可搜索）：從內存緩衝區（in-memory buffer）中創建新的內存段（segment），然後清空緩衝區，如下所示。

段（segment）的特殊細分

索引的分片（shard）由多個片段(segment)組成。segment是Lucene的核心數據結構，其本質上是一個用於存儲索引（index）增量的集合。這些段是在每次刷新時創建的，隨後隨後在後臺合併，以確保資源的有效使用（每個段實際上是以文件的形式存儲在磁盤上，使用文件句柄，內存和CPU）。

分段可以看作是將詞（terms）映射到包含這些術語的文檔的小型倒排索引。每次搜索索引時，必須搜索每個分片的primary或replica版本，依次搜索該分片中的每個片段(segment)。

分段是不可變的，因此更新文檔意味着：

• 在刷新過程中將信息寫入新的段

• 將舊信息標記爲已刪除

   

   

 

當過時的段與其他段合併時，舊信息最終被刪除。

索引flush

在將新建索引的文檔添加到內存緩衝區的同時，它們也會被寫入到分片的translog：一個持久化的，順序寫的，只能追加的事務日誌。每隔30分鐘，或者每當translog達到最大大小（默認爲512MB）時，將觸發flush。在flush期間，刷新內存緩衝區中的所有文檔（存儲在新的段中），然後將所有內存中的段都提交到磁盤，並且清除translog。

translog有助於防止節點發生故障時的數據丟失。它旨在幫助分片恢復在flush間隔之間可能已經丟失的數據。日誌每5秒提交一次磁盤或每次成功的索引，刪除，更新或批量請求（以先到者爲準）也會觸發提交。

Flush過程如下圖所示：

Elasticsearch提供了許多指標，可用於評估索引性能並優化更新索引的方式。

度量描述	名稱	公制型
索引的文件總數	indices.indexing.index_total	吞吐量
索引文檔總時間	indices.indexing.index_time_in_millis	性能
目前索引的文件數量	indices.indexing.index_current	吞吐量
索引刷新總數	indices.refresh.total	吞吐量
刷新指數的總時間	indices.refresh.total_time_in_millis	性能
索引刷新總數到磁盤	indices.flush.total	吞吐量
將索引刷新到磁盤上的總時間	indices.flush.total_time_in_millis	性能

索引要觀看的性能指標

索引延遲： Elasticsearch不會直接暴露此特定指標，但監控工具可以幫助您從可用index_total和index_time_in_millis指標計算平均索引延遲。如果您注意到延遲增加，您可能是一次嘗試索引太多的文檔了（Elasticsearch的官方文檔建議從5到15兆字節的批量索引大小開始，並從那裏緩慢增加）。

如果您計劃索引大量文檔，並且不需要立即可用於搜索的新信息，則可以通過減少刷新頻率來優化搜索性能的索引性能，直到完成索引。該指數設置API，您可以暫時禁用的刷新間隔：

 

1. curl -XPUT <nameofhost>:9200/<name_of_index>/_settings -d '{

2. "index" : {

3. "refresh_interval" : "-1"

4. }

5. }'

 

完成索引後，您可以恢復爲默認值“1s”。本系列的第4部分將對此和其他索引性能提示進行更詳細的說明。

Flush延遲：由於在刷新成功完成之前，數據不會立即持久化，因此如果性能開始下降，則可能會跟蹤flush延遲並採取措施。如果您看到該指標穩步增加，則意味着是磁盤較慢的問題; 此問題可能升級，最終導致您無法向索引添加新信息。您可以嘗試在flush的settings中降低index.translog.flush_threshold_size。此設置確定translog到達多大時會觸發flush。但是，如果你的Elasticsearch的寫操作很頻繁，你應該使用類似iostat或Datadog代理的工具，以保持緊密的對磁盤IO的指標的關注，必要時，考慮升級您的磁盤。

3、內存使用和垃圾回收

在運行Elasticsearch時，內存是您要密切監控的關鍵資源之一。Elasticsearch和Lucene以兩種方式利用節點上的所有可用RAM：JVM堆和文件系統緩存。Elasticsearch運行在Java虛擬機（JVM）中，這意味着JVM垃圾回收的持續時間和頻率將是其他重要的監視區域。

JVM堆：一個Goldilocks故事

Elasticsearch強調了JVM堆大小的重要性，這是相當“正確”的 - 您不希望將其設置得太大或太小，原因如下。一般來說，Elasticsearch的經驗法則是將少於50％的可用RAM分配給JVM堆，而不會超過32 GB。

您分配給Elasticsearch的堆內存越少，Lucene就可以使用更多的RAM，這很大程度上依賴於文件系統緩存來提供快速請求（文件系統會在RAM上申請緩存）。但是，您也不想將堆大小設置得太小，因爲這樣應用程序會面臨因頻繁垃圾回收的而不間斷暫停的問題，並且還可能會因此內存不足錯誤或吞吐量降低。請參閱本指南，由Elasticsearch的核心工程師之一撰寫，以查找確定正確堆大小的提示。

Elasticsearch的默認安裝設置的JVM堆大小爲1 GB，對於大多數用例來說，這是一個太小的堆棧。您可以將所需的堆大小導出爲環境變量並重新啓動Elasticsearch：

1. $ export ES_HEAP_SIZE=10g

 

另一個選項是在每次啓動Elasticsearch時，在命令行上設置JVM堆大小（具有相同的最小和最大大小以防止調整大小）

1. $ ES_HEAP_SIZE="10g" ./bin/elasticsearch

 

在這兩個示例中，我們將堆大小設置爲10 GB。要驗證您的更新是否成功，請運行：

1. $ curl -XGET http://<nameofhost>:9200/_cat/nodes?h=heap.max

輸出應顯示正確更新的最大堆值。

垃圾收集

Elasticsearch依靠垃圾收集過程來釋放堆內存。因爲垃圾收集也會消耗系統資源（爲了釋放資源！），您應該注意其頻率和持續時間，以查看是否需要調整堆大小。將堆設置得太大可能導致垃圾收集時間長; 這些過度的停頓是危險的，因爲它們可能導致您的羣集錯誤地將節點註冊爲已經掉線狀態。

度量描述	名稱	公制型
年輕代垃圾收集總數	jvm.gc.collectors.young.collection_count（jvm.gc.collectors.ParNew.collection_count在0.90.10之前）	其他
花費在年輕代垃圾收集上的總時間	jvm.gc.collectors.young.collection_time_in_millis（jvm.gc.collectors.ParNew.collection_time_in_millis在0.90.10之前）	其他
年老代垃圾收集總數	jvm.gc.collectors.old.collection_count（jvm.gc.collectors.ConcurrentMarkSweep.collection_count在0.90.10之前）	其他
花在年老代垃圾收集上的總時間	jvm.gc.collectors.old.collection_time_in_millis（jvm.gc.collectors.ConcurrentMarkSweep.collection_time_in_millis在0.90.10之前）	其他
當前正在使用的JVM堆的百分比	jvm.mem.heap_used_percent	資源：利用
配置的JVM堆的數量	jvm.mem.heap_committed_in_bytes	資源：利用

需要關注的JVM指標

 

正在使用的JVM堆：Elasticsearch被設置爲每當JVM堆使用率達到75％時，啓動垃圾收集。如上所示，它被用於監視哪些節點有高堆使用量，並設置一個警報，以確定是否有任何節點始終使用超過85％的堆內存; 這表明垃圾收集率跟不上垃圾的生產率。要解決這個問題，您可以增加堆大小（只要它低於上述建議的準則），或者通過添加更多節點來擴展集羣。（如果超過75%的使用率才做垃圾回收，在過大的堆內存時，每次垃圾回收的時間會很長；而過小的堆內存，則可能會造成頻繁的垃圾回收，並且回收速度趕不上生產速度，因此得在堆內存的大小上作一個權衡）

JVM堆使用與JVM堆大小的設置：與已設置的內存（保證可用的數量）相比，瞭解當前使用的JVM堆的大小是有幫助的。正在使用的堆內存量通常會垃圾累積時上升和在垃圾收集時下降。如果模式隨着時間的推移開始向上偏移，這意味着垃圾收集速度跟不上創建對象的速度，這可能導致垃圾收集時間慢，最終導致OutOfMemoryErrors。

垃圾收集時間和頻率：年輕代和年老代垃圾收集器都會經歷“stop the world”的階段，因爲此時JVM會停止執行程序以收集無用的對象。在此期間，節點無法完成任何任務。由於主節點每30秒檢查一次其他節點的狀態，如果任何節點的垃圾收集時間超過30秒，則會導致主節點相信節點發生故障。

內存使用情況

如上所述，Elasticsearch非常會利用任何尚未分配給JVM堆的RAM。像Kafka一樣，Elasticsearch被設計爲依靠操作系統的文件系統緩存來快速可靠地提供請求。

許多變量決定了Elasticsearch是否能成功讀取文件系統緩存。如果段文件最近被Elasticsearch寫入磁盤，那麼它已經在緩存中。但是，如果節點已被關閉並重新啓動，則首次查詢某個段時，該信息很可能必須從磁盤讀取。這就是是爲什麼您需要確保羣集保持穩定並且節點不會崩潰的重要原因之一。

一般來說，監視節點上的內存使用情況非常重要，同時給Elasticsearch儘可能多的RAM，這樣就可以利用文件系統緩存的速度，而不會耗盡空間。

4、主機級網絡和系統指標

名稱	公制型
可用磁盤空間	資源：利用
I / O利用率	資源：利用
CPU使用率	資源：利用
網絡字節發送/接收	資源：利用
打開文件描述符	資源：利用

雖然Elasticsearch通過API提供許多特定於應用程序的指標，但您也應該從每個節點收集和監控幾個主機級別的度量。

需要報警的系統指標

磁盤空間：如果您的Elasticsearch集羣是重寫入的，此度量特別重要。您不想耗盡磁盤空間，因爲這樣您將無法插入或更新任何內容，並且節點將失敗。如果節點上不到20％可用，則可能需要使用“ curator”等工具來刪除該節點上駐留的佔用太多有價值磁盤空間的某些索引。

如果刪除索引不是一個選項，另一個選擇是添加更多節點，並讓主節點自動重新分配新節點上的分片（儘管您應該注意到，這爲繁忙的主節點創建了額外的工作）。另外，請記住，具有分析字段的文檔（需要文本分析的字段，會執行標記化，分詞，刪除標點符號等操作）比具有未分析字段（精確值）的文檔佔用更多的磁盤空間。

需要監控的系統指標

I / O利用率：由於段的創建，查詢和合並，Elasticsearch對磁盤進行了大量寫入和讀取。對於具有不斷遇到重度I / O活動的節點的寫入繁重的羣集，Elasticsearch建議使用SSD來提升性能。

 

節點的CPU利用率：可以在每個節點類型的熱圖（如上所示）中可視化CPU使用情況。例如，您可以創建三個不同的圖表來表示集羣中的每組節點（例如，數據節點，主節點，客戶端節點），以查看是否有一種類型的節點與其他類型的節點相比較活動超載。如果看到CPU使用率增加，這通常是由於繁重的搜索或索引工作負載引起的。設置通知以確定節點的CPU使用率是否持續增加，如果需要，可以添加更多節點來重新分配負載。

發送/接收的網絡字節：節點之間的通信是平衡集羣的關鍵組件。您將需要監控網絡，以確保其健康，並滿足您對集羣的需求（例如，分段在節點之間複製或重新平衡）。Elasticsearch提供有關集羣通信的傳輸指標，但您也可以查看發送和接收的字節數，以查看網絡接收的流量。

打開文件描述符：文件描述符用於節點到節點的通信，客戶端連接和文件操作。如果此號碼達到您系統的最大容量，那麼新的連接和文件操作將不可能，直到舊的關閉。如果超過80％的可用文件描述符被使用，您可能需要增加系統的最大文件描述符數量。大多數Linux系統每個進程只允許1024個文件描述符。在生產中使用Elasticsearch時，您應該將操作系統文件描述符的數量重新設置得更大，如64,000。

HTTP連接

度量描述	名稱	公制型
當前打開的HTTP連接數	http.current_open	資源：利用
一段時間內打開的HTTP連接總數	http.total_opened	資源：利用

任何語言都可以給ES發送請求，但Java將使用RESTful API通過HTTP與Elasticsearch進行通信。如果打開的HTTP連接總數不斷增加，可能表示您的HTTP客戶端沒有正確建立持久連接。重新建立連接會在您的請求響應時間內增加額外的毫秒甚至幾秒鐘。確保您的客戶端配置正確，以避免對性能造成負面影響，或使用已正確配置HTTP連接的官方Elasticsearch客戶端。

5、集羣健康和節點可用性

度量描述	名稱	公制型
羣集狀態（綠色，黃色，紅色）	cluster.health.status	其他
節點數量	cluster.health.number_of_nodes	資源：可用性
正在初始化的分片數	cluster.health.initializing_shards	資源：可用性
未分配分片數	cluster.health.unassigned_shards	資源：可用性

集羣狀態：如果集羣狀態爲黃色，則至少有一個分片未創建副本或丟失。搜索結果仍將完成，但如果更多的碎片消失，您可能會丟失數據。

紅色集羣狀態指示至少一個主碎片丟失，並且你缺少數據，這意味着搜索將返回部分的結果。您也將被阻止索引到該分片。如果狀態爲黃色超過5分鐘，或者狀態在過去一分鐘爲紅色，請考慮設置一個提醒。

正在初始化和未分配的分片：當您首次創建索引或重新啓動節點時，其分片將在轉換到“啓動”或“未分配”狀態之前暫時處於“初始化”狀態，因爲主節點嘗試將分片分配給集羣中的節點。如果您看到分片仍處於正在初始化或未分配狀態太長時間，則可能是您的集羣不穩定的警告信號。

6、資源飽和度和錯誤

Elasticsearch節點使用線程池來管理線程如何消耗內存和CPU。由於線程池設置是根據處理器數量自動配置的，所以調整它們通常沒有意義。但是，最好關注隊列的添加和拒絕，以瞭解您的節點是否無法跟上; 如果是這樣，您可能需要添加更多節點來處理所有併發請求。Fielddata和過濾器高速緩存的使用是另一個要監控的領域，因爲緩存的eviction(從緩存中移除，比如根據RLU)可能指向低效的查詢或內存壓力的跡象。

線程池入隊和拒絕

每個節點維護許多類型的線程池; 您要監視的確切位置將取決於您對Elasticsearch的具體用途。一般來說，監控最重要的是搜索，索引，合併和bulk，它們與請求類型（搜索，索引，合併和批量操作）相對應。

每個線程池的隊列的大小表示節點當前處於可用等待服務的請求數。隊列允許節點跟蹤並最終服務這些請求，而不是丟棄它們。一旦線程池中的任務達到最大隊列大小，線程池將拒絕新的任務（根據線程池的類型而異）。

度量描述	名稱	公制型
線程池中的排隊線程數	thread_pool.bulk.queue thread_pool.index.queue thread_pool.search.queue thread_pool.merge.queue	資源：飽和度
線程池的被拒絕線程數	thread_pool.bulk.rejected thread_pool.index.rejected thread_pool.search.rejected thread_pool.merge.rejected	資源：錯誤

資源指標

線程池隊列：線程池不應設置過大，因爲它們佔用資源，並且如果節點關閉，還會增加丟失請求的風險。如果您看到排隊和拒絕的線程數量穩步增加，您可能希望嘗試減慢請求速率（如果可能），增加節點上的處理器數量或增加羣集中的節點數量。如下面的截圖所示，查詢負載峯值與搜索線程池隊列大小的峯值相關，因爲節點嘗試跟上查詢請求的速率。

 

批量拒絕和批量入隊：批量操作是一次發送許多請求的更有效的方式。通常，如果要執行許多操作（創建索引或添加，更新或刪除文檔），則應嘗試發送bulk請求，而不是許多單獨的請求。

批量拒絕（bulk rejection）通常與在一個bulk請求中嘗試索引太多文檔有關。根據Elasticsearch的文檔，批量拒絕不一定要擔心。但是，您應該嘗試實施線性或指數退避策略，以有效地處理批量拒絕。

緩存使用率指標

每個查詢請求都會被髮送到索引中的每個分片，然後再嘗試去命中分片上的段。Elasticsearch以每個段爲基礎來緩存查詢，以加快響應時間。另一方面，如果您的緩存過多地堆積在堆上，那麼它們可能會減慢速度，而不是加快速度！

在Elasticsearch中，文檔中的每個字段可以以兩種形式存儲：作爲精確值（keyword）或全文(text)。對於keyword，如時間戳或年份，會按照它的值原原本本的存儲。如果一個字段存儲爲全文(text)，這意味着它被分詞 - 基本上它被分解成令牌，並且根據分析器的類型，可以刪除標題符和停止詞如“是”或“該”。分析器將該字段轉換爲歸一化格式，使其能夠匹配更廣泛的查詢。

例如，假設你有一個索引包含一個類型location; 該類型的每個文檔都包含一個字段city，它被存儲爲一個分析的字符串。你索引兩個文件：一個在city中存儲“聖 路易斯“，另一個爲”聖 保羅”。每個字符串將被轉化爲小寫版本並轉換成標記，而不用標點符號。這些術語存儲在反向索引中，看起來像這樣：

術語	文檔1	文檔2
ST	X	X
路易斯	X
保羅		X

分析的好處是您可以搜索“st”，結果將顯示兩個文檔都包含該術語。如果您將該city字段存儲爲一個keyword，那麼您將不得不搜索確切的術語“聖 路易斯“或”聖 保羅“，以便看到結果文件。

 

Elasticsearch使用兩種主要類型的緩存來更快地提供搜索請求：fielddata和filter。

Fielddata緩存

在field上排序或聚合時使用fielddata緩存，這個過程基本上必須把倒排索引再倒置過來，以文檔順序爲每個field創建每個字段值的數組。例如，如果我們想在上述示例中找到任意包含詞（term）“st”的文檔中的唯一術語列表，我們將：

1. 掃描倒排索引以查看哪些文檔包含該術語（在本例中爲Doc1和Doc2）

2. 對於在步驟1中找到的每個文檔，通過索引中的每個術語從該文檔中收集令牌，創建如下所示的結構：

文件	Field（city）
文檔1	聖, 路易斯
文檔2	聖, 保羅

 

3. 現在，倒排索引已經被“反向”，從每個文檔（st，路易斯和保羅）中編譯出獨特的令牌。編譯這樣的fielddata可能會消耗大量堆內存，尤其是大量的文檔和術語。所有字段值都將加載到內存中。

對於1.3之前的版本，fielddata緩存大小是無限制的。從1.3版開始，Elasticsearch添加了一個fielddata斷路器，如果查詢嘗試加載將需要超過60％的堆的fielddata，則會觸發。

filter cache

filter cache也使用JVM堆。在2.0之前的版本中，Elasticsearch自動緩存過濾的查詢，最大值爲堆的10％，並且將最近最少使用的數據逐出。從版本2.0開始，Elasticsearch會根據頻率和段大小自動開始優化其過濾器緩存（緩存僅發生在索引中少於10,000個文檔或小於總文檔3％的段）。因此，過濾器緩存指標僅適用於使用2.0之前版本的Elasticsearch用戶。

例如，過濾器查詢可以僅返回year字段中的值在2000-2005範圍內的文檔。在首次執行過濾器查詢過程中，Elasticsearch將創建一個文檔與過濾器匹配的位組（如果文檔匹配則爲1，否則爲0）。使用相同過濾器後續執行查詢將重用此信息。無論何時添加或更新新文檔，也會更新位組。如果您在2.0之前使用Elasticsearch版本，那麼您應該關注過濾器緩存以及驅逐指標（更多關於以下內容）。

度量描述	名稱	公制型
fielddata緩存的大小（字節）	indices.fielddata.memory_size_in_bytes	資源：利用
來自fielddata緩存的驅逐次數	indices.fielddata.evictions	資源：飽和度
過濾器高速緩存的大小（字節）（僅版本2.x）	indices.filter_cache.memory_size_in_bytes	資源：利用
來自過濾器緩存的驅逐次數（僅版本2.x）	indices.filter_cache.evictions	資源：飽和度

要監視的緩存指標

 

Fielddata緩存驅逐：理想情況下，您希望限制fielddate cache的驅逐（eviction）的數量，因爲它們是I / O密集型的。如果您看到很多驅逐，而且目前無法增加內存，Elasticsearch建議臨時fielddate cache到堆的20%; 你可以在你的config/elasticsearch.yml文件中這樣做。當fielddata達到堆的20％時，它將驅逐最近最少使用的fielddata，然後允許您將新的fielddata加載到緩存中。

Elasticsearch還建議儘可能使用doc value，因爲它們與fielddata的用途相同。但是，由於它們存儲在磁盤上，它們不依賴於JVM堆。雖然doc值不能用於analyzed string fields，但是當在其他類型的字段上進行聚合或排序時，它們會保存fielddata的用法。在版本2.0和更高版本中，doc values在文檔索引期間自動構建，這減少了許多對fielddata/堆的使用。但是，如果您使用1.0和2.0之間的版本，還可以從此功能中受益 - 只需記住在索引中創建新字段時啓用它們。

Filter cache evictions：如前所述，filter cache驅逐指標僅在2.0版之前使用Elasticsearch版本時可用。每個段維護自己的單獨過濾器高速緩存。由於驅逐是在大的segment比在小segment上成本更高的操作，因此沒有明確的方法來評估每次驅逐的嚴重程度。但是，如果您看到越來越頻繁的eviction，這可能表明您沒有使用過濾器來獲得最大的利益 - 您可能正在不停的創建新的過濾器，並頻繁地排除舊的過濾器，從而打破了使用緩存的目的。您可能需要考慮調整您的查詢（例如，使用bool查詢而不是和/或/不過濾器）。

待處理任務

度量描述	名稱	公制型
待處理任務數	pending_task_total	資源：飽和度
掛起的緊急任務數量	pending_tasks_priority_urgent	資源：飽和度
待處理高優先級任務數	pending_tasks_priority_high	資源：飽和度

待處理的任務只能由主節點處理。這些任務包括創建索引並將分片分配給節點。待處理的任務按優先順序處理 - urgent先處理，然後是high。當操作的次數發生得比主節點處理更快時，它們開始累積。如果不斷增加，您需要關注這一指標。待處理任務的數量是您的羣集運行平穩的良好指示。如果您的主節點很忙，並且未完成的任務數量不會減少，則可能會導致不穩定的集羣。

不成功的GET請求

度量描述	名稱	公制型
丟失的文件的GET請求總數	indices.get.missing_total	工作：錯誤
花費在文檔丟失的GET請求上的總時間	indices.get.missing_time_in_millis	工作：錯誤

GET請求比正常的搜索請求更簡單 - 它根據其ID來檢索文檔。get-by-ID請求不成功意味着找不到文檔ID。你通常不應該對這種類型的請求有任何擔心，但是當發生GET請求失敗時，還是請注意一下。

三、總結

在這篇文章中，我們介紹了當升級和擴展Elasticsearch集羣時，需要監視的一些最重要的指標：

• 搜索和索引性能

• 內存和垃圾收集

• 主機級系統和網絡指標

• 集羣健康和節點可用性

• 資源飽和度和錯誤

 

按照本文所講述的內容進行Elasticsearch集羣監控，您將發現那些對於實際場景最有意義的指標。