Elasticsearch的10個重要指標

Elasticsearch正在蓬勃發展。與用於收集和處理日誌的Logstash和用於在Elasticsearch中搜索和可視化數據的工具Kibana(又名“ELK”堆棧)一起，Elasticsearch的采用繼續成長突飛猛進。實際使用Elasticsearch時，會生成大量指標。在這一篇博客文章中，我沒有承擔介紹ElasticSearch所有指標的艱巨任務，而是看看10個Elasticsearch重點指標。這對任何Elasticsearch新人都有幫助，對那些希望快速啟動Elasticsearch性能監控的有經驗的用戶也會有所幫助。

這部分組中的大多數圖表通過在一個圖表中顯示多個指標或將它們組織到儀表板中來進行度量。這樣做是為了為我們正在探索的每個指標提供上下文。

首先，下麵是我們要討論的10個Elasticsearch指標的儀表板視圖：

現在，我們逐一深入研究10個指標中的每一個，並了解如何解釋它們。

1.集群健康 – 節點和分片（Nodes and shards）

與服務器的OS指標一樣，集群運行狀況是Elasticsearch的基本指標。它提供了運行節點的概述以及分發給節點的分片的狀態。

將分片分配狀態的計數器放在一張圖中，可以看出集群如何隨時間恢複。特別是在重新啟動round-robin的升級過程中，了解群集分配分片所需的時間非常重要。

根據集群的特定設置，重新啟動後分配分片的過程可能需要很長時間。集群API給出了對分片分配的一些控製。

2.節點性能 – CPU

和其他服務器一樣，Elasticsearch的性能在很大程度上依賴於它所安裝的機器。 CPU，內存使用情況和磁盤I/O是每個Elasticsearch節點的基本操作係統度量標準。

在Elasticsearch(或任何其他Java應用程序)的上下文中，建議您在CPU使用率突增時查看Java虛擬機(JVM)指標。在下麵的例子中，高峰期的原因是垃圾收集活動較高。它可以被“collection count”識別，因為時間和數量增加了。

3.節點性能 – 內存使用情況

下圖顯示了一個很好的平衡。有一些備用內存，使用了近60％的內存，這為緩存內存留下了足夠的空間(例如文件係統緩存)。你更通常看到的實際上是一張顯示沒有空閑內存的圖表。人們對查看內存指標的新看法常常驚慌失措，認為沒有可用內存意味著服務器沒有足夠的內存。其實並非如此。沒有空閑的 memory 是件好事。如果服務器正在使用所有的內存，這很好。問題在於是否存在緩衝和緩存的內存(這是件好事)或者是否全部使用了。如果它全部被使用並且很少或沒有緩衝和緩存的內存，那麽服務器的RAM確實很低。因為Elasticsearch在Java虛擬機內部運行，所以JVM內存和垃圾收集是Elasticsearch-specific內存使用率需要查看的區域。

摘要儀表板

4.節點性能 – 磁盤I/O

搜索引擎大量使用存儲設備，觀看磁盤I/O可確保滿足這一基本需求。由於減少磁盤I/O的原因有很多，所以它被認為是一個關鍵指標，是許多問題的一個很好的指標。檢查索引和查詢性能的有效性是一個很好的指標。讀和寫操作的區分直接表明了係統在特定用例中最需要的東西。通常情況下，查詢的讀取次數多於寫入次數，盡管Elasticsearch的一個常見用例是日誌管理，它通常具有較高的寫入和較低的讀取次數。當寫入高於讀取時，對索引的優化比查詢優化更重要。這個例子顯示了一個寫入次數多於讀取次數的日誌係統

磁盤I/O的操作係統設置是所有其他優化的基礎 – 調整磁盤I/O可避免潛在問題。如果磁盤I/O仍然不足，則應根據導致I/O的情況評估諸如優化碎片數量和大小，限製合並，替換慢磁盤，移動到SSD或添加更多節點等應對瓶頸。例如，在搜索時，如果索引不適合OS緩存，則磁盤會被刪除。這可以通過多種不同的方式解決：通過添加更多的RAM或數據節點，或者通過減小索引大小(例如，使用time-based索引和別名)，或者更智能地將搜索限製為僅限於特定的分片或索引而不是全部搜索或者通過緩存等。

5. Java – 堆使用和垃圾收集

Elasticsearch在JVM中運行，因此JVM的最佳設置以及垃圾回收器和內存使用情況的監視都非常重要。有關JVM和操作係統內存設置需要考慮幾件事情：

• 避免JVM進程交換到磁盤。在Unix，Linux和Mac OS X係統上：通過設置將進程地址空間鎖定到RAM中bootstrap.mlockall=true在Elasticsearch配置文件和環境變量中MAX_LOCKED_MEMORY=unlimited(例如在/etc /default /elasticsearch中)。要在Linux中設置全局swappiness，請設置vm.swappiness=1在/etc/sysctl.conf中。在Windows上，可以簡單地禁用虛擬內存。
• 定義Elasticsearch的堆內存通過設置ES_HEAP_SIZE環境變量(-Xmxjava選項)並遵循以下規則：  
  • 選擇合理的最小堆內存以避免“out of memory”錯誤。最佳做法是設置最小值(-Xms)等於最大堆大小(-Xmx)，所以在運行時不需要分配額外的內存。例：./bin/elasticsearch -Xmx16g -Xms16g
  • 根據經驗，將最大堆大小設置為可用物理RAM的50％。通常，不希望將超過50-60％的RAM分配給JVM堆。 JVM內存調整不是微不足道的，需要監視已使用和緩存的主內存以及JVM內存堆，內存池利用率和垃圾收集。
  • 不要超過32 GB的限製 – 如果您的服務器內存很大，運行更多Elasticsearch節點通常最好比超過32 GB的最大堆大小限製更好。總之，使用-Xmx32g或更高的結果在JVM中使用需要更多內存的更大的64位指針。如果你不走-Xmx31g，JVM將使用壓縮的普通對象指針(OOP)使用更小的32位指針。

以下報告對於了解JVM如何管理內存的所有Java開發人員來說都是顯而易見的。在這裏，我們看到所有內存空間的相對大小及其總大小。如果您正在對JVM的性能(幾乎每個Java應用程序都執行哪項操作)進行故障診斷，那麽除了查看垃圾回收和內存池利用率報告(參見圖“JVM pool utilization”)之外，這是首先檢查的關鍵位置之一。在下麵的圖表中，我們看到一個健康的鋸齒圖案清楚地顯示大型垃圾收集何時開始。

當我們觀察多個Elasticsearch節點的摘要時，由於垃圾收集發生在不同機器上的不同時間，因此鋸齒形圖案不像平常那​​樣尖銳。盡管如此，仍然可以識別該模式，可能是因為此群集中的所有節點都是同時啟動的，並且正在遵循類似的垃圾回收循環。

6. Java – JVM池大小

內存池利用率圖顯示隨著時間的推移每個池正在使用的百分比。當這些內存池中的一些(尤其是舊的Gen或Perm Gen)達到100％的利用率並停留在那裏時，是時候擔心了。其實，那時已經太遲了。你有這些指標設置的警報，對吧？當發生這種情況時，您可能會發現垃圾收集時間增加和CPU使用率增加，因為JVM一直試圖釋放(幾乎)已滿的任何池中的一些空間。如果垃圾收集活動太多，可能是由於以下原因之一：

• 一個特定的內存池被壓垮，你可以調整(tuning)池子。
• JVM需要比分配給它更多的內存。在這種情況下，您可以降低您的需求或添加更多堆內存(ES_HEAP_SIZE)。理論上可以通過減少字段和過濾器緩存來降低Elasticsearch中使用的堆。在實踐中，這樣做會對查詢性能產生負麵影響。一種更好的方法來減少“not_analyzed“字段內存是使用”doc_values“索引映射/類型定義中的格式 – 它減少了查詢時的內存占用量。

內存使用量的劇烈變化或長時間的垃圾回收運行可能表明危急情況。例如，在所有節點上的JVM內存的匯總視圖中，內存中若幹GB的內存可能表示節點離開集群，重新啟動或重新配置以減少堆的使用。

摘要儀表板

7.搜索性能 – 請求延遲和請求率

在涉及搜索應用程序時，用戶體驗通常（typically）與搜索請求的延遲高度相關。例如，簡單查詢的請求延遲通常低於100.我們說“typically”是因為Elasticsearch經常用於分析查詢，人們似乎仍然容忍場景中較慢的查詢。有很多事情可能會影響查詢的性能 – 構造不佳的查詢，Elasticsearch集群配置不當，JVM內存和垃圾收集問題，磁盤IO等等。毋庸置疑，查詢延遲是直接影響用戶的指標，因此請確保您在其上放置了一些警報。基於查詢延遲異常檢測的警報在這裏會很有幫助。下麵的圖表說明了這種情況。類似藍色第95百分位查詢延遲峰值的尖峰會使任何異常的基於檢測的警報係統跳閘。請注意：Elasticsearch公開的查詢延遲實際上是每個分片的查詢延遲指標。它們不是整個查詢的延遲值。

將請求延遲與請求速率一起放入圖形中，立即提供了係統使用量以及響應方式的概述。

8.搜索性能 – 過濾器緩存

Elasticsearch中的大部分過濾器默認都被緩存。這意味著在第一次執行帶有過濾器的查詢時，Elasticsearch將查找與過濾器匹配的文檔，並使用該信息構建名為“bitset”的結構。存儲在bitset中的數據非常簡單;它包含文檔標識符以及給定的文檔是否與過濾器匹配。隨後執行具有相同過濾器的查詢將重新使用存儲在位集中的信息，從而通過節省I/O操作和CPU周期來加快查詢執行速度。盡管過濾器相對較小，但如果您擁有大量數據和眾多不同的過濾器，則它們可占用大部分JVM堆。因此，明智地設置“indices.cache.filter.size“屬性來限製用於過濾器緩存的堆的數量。要找出此屬性的最佳設置，請關注下圖中顯示的過濾器高速緩存大小和過濾器高速緩存驅逐度量標準。

9.搜索性能 – 字段數據緩存

如果使用聚合查詢，則字段數據高速緩存大小和驅逐對於搜索性能通常很重要。字段數據構造費用昂貴 – 它需要將數據從磁盤提取到內存中。字段數據也用於排序和腳本字段。請記住，默認情況下(由於構建它的代價太大)，字段數據緩存是無限的。這當然會讓你的JVM堆爆炸。為了避免令人討厭的意外，請考慮通過設置“indices.fielddata.cache.size“屬性並密切關注它以了解緩存的實際大小。

摘要儀表板

10.索引性能 – 刷新時間和合並時間

Elasticsearch在編製索引過程中發生了幾件不同的事情，並且有許多指標可以監控其性能。在運行索引基準時，通常會使用固定數量的記錄來計算索引率。不過，在製作過程中，您通常需要關注真正的索引速率。 Elasticsearch本身並不公開速率本身，但它確實暴露了可以計算速率的文檔數量，如下所示：

這是另一個值得考慮的警報和/或異常檢測指標。索引率突然上升和下降可能表明數據源存在問題。刷新時間和合並時間與索引性能密切相關，並影響整體集群性能。刷新時間隨著Lucene索引(分片)的文件操作數量的增加而增加。將刷新間隔設置為較高的值(例如從1秒到30秒)可以實現刷新時間的縮短。當Elasticsearch(實際上是位於Elasticsearch核心的索引/搜索庫Apache Lucene)合並很多分段(segments)，或者隻是一個非常大的索引分段時，合並時間就會增加。這是正確合並策略，分片和分段設置的好指標。另外，磁盤I/O指示在CPU使用率高峰期間密集使用寫入操作。因此，合並應該盡可能快。或者，如果合並太多影響集群，則可以限製合並吞吐量並增加“indices.memory.index_buffer_size“(在小堆上的節點上超過10％)來減少磁盤I/O，並且讓並發執行的查詢具有更多的CPU周期。

分段合並對於指數表現來說是一個非常重要的過程，但它並非沒有副作用。較高的索引性能通常意味著允許存在更多的段，從而使查詢稍微慢一些。

摘要儀表板

主要的Elasticsearch度量指標可以幫你發現很多問題！ – 在圖表，圖形，儀表板等中。Elasticsearch是一個high-powered平台，可以極好地滿足您組織的搜索需求，但是，就像一輛速度極快的跑車一樣，您必須知道要觀看什麽撥號以及如何換檔讓事情順利進行。持續關注這10個指標並進行相應的分析將使您走上成功的Elasticsearch體驗之路。

這篇文章是O’Reilly和Sematext合作的一部分。請參閱我們的編輯獨立聲明。