一、Elasticsearch 是什麽

Elasticsearch是一款用Java編寫的開源分布式文檔存儲和搜索引擎，可以用於near real-time存儲和數據檢索。

1、Elasticsearch簡要組成

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

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

三種最常見的es幾點類型有：

• master備選節點
  默認情況下（不動配置），每個節點均為master備選節點。每個集群都會自動從所有master備選節點中選擇一個成為master節點。在當前master節點遇到故障（例如停電，硬件故障或內存不足錯誤）的情況下，重新選舉產生新的master節點。master節點負責協調集群任務，比如跨節點的shards分發、創建和刪除索引等。
  master節點也能同時作為數據節點，但在比較大的集群中，master節點一般不存儲數據（通過設置node.data : false 來設置），以提高可靠性。在高可用環境中，節點任務明確、分離可以保證任務單一可靠。（專人幹專事）
• data節點
  默認情況下（不動配置），每個節點都是數據節點，以shards的形式存儲數據並執行與索引，搜索和聚合數據相關的操作。
  在大集群中，我們可以通過設置node.master : false來設置該節點為專用數據節點。確保這些節點具有足夠的資源來處理與數據相關的請求，而不需要承擔與集群相關的管理任務類的工作負載。
• client 節點
  如果將node.master 和node.data都設置為false。那麽該節點就是一個client節點。該client節點被設計為負載均衡器的角色，以幫助路由索引和搜索請求。
  client節點有助於承擔部分搜索工作量，以便數據和主節點節點可以專註於其核心任務。client節點並不是必須的，因為數據節點能夠自己處理請求路由。如果你的search/index workload比較重，可以在集群中配一個client節點。

2、Elasticsearch 如何組織數據

在es中，相關聯的數據通常存儲在相同的索引中，每個索引包含一組JSON格式的相關聯文檔。

Elasticsearch的全文搜索秘訣是Lucene的倒排索引。在索引（存入）數據的時候，es會自動為每個字段創建一個倒排索引，倒排索引將索引的詞（terms）映射(map)到包含該詞的文檔（document）中。

index被存儲在一個或多個主副shard中，每個shard都是一個完整的Lucenes實例，是一個完整的迷你搜索引擎。

創建索引時，可以指定主分片的數量以及每個主節點的副本數，默認為五個分片和一個副本。索引創建後，分片數不能被修改。如果要修改可能需要reindex。副本數可以在後期被修改。
為了防止數據丟失，主節點的調度機制會確保主副分片不會出現在同一個數據節點上。

二、我們要監控哪些Elasticsearch metric

Elasticsearch提供了大量的Metric，可以幫助您檢測到問題的跡象，在遇到節點不可用、out-of-memory、long garbage collection times的時候采取相應措施。
一些關鍵的檢測如下：

• Search and indexing performance（搜索、索引性能）
• Memory and garbage collection
• Host-level system and network metrics
• Cluster health and node availability
• Resource saturation（飽和） and errors

這裏提供了一個metric搜集和監控的框架 Monitoring 101 series
所有這些指標都可以通過Elasticsearch的API以及Elasticsearch的Marvel和Datadog等通用監控工具訪問。

1、搜索性能指標

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

1.客戶端向Node 2 發送搜索請求

2.Node 2（此時客串協調角色）將查詢請求發送到索引中的每一個分片的副本

3.每個分片（Lucene實例，迷你搜素引擎）在本地執行查詢，然後將結果交給Node 2。Node 2 sorts and compiles them into a global priority queue.

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

5.每個分片loads documents然後將他們返回給Node 2

6.Node 2將搜索結果交付給客戶端

節點處理，由誰分發，就由誰交付

如果您使用Elasticsearch主要用於搜索，或者如果搜索是面向客戶的功能。您應該監視查詢延遲和設定閾值。 監控關於查詢和提取的相關指標很重要，可以幫助您確定搜索隨時間的變化。 例如，您可能希望跟蹤查詢請求的尖峰和長期增長，以便您可以做好準備。

搜索性能指標的要點：

• Query load:監控當前正在進行的查詢數量可以讓您了解群集在任何特定時刻處理的請求數量。您可能還想監視搜索線程池隊列的大小，稍後我們將在本文中進一步解釋鏈接。
• Query latency: 雖然Elasticsearch沒有明確提供此度量標準，但監控工具可以幫助您使用可用的指標來計算平均查詢延遲，方法是以定期查詢總查詢次數和總經過時間。 如果延遲超過閾值，則設置警報，如果觸發，請查找潛在的資源瓶頸，或調查是否需要優化查詢。
• Fetch latency: 搜索過程的第二部分，即提取階段通常比查詢階段要少得多的時間。 如果您註意到這一指標不斷增加，可能是磁盤性能不好、highlighting影響、requesting too many results的原因。

2、索引性能指標

索引請求類似於傳統數據庫系統中的寫入請求，如果es的寫入工作量很重，那麽監控和分析您能夠如何有效地使用新數據更新索引非常重要。在了解指標之前，讓我們來探索Elasticsearch更新索引的過程，在新數據被添加進索引、更新或刪除已有數據，索引中的每個shard都有兩個過程：refresh 和 flush

Index fresh
新索引的文檔不能立馬被搜索的。
首先，它們被寫入一個內存中的緩沖區（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

在新索引的document添加到in-memory buffer的同時，它們也會被附加到分片的translog（a persistent, write-ahead transaction log of operations）中。

每隔30分鐘，或者每當translog達到最大大小（默認情況下為512MB）時，將觸發flush 。在flush 期間，在in-memory buffer上的documents會被refreshed（存到新的segments上），所有內存中的segments都提交到磁盤，並且translog被清空。

translog有助於防止節點發生故障時的數據丟失。 It is designed to help a shard recover operations that may otherwise have been lost between flushes. 這個translog每5秒將操作信息（索引，刪除，更新或批量請求（以先到者為準））固化到磁盤上。

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

索引性能指標的要點：

• 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
  • 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時間過長，這些長時間的停頓會讓集群錯誤的認為該節點已經脫離。

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主機的網絡和系統

雖然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、集群健康和節點可用性

指標要點：

• 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就會發生。

指標要點：

• 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

• 原文轉自：http://blog.csdn.net/yangwenbo214/article/details/74000458

elasticsearch 性能監控基礎