Elasticsearch 之 監控Elasticsearch性能

時間  2021-01-09 標籤 Elasticsearch 性能指標 segments 集羣

     
  本文翻譯原文地址：https://www.datadoghq.com/blog/monitor-elasticsearch-performance-metrics/


      本文是關於監控Elasticsearch性能的4部分系列文章的第1部分。 在這篇文章中，我們將介紹Elasticsearch的工作原理，並探索您應該監控的關鍵指標。 第2部分介紹瞭如何收集Elasticsearch性能指標，第3部分介紹瞭如何使用Datadog監控Elasticsearch，第4部分討論瞭如何解決5個常見的Elasticsearch問題。

什麼是Elasticsearch？

      Elasticsearch是一個開源的分佈式文檔存儲和搜索引擎，可以近乎實時地存儲和檢索數據結構。 由Shay Banon開發並於2010年發佈，它在很大程度上依賴於Apache Lucene，這是一個用Java編寫的全文搜索引擎。
      Elasticsearch以結構化JSON文檔的形式表示數據，並通過RESTful API和Web客戶端訪問PHP，Python和Ruby等語言的全文搜索。 它也具有彈性，因爲它易於水平擴展 - 只需添加更多節點即可分配負載。 如今，許多公司，包括維基百科，eBay，GitHub和Datadog，都使用它來存儲，搜索和分析大量數據。

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

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

Elasticsearch中三種最常見的節點類型是：

      符合主節點的節點：默認情況下，除非另有說明，否則每個節點都符合主節點。每個集羣自動從所有符合主節點的節點中選擇一個主節點。如果當前主節點出現故障（例如斷電，硬件故障或內存不足錯誤），則符合主節點的節點會選擇新的主節點。主節點負責協調集羣任務，例如跨節點分發分片，以及創建和刪除索引。任何符合主節點的節點也可以用作數據節點。但是，在較大的羣集中，用戶可以啓動不存儲任何數據的專用主節點（通過將node.data：false添加到配置文件中），以提高可靠性。在高使用率環境中，將主角色從數據節點移開有助於確保始終有足夠的資源分配給只有符合主節點的節點才能處理的任務。

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

      客戶端節點：如果將node.master和node.data設置爲false，則最終會得到一個客戶端節點，該節點旨在充當負載均衡器，以幫助路由索引和搜索請求。客戶端節點有助於承擔一些搜索工作負載，以便數據和符合條件的節點可以專注於其核心任務。根據您的使用情況，客戶端節點可能不是必需的，因爲數據節點能夠自己處理請求路由。但是，如果您的搜索/索引工作負載足夠大，可以通過使用專用客戶端節點來幫助路由請求，那麼將客戶端節點添加到羣集是有意義的。

Elasticsearch如何組織數據
      在Elasticsearch中，相關數據通常存儲在同一索引中，可以將其視爲配置邏輯包裝的等價物。 每個索引都包含一組JSON格式的相關文檔。 Elasticsearch對全文搜索的祕訣是Lucene的倒排索引。 索引文檔時，Elasticsearch會自動爲每個字段創建倒排索引; 倒排索引將術語映射到包含這些術語的文檔。

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

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

 

要監控的關鍵Elasticsearch性能指標

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

  1. 搜索和索引性能
  2. 內存和垃圾收集
  3. 主機級系統和網絡指標
  4. 羣集運行狀況和節點可用性
  5. 資源飽和和錯誤
     

本文引用了Monitoring 101系列中的度量標準術語，該系列提供了度量標準收集和警報的框架。

這裏提供了一個metric蒐集和監控的框架 Monitoring 101 series 

所有這些指標都可以通過Elasticsearch的API以及Elastic的Marvel和Datadog等通用監控服務等單一用途監控工具訪問。 有關如何使用所有這些方法收集這些指標的詳細信息，請參閱本系列的第2部分。

搜索性能指標

     搜索請求是Elasticsearch中的兩個主要請求類型之一，以及索引請求。 這些請求在某種程度上類似於傳統數據庫系統中的讀取和寫入請求。 Elasticsearch提供與搜索過程的兩個主要階段（查詢和獲取）相對應的度量標準。 下圖說明了從頭到尾的搜索請求的路徑。


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

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

3.每個分片在本地執行查詢並將結果傳遞給節點2.節點2將它們排序並編譯成全局優先級隊列。

 

4.節點2找出需要提取的文檔，並向相關分片發送多GET請求。

 

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

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


如果您主要使用Elasticsearch進行搜索，或者搜索是面向客戶的功能，這對您的組織至關重要，則應監視查詢延遲並在超過閾值時採取措施。 監控有關查詢和提取的相關指標非常重要，這些指標可以幫助您確定搜索在一段時間內的執行情況。 例如，您可能希望跟蹤查詢請求中的峯值和長期增長，以便您可以準備調整配置以優化以獲得更好的性能和可靠性。

Metric description Name [Metric type][monitoring-101-blog]
Total number of queries indices.search.query_total Work: Throughput
Total time spent on queries indices.search.query_time_in_millis Work: Performance
Number of queries currently in progress indices.search.query_current Work: Throughput
Total number of fetches indices.search.fetch_total Work: Throughput
Total time spent on fetches indices.search.fetch_time_in_millis Work: Performance
Number of fetches currently in progress indices.search.fetch_current Work: Throughput

要搜索的搜索效果指標
      查詢負載（Query load）：監控當前正在進行的查詢數量可以讓您大致瞭解您的集羣在任何特定時刻處理的請求數量。考慮警告可能指向潛在問題的異常尖峯或驟降。您可能還想監視搜索線程池隊列的大小，我們將在本文後面進一步詳細說明。

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

      獲取延遲（Fetch latency）：搜索過程的第二部分（獲取階段）通常比查詢階段花費的時間少得多。如果您注意到此指標持續增加，則可能表示磁盤速度慢，文檔豐富（突出顯示搜索結果中的相關文本等）或請求過多結果。

索引性能指標
      索引請求類似於傳統數據庫系統中的寫入請求。如果您的Elasticsearch工作負載是大量寫入的，那麼監控和分析您能夠使用新信息更新索引的效率非常重要。在我們開始使用指標之前，讓我們來探索Elasticsearch更新索引的過程。將新信息添加到索引或更新或刪除現有信息時，索引中的每個分片都會通過兩個進程更新：刷新和刷新。

索引刷新
     首先，它們被寫入一個內存中的緩衝區（in-memory buffer），等待下一次索引刷新，默認情況下每秒一次。刷新是以in-memory buffer爲基礎創建in-memory segment的過程（The refresh process creates a new in-memory segment from the contents of the in-memory buffer ）。這樣索引進的文檔才能是可被搜索的，創建完segment後，清空buffer

A special segment on segments
索引由shards構成，shard又由很多segments組成，The core data structure from Lucene, a segment is essentially a change set for the index. 這些segments在每次刷新的時候被創建，隨後會在後臺進行合併，以確保資源的高效利用（每個segment都要佔file handles、memory、CPU）

segments 是mini的倒排索引，這些倒排索引映射了terms到documents。每當搜索索引的時候，每個主副shards都必須被遍歷。更深一步說shards上的每個segment會被依次搜索。

segment是不可變的，因此updating a document 意味着如下：

  • writing the information to a new segment during the refresh process
  • marking the old information as deleted

當多個outdated segment合併後纔會被刪除。（意思是不單個刪除，合併後一起刪）。

索引刷新（Index flush）
在將新索引文檔添加到內存緩衝區的同時，它們也會附加到分片的translog：操作的持久，預寫事務事務日誌。 每隔30分鐘，或者當translog達到最大大小（默認爲512MB）時，將觸發刷新。 在刷新期間，內存緩衝區中的任何文檔都會刷新（存儲在新段中），所有內存中的段都將提交到磁盤，並且會清除translog。

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

沖洗過程如下所示：

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

Metric description Name [Metric type][monitoring-101-blog]
Total number of documents indexed indices.indexing.index_total Work: Throughput
Total time spent indexing documents indices.indexing.index_time_in_millis Work: Performance
Number of documents currently being indexed indices.indexing.index_current Work: Throughput
Total number of index refreshes indices.refresh.total Work: Throughput
Total time spent refreshing indices indices.refresh.total_time_in_millis Work: Performance
Total number of index flushes to disk indices.flush.total Work: Throughput
Total time spent on flushing indices to disk indices.flush.total_time_in_millis Work: Performance

索引性能指標的要點：

  • Indexing latency： Elasticsearch不會直接公開此特定指標，但是監控工具可以幫助您從可用的index_total和index_time_in_millis指標計算平均索引延遲。 如果您注意到延遲增加，您可能會一次嘗試索引太多的文檔（Elasticsearch的文檔建議從5到15兆字節的批量索引大小開始，並緩慢增加）。 
    如果您計劃索引大量文檔，並且不需要立即可用於搜索。則可以通過減少刷新頻率來優化。索引設置API使您能夠暫時禁用刷新間隔：

    curl -XPUT <nameofhost>:9200/<name_of_index>/_settings -d '{
 "index" : {
 "refresh_interval" : "-1"
 } 
}'
    • 1
    • 2
    • 3
    • 4
    • 5

    完成索引後，您可以恢復爲默認值「1s」

  • Flush latency: 在flush完成之前，數據不會被固化到磁盤中。因此追蹤flush latency很有用。比如我們看到這個指標穩步增長，表明磁盤性能不好。這個問題將最終導致無法向索引添加新的數據。 
    可以嘗試降低index.translog.flush_threshold_size。這個設置決定translog的最大值（在flush被觸發前）

3、內存使用和GC指標

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

JVM heap: A Goldilocks tale 
Elasticsearch強調了JVM堆大小的重要性，這是「正確的」 - 不要將其設置太大或太小，原因如下所述。 一般來說，Elasticsearch的經驗法則是將少於50％的可用RAM分配給JVM堆，而不會超過32 GB。

您分配給Elasticsearch的堆內存越少，Lucene就可以使用更多的RAM，這很大程度上依賴於文件系統緩存來快速提供請求。 但是，您也不想將堆大小設置得太小，因爲應用程序面臨來自頻繁GC的不間斷暫停，可能會遇到內存不足錯誤或吞吐量降低的問題

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

export ES_HEAP_SIZE=10g

如上我們設置了es heap大小爲10G，通過如下命令進行校驗：

curl -XGET http://:9200/_cat/nodes?h=heap.max

Garbage collection 
Elasticsearch依靠垃圾收集過程來釋放heap memory。因爲垃圾收集使用資源（爲了釋放資源！），您應該注意其頻率和持續時間，以查看是否需要調整heap大小。設置過大的heap會導致GC時間過長，這些長時間的停頓會讓集羣錯誤的認爲該節點已經脫離。

Metric description Name [Metric type][monitoring-101-blog]
Total count of young-generation garbage collections jvm.gc.collectors.young.collection_count(jvm.gc.collectors.ParNew.collection_count prior to vers. 0.90.10) Other
Total time spent on young-generation garbage collections jvm.gc.collectors.young.collection_time_in_millis(jvm.gc.collectors.ParNew.collection_time_in_millis prior to vers. 0.90.10) Other
Total count of old-generation garbage collections jvm.gc.collectors.old.collection_count(jvm.gc.collectors.ConcurrentMarkSweep.collection_count prior to vers. 0.90.10) Other
Total time spent on old-generation garbage collections jvm.gc.collectors.old.collection_time_in_millis(jvm.gc.collectors.ConcurrentMarkSweep.collection_time_in_millis for versions prior to 0.90.10) Other
Percent of JVM heap currently in use jvm.mem.heap_used_percent Resource: Utilization
Amount of JVM heap committed jvm.mem.heap_committed_in_bytes Resource: Utilization

JVM指標的要點：

這裏寫圖片描述

  • JVM heap in use: 當JVM heap 使用率達到75％時，es啓動GC。如上圖所示，可以監控node的JVM heap，並且設置一個警報，確認哪個節點是否一直超過%85。如果一直超過，則表明垃圾的收集已經跟不上垃圾的產生。此時可以通過增加heap（需要滿足建議法則不超過32G），或者通過增加節點來擴展集羣，分散壓力。

  • JVM heap used vs. JVM heap committed: 與commit的內存（保證可用的數量）相比，瞭解當前正在使用多少JVM heap的情況可能會有所幫助。heap memory的圖一般是個鋸齒圖，在垃圾收集的時候heap上升，當收集完成後heap下降。如果這個鋸齒圖向上偏移，說明垃圾的收集速度低於rate of object creation，這可能會導致GC時間放緩，最終OutOfMemoryErrors。

  • Garbage collection duration and frequency: Both young- and old-generation garbage collectors undergo 「stop the world」 phases, as the JVM halts execution of the program to collect dead objects。在此期間節點cannot complete any task。主節點每30秒會去檢查其他節點的狀態，如果任何節點的垃圾回收時間超過30秒，則會導致主節點任務該節點脫離集羣。

  • Memory usage: 如上所述，es非常會利用除了分配給JVM heap的任何RAM。像Kafka一樣，es被設計爲依賴操作系統的文件系統緩存來快速可靠地提供請求。 
    許多變量決定了Elasticsearch是否成功讀取文件系統緩存，如果segment file最近由es寫入到磁盤，它已經in the cache。然而如果節點被關閉並重新啓動，首次查詢某個segment的時候，數據很可能是必須從磁盤中讀取，這是確保您的羣集保持穩定並且節點不會崩潰的重要原因之一。 
    總的來說，監控節點上的內存使用情況非常重要，並且儘可能多給es分配RAM，so it can leverage the speed of the file system cache without running out of space。

4、es主機的網絡和系統

Name [Metric type][monitoring-101-blog]
Available disk space Resource: Utilization
I/O utilization Resource: Utilization
CPU usage Resource: Utilization
Network bytes sent/received Resource: Utilization
Open file descriptors Resource: Utilization

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

Host指標要點：

  • Disk space: 如果數據很多，這個指標很關鍵。如果disk space 過小，講不能插入或更新任何內容，並且節點會掛掉。可以使用Curator這樣的工具來刪除特定的索引以保持disk的可用性。 
    如果不讓刪除索引，另外的辦法是添加磁盤、添加節點。請記住analyzed field佔用磁盤的空間遠遠高於non-analyzed fields。

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

    這裏寫圖片描述

  • CPU utilization: 在每個節點類型的熱圖（如上所示）中可視化CPU使用情況可能會有所幫助。 例如，您可以創建三個不同的圖表來表示集羣中的每組節點（例如，數據節點，主節點，客戶端節點）， 如果看到CPU使用率的增加，這通常是由於搜索量大或索引工作負載引起的。 如果需要，可以添加更多節點來重新分配負載。

  • Network bytes sent/received: 節點之間的通訊是集羣平衡的關鍵。因此需要監控network來確保集羣的health以及對集羣的需求（例如，segment在節點之間進行復制或重新平衡）。 Elasticsearch提供有關集羣通信的指標，但也可以查看發送和接收的字節數，以查看network接收的流量。

  • Open file descriptors: 文件描述符用於節點到節點的通信，客戶端連接和文件操作。如果這個number達到了系統的最大值，則只有在舊的連接和文件操作關閉之後才能進行新的連接和文件操作。 如果超過80％的可用文件描述符被使用，您可能需要增加系統的最大文件描述符數量。大多數Linux系統每個進程只允許1024個文件描述符。 在生產中使用Elasticsearch時，您應該將操作系統文件描述符計數重新設置爲更大，如64,000。

  • HTTP connections:

    Metric description Name [Metric type][monitoring-101-blog]
    Number of HTTP connections currently open http.current_open Resource: Utilization
    Total number of HTTP connections opened over time http.total_opened Resource: Utilization

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

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

Metric description Name [Metric type][monitoring-101-blog]
Cluster status (green, yellow, red) cluster.health.status Other
Number of nodes cluster.health.number_of_nodes Resource: Availability
Number of initializing shards cluster.health.initializing_shards Resource: Availability
Number of unassigned shards cluster.health.unassigned_shards Resource: Availability

指標要點：

  • Cluster status: 如果集羣狀態爲黃色，則至少有一個副本分片未分配或丟失。 搜索結果仍將完成，但如果更多的分片消失，您可能會丟失數據。 
    紅色的羣集狀態表示至少有一個主分片丟失，並且您缺少數據，這意味着搜索將返回部分結果。 您也將被阻止索引到該分片。 Consider setting up an alert to trigger if status has been yellow for more than 5 min or if the status has been red for the past minute.

  • Initializing and unassigned shards: 當首次創建索引或者重啓節點，其分片將在轉換到「started」或「unassigned」狀態之前暫時處於「initializing」狀態，此時主節點正在嘗試將分片分配到集羣中的數據節點。 如果您看到分片仍處於初始化或未分配狀態太長時間，則可能是您的集羣不穩定的警告信號。

6、資源saturation and errors

es節點使用線程池來管理線程如何消耗內存和CPU。 由於線程池設置是根據處理器數量自動配置的，所以調整它們通常沒有意義。However, it’s a good idea to keep an eye on queues and rejections to find out if your nodes aren’t able to keep up; 如果無法跟上，您可能需要添加更多節點來處理所有併發請求。Fielddata和過濾器緩存使用是另一個要監視的地方，as evictions may point to inefficient queries or signs of memory pressure.

Thread pool queues and rejections 
每個節點維護許多類型的線程池; 您要監視的確切位置將取決於您對es的具體用途，一般來說，監控的最重要的是搜索，索引，merge和bulk，它們與請求類型（搜索，索引，合併和批量操作）相對應。 
線程池隊列的大小反應了當前等待的請求數。 隊列允許節點跟蹤並最終服務這些請求，而不是丟棄它們。 一旦超過線程池的maximum queue size，Thread pool rejections就會發生。

Metric description Name [Metric type][monitoring-101-blog]
Number of queued threads in a thread pool thread_pool.bulk.queue
thread_pool.index.queue
thread_pool.search.queue
thread_pool.merge.queue		 Resource: Saturation
Number of rejected threads a thread pool thread_pool.bulk.rejected
thread_pool.index.rejected
thread_pool.search.rejected
thread_pool.merge.rejected		 Resource: Error

指標要點：

  • Thread pool queues: 大隊列不理想，因爲它們耗盡資源，並且如果節點關閉，還會增加丟失請求的風險。如果你看到線程池rejected穩步增加，你可能希望嘗試減慢請求速率（如果可能），增加節點上的處理器數量或增加羣集中的節點數量。 如下面的截圖所示，查詢負載峯值與搜索線程池隊列大小的峯值相關，as the node attempts to keep up with rate of query requests。 
    這裏寫圖片描述

  • Bulk rejections and bulk queues: 批量操作是一次發送許多請求的更有效的方式。 通常，如果要執行許多操作（創建索引或添加，更新或刪除文檔），則應嘗試以批量操作發送請求，而不是發送許多單獨的請求。 
    bulk rejections 通常與在一個批量請求中嘗試索引太多文檔有關。根據Elasticsearch的文檔，批量rejections並不是很需要擔心的事。However, you should try implementing a linear or exponential backoff strategy to efficiently deal with bulk rejections。

  • Cache usage metrics: 每個查詢請求都會發送到索引中的每個分片的每個segment中，Elasticsearch caches queries on a per-segment basis to speed up response time。另一方面，如果您的緩存過多地堆積了這些heap，那麼它們可能會減慢速度，而不是加快速度！ 
    在es中，文檔中的每個字段可以以兩種形式存儲：exact value 和 full text。 
    例如，假設你有一個索引，它包含一個名爲location的type。每個type的文檔有個字段叫city。which is stored as an analyzed string。你索引了兩個文檔，一個的city字段爲「St. Louis」，另一個的city字段爲「St. Paul」。在倒排索引中存儲時將變成小寫並忽略掉標點符號，如下表

    Term Doc1 Doc2
    st x x
    louis x  
    paul   x

分詞的好處是你可以搜索st。結果會搜到兩個。如果將city字段保存爲exact value，那隻能搜「St. Louis」, 或者 「St. Paul」。 
Elasticsearch使用兩種主要類型的緩存來更快地響應搜索請求：fielddata和filter。

  • Fielddata cache: fielddata cache 在字段排序或者聚合時使用。 a process that basically has to uninvert the inverted index to create an array of every field value per field, in document order. For example, if we wanted to find a list of unique terms in any document that contained the term 「st」 from the example above, we would: 
    1.掃描倒排索引查看哪些文檔（documents）包含這個term（在本例中爲Doc1和Doc2） 
    2.對1中的每個步驟，通過索引中的每個term 從文檔中來收集tokens，創建如下結構：

    Doc Terms
    Doc1 st, louis
    Doc2 st, paul

    3.現在反向索引被再反向，從doc中compile 獨立的tokens(st, louis, and paul)。compile這樣的fielddata可能會消耗大量堆內存。特別是大量的documents和terms的情況下。 所有字段值都將加載到內存中。

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

  • Filter cache: 過濾緩存也使用JVM堆。 在2.0之前的版本中，Elasticsearch自動緩存過濾的查詢，最大值爲堆的10％，並且將最近最少使用的數據逐出。 從版本2.0開始，Elasticsearch會根據頻率和段大小自動開始優化其過濾器緩存（緩存僅發生在索引中少於10,000個文檔的段或小於總文檔的3％）。 因此，過濾器緩存指標僅適用於使用2.0之前版本的Elasticsearch用戶。 
    例如，過濾器查詢可以僅返回年份字段中的值在2000-2005範圍內的文檔。 在首次執行過濾器查詢時，Elasticsearch將創建一個與其相匹配的文檔的位組（如果文檔匹配則爲1，否則爲0）。 使用相同過濾器後續執行查詢將重用此信息。 無論何時添加或更新新的文檔，也會更新bitset。 如果您在2.0之前使用的是Elasticsearch版本，那麼您應該關注過濾器緩存以及驅逐指標（更多關於以下內容）。

    Metric description Name [Metric type][monitoring-101-blog]
    Size of the fielddata cache (bytes) indices.fielddata.memory_size_in_bytes Resource: Utilization
    Number of evictions from the fielddata cache indices.fielddata.evictions Resource: Saturation
    Size of the filter cache (bytes) (only pre-version 2.x) indices.filter_cache.memory_size_in_bytes Resource: Utilization
    Number of evictions from the filter cache (only pre-version 2.x) indices.filter_cache.evictions Resource: Saturation

  • Fielddata cache evictions: 理想情況下，我們需要限制fielddata evictions的數量，因爲他們很吃I/O。如果你看到很多evictions並且你又不能增加內存。es建議限制fielddata cache的大小爲20%的heap size。這些是可以在elasticsearch.yml中進行配置的。當fielddata cache達到20%的heap size時，es將驅逐最近最少使用的fielddata,然後允許您將新的fielddata加載到緩存中。 
    es還建議使用doc values，因爲它們與fielddata的用途相同。由於它們存儲在磁盤上，它們不依賴於JVM heap。儘管doc values不能被用來分析字符串， they do save fielddata usage when aggregating or sorting on other types of fields。在2.0版本後，doc values會在文檔被index的時候自動創建，which has reduced fielddata/heap usage for many users。

  • Filter cache evictions: 如前所述，filter cache eviction 指標只有在es2.0之前的版本可用。每個segment都維護自己的filter cache eviction。因爲eviction在大的segment上操作成本較高，沒有的明確的方法來評估eviction。但是如果你發現eviction很頻繁，表明你並沒有很好地利用filter，此時你需要重新創建filter，即使放棄原有的緩存，你也可能需要調整查詢方式（用bool query 而不是 and/or/not filter）。

  • Pending tasks:

    Metric description Name [Metric type][monitoring-101-blog]
    Number of pending tasks pending_task_total Resource: Saturation
    Number of urgent pending tasks pending_tasks_priority_urgent Resource: Saturation
    Number of high-priority pending tasks pending_tasks_priority_high Resource: Saturation

    pending task只能由主節點來進行處理，這些任務包括創建索引並將shards分配給節點。任務分優先次序。如果任務的產生比處理速度更快，將會產生堆積。待處理任務的數量是您的羣集運行平穩的良好指標，如果您的主節點非常忙，並且未完成的任務數量不會減少，我們需要仔細檢查原因。

  • Unsuccessful GET requests: GET請求比正常的搜索請求更簡單 - 它根據其ID來檢索文檔。 get-by-ID請求不成功意味着找不到文檔ID

 

結論
在這篇文章中，我們介紹了Elasticsearch的一些最重要的領域，以便在您擴展和擴展集羣時進行監控：

搜索和索引性能 內存和垃圾收集 主機級系統和網絡指標 羣集運行狀況和節點可用性 資源飽和和錯誤 在監視Elasticsearch指標以及節點級系統指標時，您將發現哪些區域對您的特定用例最有意義。 閱讀本系列的第2部分，瞭解如何開始收集和可視化對您最重要的Elasticsearch指標。  

联系我们 沪ICP备2021010478号-7