什麼是Elasticsearch
Elasticsearch是一個開源的分散式文件儲存和搜尋引擎，可以近乎實時地儲存和檢索資料結構，它很大程度上依賴於Apache Lucence--一個用Java編寫的全文搜尋引擎。
Elasticsearch以結構化JSON文件的形式呈現資料，並通過RESTful API和web客戶端為PHP，Python和Ruby等語言提供全文搜尋。Elasticsearch服務是具有彈性的，因為它易於水平擴充套件--只需新增更多節點即可分配負載。現在有很多企業動用它來動態儲存，搜尋和分析大量資料，包括維基百科，eBay，Github和Datadog。
工作方式
在探討效能指標之前，先來看看Elasticsearch的工作方式。在Elasticsearch中，叢集由一個或多個節點組成，如下
每個節點都是單個Elasticsearch例項，其elasticsearch.yml配置檔案制定它屬於哪個叢集(cluster.name)以及它是哪種型別的節點。配置檔案中設定的任何屬性（包括叢集名稱）也可以通過命令列引數指定。上圖中的叢集由一個專用主節點和五個資料節點組成。
Elasticsearch中最常見的三種型別的節點是：
- 符合條件的主節點：預設情況下，每個節點均可作為主節點。每個叢集都會自動從所有主節點中選擇一個主節點。如果當前主節點發生故障（例如停電，硬體故障或者記憶體不足），會從符合條件的節點中選出一個主節點。主節點負責協調叢集任務，例如跨節點分發分片，建立以及刪除索引。符合條件的主節點也可以充當資料節點。不過在較大的叢集中，通常啟動不儲存任何資料的專用主節點（配置檔案中設定
node.data為false），來提高可靠性。在高使用率的環境中，將主節點和資料節點分開有助於確保總是有足夠的資源分配給只有主節點可以處理的任務。 - 資料節點：預設情況下，每個節點都是以分片形式儲存資料的資料節點，這些節點執行索引，搜尋以及聚合資料相關的操作。在較大的叢集中，可通過在配置檔案中設定
node.master: false來建立專用資料節點，來確保這些節點有足夠的資源來處理與資料相關的請求，而無需處理叢集相關管理任務的額外工作量。 - 客戶節點：如果將
node.master和node.data設定為false，那麼該節點會成為一個客戶節點，用作一個負載均衡器，以幫助路有索引和搜尋請求。客戶端節點可以承擔一部分的搜尋工作量，以便讓資料節點和主節點可以專注於核心任務。根據使用情況，客戶節點可能不是必須的，因為資料節點能夠自行處理請求路由。但是，如果搜尋|索引的工作負載足夠大，可以利用客戶節點來幫助路有請求。
資料的儲存
在Elasticsearch中，相關資料通常儲存在同一個索引中，可以將其視為配置邏輯包裝的等價物。每個索引都包含一組JSON格式的相關文件。Elasticsearch的全文索引使用的是Lucence的倒排索引。為文件建立索引時，Elasticsearch會自動為每個欄位建立倒排索引；倒排索引將欄位對映到包含這些欄位的文件。
索引儲存在在主分片（一個或多個）和副本分片（零個或多個）中，每個分片都是一個Lucence的完整例項，可以當成一個迷你搜尋引擎。
當建立索引時，可以制定主分片的數量以及每個主分片的副本數量。預設值為每個索引五個主分片，每個主分片一個副本。在索引被建立後，主分片的數量無法更改，因此在選擇數量時要謹慎，否則後面可能需要重新建立索引。副本的數量可以在後面根據需求更新。為了防止資料丟失，主節點確保每個副本分片不會和主分片分配到同個節點上。
關鍵指標
Elasticsearch提供了大量指標，可以幫助使用者檢測出故障跡象，並在遇到諸如不可靠節點，記憶體不足和GC時間過長等問題時採取措施。一些需要監控的關鍵指標是：
- 搜尋和索引的效能
- 記憶體和垃圾回收
- 主機和網路
- 叢集健康度和節點可用性
- 資源飽和和錯誤
上面列出的指標都可以通過Elasticsearch的API以及像Elastic的Marvel這樣的工具收集到。
搜尋效能指標
搜尋請求和索引請求是Elasticsearch中的兩個主要請求型別。在某種程度上，這些請求和傳統資料庫系統中的讀取和寫入請求很類似。Elasticsearch提供了與搜尋過程的兩個主要階段（查詢和提取）相對應的指標。一次搜尋請求從開始到結束的路徑如下
- 客戶端向節點2傳送請求
- 節點2（協調節點）將查詢傳送到索引中每個分片的副本（主副本或分片副本）
- 每個分片在本地執行查詢並將結果傳給節點2。節點2將這些結果排序並編譯為全域性優先順序佇列。
- 節點2找出需要提取的文件，並向相關分片發出多個GET請求
- 每個分片載入文件，並返回給節點2
- 節點2將結果返回給客戶端
當Elasticsearch主要用於搜尋時，有必要監控查詢延遲並在超過闕值時採取措施。監控有關查詢和提取的相關指標非常重要，這些指標可以幫助確定在一段時間內的搜尋效能。比如，可以跟蹤查詢請求中的峰值和長期的的增長趨勢，以準備優化配置來獲得更好的效能和可靠性。
| 指標描述 | 指標名 | 指標型別 |
|---|---|---|
| query總數 | indices.search.query_total | 吞吐量 |
| query總耗時 | indices.search.query_time_in_millis | 效能 |
| 當前在處理的query數量 | indices.search.query_current | 吞吐量 |
| fetch總數 | indices.search.fetch_total | 吞吐量 |
| fetch總耗時 | indices.search.fetch_time_in_millis | 效能 |
| 當前在處理的fetch數量 | indices.search_fetch_current | 吞吐量 |
重點指標
Query 負載：監控當前正在進行的query數量可以大致瞭解叢集在任何特定時刻處理的請求數量。可以考慮在出現異常尖峰和驟降時發出警告。
Query延遲：儘管Elastisearch沒有明確提供這個指標，但是可以用現有指標來推算這個值，演算法是定期用查詢總數除以總耗時。
Fetch延遲：搜尋的第二階段（fetch階段）通常比query階段耗時要少。如果這個值持續增加，可能意味著磁碟速度慢，或者請求的結果數量過多。
索引效能指標
索引請求類似於傳統資料庫系統中的寫請求。如果Elasticsearch叢集主要用於索引，那麼對索引效能的監控是非常有必要的。在討論監控指標前，我們先看看Elasticsearch處理索引的方式。當在索引中新增新資訊或者刪除現有資訊時，索引中的每個分片都會通過兩個步驟更新：refresh和flush。
refresh
新加入到索引的文件不能立即用於搜尋，這些文件會先被寫入記憶體緩衝區，等待下一次索引重新整理，預設情況下每秒重新整理一次。refresh先從之前記憶體緩衝區中建立新的記憶體段，讓這些內容能夠被搜尋到，然後清空快取區，過程如下
段
索引的分片由多個段組成。這個Lucene的核心資料結構，一個段實際上索引的變更集。每個段使用檔案，記憶體和CPU，為了有效利用這些資源，這些段在每次重新整理時建立，隨後合併。
段是微型的倒排索引，可以將詞對映到包含這些詞的文件。每次搜尋索引時，依次搜尋主分片或者副本分片，在分片中搜尋每個分段。
段是不可變的，所以更新文件會：
- 在refresh過程中將資訊寫入新段
- 將舊資訊標記為刪除
當過期段與另一個段合併時，最終會刪除舊資訊。
flush
在將新索引文件新增到記憶體緩衝區的同時，這些內容也會新增到分片的translog，translog用於持久記錄操作的日誌。每隔30分鐘，或者當translog大小到達最大時（預設是512MB），會觸發一次flush操作。在flush期間，記憶體緩衝區的任何文件都會重新整理（儲存在新段中），所有記憶體中的段都會提交到磁碟，同時translog被清空。
translog有助於防止節點故障時丟失資料。可以用translog幫助恢復可能在重新整理之間丟失的操作。日誌每5秒提交到磁碟；或在索引，刪除，更新或批量請求成功後，日誌提交到磁碟。流程如下
Elasticsearch提供了很多有關索引的指標
| 指標描述 | 指標名 | 指標型別 |
|---|---|---|
| 索引的文件總數 | indices.indexing.index_total | 吞吐量 |
| 索引文件總耗時 | indices.indexing.index_time_in_millis | 效能 |
| 當前索引的文件數 | indices.indexing.index_current | 吞吐量 |
| 索引refresh總數 | indices.refresh.total | 吞吐量 |
| refresh總耗時 | indices.refresh.total_time_in_millis | 吞吐量 |
| 索引flush到磁碟總數 | indices.flush.total | 吞吐量 |
| flush總耗時 | indices.flush.total_time_in_millis | 吞吐量 |
重點指標
索引延遲：Elasticsearch並不直接提供這個指標，不過可以根據index_total和index_time_in_millis算出來。如果注延遲增加，可能是因為一次索引的太多文件（Elastisearch建議批量索引大小為5MB-15MB）。
如果計劃索引大量文件，並且不需要新的資訊可立即用於搜尋，可以通過降低重新整理頻率來優化索引效能而不是搜尋效能，直到完成索引。
Flush延遲：由於資料在成功完成重新整理之前不會持久儲存到磁碟，因此跟蹤重新整理延遲並在效能開始下潛時採取措施會很有用。如果看到此指標穩步增加，則可能表示磁碟速度較慢；此問題可能會升級並最終阻止向索引新增新文件。在這種情況下，可以嘗試降低index.translog.flush_threshold_size，此設定確定在觸發重新整理之前translog大小可以達到的大小。如果Elasticsearch寫比較重，可以考慮使用iostat關注磁碟I/O。
記憶體和垃圾回收
記憶體是需要監控的關鍵指標之一。Elasticsearch和Lucene以兩種方式利用節點上的所有可用記憶體：JVM堆和檔案系統快取。Elasticsearch在Java虛擬機器（JVM）中執行，這意味著JVM垃圾收集的持續時間和頻率也是需要監控起來的。
JVM堆
使用Elasticsearch需要設定適當的JVM堆大小。一般來說，Elasticsearch的經驗法則是將不到50％的可用RAM分配給JVM堆，永遠不會高於32GB。分配給Elasticsearch的堆記憶體越小，Lucene可用的記憶體就越多，而Lucene很大程度上依賴於檔案系統快取來快速響應請求；但是也不能設定的太小，因為可能會遇到記憶體不足，或者因為頻繁GC導致吞吐量降低。這篇部落格有詳細描述。
Elasticsearch預設設定JVM堆大小為1G，在大多數場景下這個都太小，可以所需要的堆大小匯出為環境變數，然後重新啟動Elasticsearch。
export ES_HEAP_SIZE=10g
複製程式碼垃圾回收
Elasticsearch依賴於垃圾收集（GC）程式來釋放堆記憶體。需要留意GC的頻率和持續時間。將堆設定得太大會導致垃圾收集時間過長；這些過度暫停是危險的，會導致叢集中其他節點認為該節點失去響應。
| 指標描述 | 指標名 | 指標型別 |
|---|---|---|
| 年輕代垃圾回收總數 | jvm.gc.collectors.young.collection_count | |
| 年輕代垃圾回收耗時 | jvm.gc.collectors.young.collection_time_in_millis | |
| 年老代垃圾回收總數 | jvm.gc.collectors.old.collection_count | |
| 年老代垃圾回收耗時 | jvm.gc.collectors.old.collection_time_in_millis | |
| 當前JVM堆佔比 | jvm.mem.heap_used_percent | |
| 已提交的JVM堆量 | jvm.mem.heap_committed_in_bytes |
重點指標
在使用的JVM堆： Elasticsearch設定為在JVM堆使用率達到75％時啟動垃圾回收。監視哪些節點表現出高堆使用率並設定警報以查明是否有任何節點始終使用超過85％的堆記憶體可能很有用：這表明垃圾收集的速度跟不上垃圾建立的速度。要解決這個問題，可以增加堆大小，或者通過新增更多節點來擴充套件群集。
已使用的堆和已提交的堆：使用的堆記憶體量通常採用鋸齒模式，當垃圾堆積時會上升，當收集垃圾時會下降。已使用堆和已提交堆比例增加時，意味著垃圾收集的速率跟不上物件建立的速度，這可能導致垃圾收集時間變慢，並最終導致OutOfMemoryErrors。
GC持續時間和頻率：回收年輕代和年老代垃圾回收都會經歷“世界停止”階段，因為JVM停止執行程式來進行回收。在這段時間內，節點無法完成任何任務。主節點會每隔30秒檢查其他節點狀體啊，如何任何節點的垃圾回收時間超過30秒，主節點將認為這個節點已經掛掉。
記憶體使用率：如上所述，Elasticsearch充分利用了尚未分配給JVM堆的任何RAM，其依靠作業系統的檔案系統快取來快速可靠地處理請求。有許多變數決定Elasticsearch是否成功從檔案系統快取中讀取。如果段檔案最近由Elasticsearch寫入磁碟，則它已在快取中；但是，如果節點已關閉並重新啟動，則第一次查詢段時，很可能必須從磁碟讀取資訊。這是需要為什麼確保叢集保持穩定並且節點不會崩潰的重要原因之一。
主機指標
I/O：在建立，查詢和合並段時，Elasticsearch會對磁碟進行大量寫入和讀取操作。對於具有持續經歷大量I / O活動的節點的大量叢集，Elasticsearch建議使用SSD來提高效能。
CPU使用率：視覺化CPU使用率會很有用。CPU使用率增加通常是由大量搜尋和索引請求導致。
網路流出/流入位元組數：節點之間的通訊是平衡群集的關鍵。除了Elasticsearch提供有關群集通訊的傳輸指標，還可以檢視網路卡傳送和接收的位元組速率。
開啟檔案數：檔案描述符用於節點到節點通訊，客戶端連線和檔案操作。如果此數字達到系統的最大容量，則在舊的連線關閉之前，將無法進行新的連線和檔案操作。
叢集狀態和節點可用性
| 指標描述 | 指標名 | 指標型別 |
|---|---|---|
| 叢集狀態 | cluster.health.status | |
| 節點數量 | cluster.health.number_of_nodes | 可用性 |
| 初始化中的分片數 | cluster.health.initializing_shards | 可用性 |
| 未分配分片數 | cluster.health.unassigned_shards | 可用性 |
叢集狀態：如果群集狀態為黃色，則至少有一個副本分片未分配或丟失。搜尋結果仍然完整，但如果更多分片消失，可能會丟失資料。
紅色群集狀態表示至少缺少一個主分片，並且資料正在丟失，這意味著搜尋將返回部分結果。
初始化中和未分配的分片：首次建立索引或重新啟動節點時，其主機節點嘗試將分片分配給節點時，其分片將在轉換為“已啟動”或“未分配”狀態之前暫時處於“初始化”狀態。如果發現分片在初始化或未分配狀態下保留的時間過長，則可能表示叢集不穩定。
結語
在這篇文章中，我們介紹了Elasticsearch的一些最重要的領域，以便在擴充套件和擴充套件叢集時對其進行監控。
在監視Elasticsearch指標以及節點級系統指標時，可以集合具體的使用場景挑選出最重要的指標。