ElasticSearch 叢集資訊監控
最近在做 ElasticSearch 的資訊（叢集和節點）監控，特此稍微整理下學到的東西。這篇文章主要介紹叢集的監控。
要監控哪些 ElasticSearch metrics
Elasticsearch 提供了大量的 Metric，可以幫助您檢測到問題的跡象，在遇到節點不可用、out-of-memory、long garbage collection times 的時候採取相應措施。但是指標太多了，有時我們並不需要這麼多，這就需要我們進行篩選。
叢集健康
一個 Elasticsearch 叢集至少包括一個節點和一個索引。或者它 可能有一百個資料節點、三個單獨的主節點，以及一小打客戶端節點——這些共同操作一千個索引（以及上萬個分片）。
不管叢集擴充套件到多大規模，你都會想要一個快速獲取叢集狀態的途徑。Cluster Health API 充當的就是這個角色。你可以把它想象成是在一萬英尺的高度鳥瞰叢集。它可以告訴你安心吧一切都好，或者警告你叢集某個地方有問題。
讓我們執行一下 cluster-health API 然後看看響應體是什麼樣子的：
GET _cluster/health和 Elasticsearch 裡其他 API 一樣，cluster-health 會返回一個 JSON 響應。這對自動化和告警系統來說，非常便於解析。響應中包含了和你叢集有關的一些關鍵資訊：
{
"cluster_name 響應資訊中最重要的一塊就是 status 欄位。狀態可能是下列三個值之一 :
| status | 含義 |
|---|---|
| green | 所有的主分片和副本分片都已分配。你的叢集是 100% 可用的。 |
| yellow | 所有的主分片已經分片了，但至少還有一個副本是缺失的。不會有資料丟失，所以搜尋結果依然是完整的。不過，你的高可用性在某種程度上被弱化。如果 更多的 分片消失，你就會丟資料了。把 yellow 想象成一個需要及時調查的警告。 |
| red | 至少一個主分片（以及它的全部副本）都在缺失中。這意味著你在缺少資料：搜尋只能返回部分資料，而分配到這個分片上的寫入請求會返回一個異常。 |
- number_of_nodes 和 number_of_data_nodes 這個命名完全是自描述的。
- active_primary_shards 指出你叢集中的主分片數量。這是涵蓋了所有索引的彙總值。
- active_shards 是涵蓋了所有索引的所有分片的彙總值，即包括副本分片。
- relocating_shards 顯示當前正在從一個節點遷往其他節點的分片的數量。通常來說應該是 0，不過在 Elasticsearch 發現叢集不太均衡時，該值會上漲。比如說：添加了一個新節點，或者下線了一個節點。
- initializing_shards 是剛剛建立的分片的個數。比如，當你剛建立第一個索引，分片都會短暫的處於 initializing 狀態。這通常會是一個臨時事件，分片不應該長期停留在 initializing狀態。你還可能在節點剛重啟的時候看到 initializing 分片：當分片從磁碟上載入後，它們會從initializing 狀態開始。
- unassigned_shards 是已經在叢集狀態中存在的分片，但是實際在叢集裡又找不著。通常未分配分片的來源是未分配的副本。比如，一個有 5 分片和 1 副本的索引，在單節點叢集上，就會有 5 個未分配副本分片。如果你的叢集是 red 狀態，也會長期保有未分配分片（因為缺少主分片）。
叢集統計
叢集統計資訊包含 叢集的分片數，文件數，儲存空間，快取資訊，記憶體作用率，外掛內容，檔案系統內容，JVM 作用狀況，系統 CPU，OS 資訊，段資訊。
檢視全部統計資訊命令：
curl -XGET 'http://localhost:9200/_cluster/stats?human&pretty'返回 JSON 結果：
{
"timestamp": 1459427693515,
"cluster_name": "elasticsearch",
"status": "green",
"indices": {
"count": 2,
"shards": {
"total": 10,
"primaries": 10,
"replication": 0,
"index": {
"shards": {
"min": 5,
"max": 5,
"avg": 5
},
"primaries": {
"min": 5,
"max": 5,
"avg": 5
},
"replication": {
"min": 0,
"max": 0,
"avg": 0
}
}
},
"docs": {
"count": 10,
"deleted": 0
},
"store": {
"size": "16.2kb",
"size_in_bytes": 16684,
"throttle_time": "0s",
"throttle_time_in_millis": 0
},
"fielddata": {
"memory_size": "0b",
"memory_size_in_bytes": 0,
"evictions": 0
},
"query_cache": {
"memory_size": "0b",
"memory_size_in_bytes": 0,
"total_count": 0,
"hit_count": 0,
"miss_count": 0,
"cache_size": 0,
"cache_count": 0,
"evictions": 0
},
"completion": {
"size": "0b",
"size_in_bytes": 0
},
"segments": {
"count": 4,
"memory": "8.6kb",
"memory_in_bytes": 8898,
"terms_memory": "6.3kb",
"terms_memory_in_bytes": 6522,
"stored_fields_memory": "1.2kb",
"stored_fields_memory_in_bytes": 1248,
"term_vectors_memory": "0b",
"term_vectors_memory_in_bytes": 0,
"norms_memory": "384b",
"norms_memory_in_bytes": 384,
"doc_values_memory": "744b",
"doc_values_memory_in_bytes": 744,
"index_writer_memory": "0b",
"index_writer_memory_in_bytes": 0,
"version_map_memory": "0b",
"version_map_memory_in_bytes": 0,
"fixed_bit_set": "0b",
"fixed_bit_set_memory_in_bytes": 0,
"file_sizes": {}
},
"percolator": {
"num_queries": 0
}
},
"nodes": {
"count": {
"total": 1,
"data": 1,
"coordinating_only": 0,
"master": 1,
"ingest": 1
},
"versions": [
"5.6.3"
],
"os": {
"available_processors": 8,
"allocated_processors": 8,
"names": [
{
"name": "Mac OS X",
"count": 1
}
],
"mem" : {
"total" : "16gb",
"total_in_bytes" : 17179869184,
"free" : "78.1mb",
"free_in_bytes" : 81960960,
"used" : "15.9gb",
"used_in_bytes" : 17097908224,
"free_percent" : 0,
"used_percent" : 100
}
},
"process": {
"cpu": {
"percent": 9
},
"open_file_descriptors": {
"min": 268,
"max": 268,
"avg": 268
}
},
"jvm": {
"max_uptime": "13.7s",
"max_uptime_in_millis": 13737,
"versions": [
{
"version": "1.8.0_74",
"vm_name": "Java HotSpot(TM) 64-Bit Server VM",
"vm_version": "25.74-b02",
"vm_vendor": "Oracle Corporation",
"count": 1
}
],
"mem": {
"heap_used": "57.5mb",
"heap_used_in_bytes": 60312664,
"heap_max": "989.8mb",
"heap_max_in_bytes": 1037959168
},
"threads": 90
},
"fs": {
"total": "200.6gb",
"total_in_bytes": 215429193728,
"free": "32.6gb",
"free_in_bytes": 35064553472,
"available": "32.4gb",
"available_in_bytes": 34802409472
},
"plugins": [
{
"name": "analysis-icu",
"version": "5.6.3",
"description": "The ICU Analysis plugin integrates Lucene ICU module into elasticsearch, adding ICU relates analysis components.",
"classname": "org.elasticsearch.plugin.analysis.icu.AnalysisICUPlugin",
"has_native_controller": false
},
{
"name": "ingest-geoip",
"version": "5.6.3",
"description": "Ingest processor that uses looksup geo data based on ip adresses using the Maxmind geo database",
"classname": "org.elasticsearch.ingest.geoip.IngestGeoIpPlugin",
"has_native_controller": false
},
{
"name": "ingest-user-agent",
"version": "5.6.3",
"description": "Ingest processor that extracts information from a user agent",
"classname": "org.elasticsearch.ingest.useragent.IngestUserAgentPlugin",
"has_native_controller": false
}
]
}
}記憶體使用和 GC 指標
在執行 Elasticsearch 時，記憶體是您要密切監控的關鍵資源之一。 Elasticsearch 和 Lucene 以兩種方式利用節點上的所有可用 RAM：JVM heap 和檔案系統快取。 Elasticsearch 執行在Java虛擬機器（JVM）中，這意味著JVM垃圾回收的持續時間和頻率將成為其他重要的監控領域。
上面返回的 JSON監控的指標有我個人覺得有這些：
- nodes.successful
- nodes.failed
- nodes.total
- nodes.mem.used_percent
- nodes.process.cpu.percent
- nodes.jvm.mem.heap_used
可以看到 JSON 檔案是很複雜的，如果從這複雜的 JSON 中獲取到對應的指標（key）的值呢，這裡請看文章 ：JsonPath —— JSON 解析神器