集群健康就像是光譜的一端——對集群的所有資訊進行高度概述。
而節點統計值api 則是在另一端。它提供乙個讓人眼花繚亂的統計資料的陣列，包含集群的每乙個節點統計值。
節點統計值提供的統計值如此之多，在完全熟悉它之前，你可能都搞不清楚哪些指標是最值得關注的。我們將會高亮那些最重要的監控指標（但是我們鼓勵你記錄介面提供的所有指標——
或者用 marvel ——因為你永遠不知道何時需要某個或者另乙個值）。
get _nodes/stats
1、開頭部分
在輸出內容的開頭，我們可以看到集群名稱和我們的第乙個節點：
節點是排列在乙個雜湊裡，以節點的 uuid 作為鍵名。還顯示了節點網路屬性的一些資訊（比如傳輸層位址和主機名）。這些值對除錯諸如節點未加入集群這類自動發現問題很有用。
2、索引部分
索引(indices)部分列出了這個節點上所有索引的聚合過的統計值
返回的統計值被歸入以下部分：
docs展示節點記憶體有多少文件，包括還沒有從段裡清除的已刪除文件數量。
store部分顯示節點耗用了多少物理儲存。這個指標包括主分片和副本分片在內。如果限流時間很大，那可能表明你的磁碟限流設定得過低（在段和合併裡討論過）。
1、indexing顯示已經索引了多少文件。這個值是乙個累加計數器。在文件被刪除的時候，數值不會下降。還要注意的是，在發生內部 索引 操作的時候，這個值也會增加，比如說文件更新。
還列出了索引操作耗費的時間，正在索引的文件數量，以及刪除操作的類似統計值。
2、get顯示通過 id 獲取文件的介面相關的統計值。包括對單個文件的get和head請求。
3、search描述在活躍中的搜尋（open_contexts）數量、查詢的總數量、以及自節點啟動以來在查詢上消耗的總時間。用query_time_in_millis / query_total計算的比值，
可以用來粗略的評價你的查詢有多高效。比值越大，每個查詢花費的時間越多，你應該要考慮調優了。fetch 統計值展示了查詢處理的後一半流程（query-then-fetch 裡的 fetch ）。
如果 fetch 耗時比 query 還多，說明磁碟較慢，或者獲取了太多文件，或者可能搜尋請求設定了太大的分頁（比如，size: 10000）。
4、merges包括了 lucene 段合併相關的資訊。它會告訴你目前在執行幾個合併，合併涉及的文件數量，正在合併的段的總大小，以及在合併操作上消耗的總時間。
在你的集群寫入壓力很大時，合併統計值非常重要。合併要消耗大量的磁碟 i/o 和 cpu 資源。如果你的索引有大量的寫入，同時又發現大量的合併數，一定要去閱讀索引效能技巧。
注意：文件更新和刪除也會導致大量的合併數，因為它們會產生最終需要被合併的段 碎片 。
elasticsearch 客戶端 集群監控
安裝 kibana cd kibana 5.5.1 linux x86 64 config 修改kibana 預設引數 vim kibana.yml 開放外訪問 建議加白名單 或者 nginx 訪問密碼 server.host 0.0.0.0 elasticsearch 位址 elasticsear...
elasticsearch配置詳解
elasticsearch的config資料夾裡面有兩個配置檔案 elasticsearch.yml和logging.yml，第乙個是es的基本配置檔案，第二個是日誌配置檔案，es也是使用log4j來記錄日誌的，所以logging.yml裡的設定按普通log4j配置檔案來設定就行了。下面主要講解下e...
誰在使用Elasticsearch
github github使用elasticsearch搜尋20tb的資料，包括13億的檔案和1300億行的 這個不用介紹了吧，碼農們都懂的，github在2013年1月公升級了他們的 搜尋，由solr轉為elasticsearch，目前集群規模為26個索引儲存節點和8個客戶端節點 負責處理搜尋請求...