Elasticsearch 集群健康状态

一个 Elasticsearch 集群至少包括一个节点和一个索引。或者它 可能有一百个数据节点、三个单独的主节点，以及一小打客户端节点——这些共同操作一千个索引（以及上万个分片）。但是不管集群扩展到多大规模，你都会想要一个快速获取集群状态的途径。Cluster Health API 充当的就是这个角色。你可以把它想象成是在一万英尺的高度鸟瞰集群。它可以告诉你安心吧一切都好，或者警告你集群某个地方有问题。Elasticsearch 里其他 API 一样，cluster-health 会返回一个 JSON 响应。这对自动化和告警系统来说，非常便于解析。响应中包含了和你集群有关的一些关键信息:

  1. 查看Elasticsearch健康状态  (*表示ES集群的master主节点)
  2. [root@elk-node03 ~]# curl -XGET 'http://10.0.8.47:9200/_cat/nodes?v'
  3. host      ip        heap.percent ram.percent load node.role master name                      
  4. 10.0.8.47 10.0.8.47           53          85 0.16 d         *      elk-node03.kevin.cn
  5. 10.0.8.44 10.0.8.44           26          54 0.09 d         m      elk-node01.kevin.cn
  6. 10.0.8.45 10.0.8.45           71          81 0.02 d         m      elk-node02.kevin.cn
  8. 下面两条shell命令都可以监控到Elasticsearch健康状态
  9. [root@elk-node03 ~]# curl 10.0.8.47:9200/_cat/health
  10. 1554792912 14:55:12 kevin-elk green 3 3 4478 2239 0 0 0 0 - 100.0%
  12. [root@elk-node03 ~]# curl -X GET 'http://10.0.8.47:9200/_cluster/health?pretty'
  13. {
  14.   "cluster_name" : "kevin-elk",             #集群名称
  15.   "status" : "green",                             #为 green 则代表健康没问题，如果是 yellow 或者 red 则是集群有问题
  16.   "timed_out" : false,                           #是否有超时
  17.   "number_of_nodes" : 3,                    #集群中的节点数量
  18.   "number_of_data_nodes" : 3,
  19.   "active_primary_shards" : 2234,
  20.   "active_shards" : 4468,
  21.   "relocating_shards" : 0,
  22.   "initializing_shards" : 0,
  23.   "unassigned_shards" : 0,
  24.   "delayed_unassigned_shards" : 0,
  25.   "number_of_pending_tasks" : 0,
  26.   "number_of_in_flight_fetch" : 0,
  27.   "task_max_waiting_in_queue_millis" : 0,
  28.   "active_shards_percent_as_number" : 100.0      #集群分片的可用性百分比，如果为0则表示不可用
  29. }

正常情况下，Elasticsearch 集群健康状态分为三种：

green 最健康得状态，说明所有的分片包括备份都可用; 这种情况Elasticsearch集群所有的主分片和副本分片都已分配, Elasticsearch集群是 100% 可用的。
yellow 基本的分片可用，但是备份不可用（或者是没有备份）; 这种情况Elasticsearch集群所有的主分片已经分片了，但至少还有一个副本是缺失的。不会有数据丢失，所以搜索结果依然是完整的。不过，你的高可用性在某种程度上被弱化。如果 更多的 分片消失，你就会丢数据了。把 yellow 想象成一个需要及时调查的警告。
red 部分的分片可用，表明分片有一部分损坏。此时执行查询部分数据仍然可以查到，遇到这种情况，还是赶快解决比较好; 这种情况Elasticsearch集群至少一个主分片（以及它的全部副本）都在缺失中。这意味着你在缺少数据：搜索只能返回部分数据，而分配到这个分片上的写入请求会返回一个异常。

Elasticsearch 集群不健康时的排查思路

-> 首先确保 es 主节点最先启动，随后启动数据节点;
-> 允许 selinux（非必要），关闭 iptables;
-> 确保数据节点的elasticsearch配置文件正确;
-> 系统最大打开文件描述符数是否够用;
-> elasticsearch设置的内存是否够用 (“ES_HEAP_SIZE“内存设置 和 “indices.fielddata.cache.size“上限设置);
-> elasticsearch的索引数量暴增 , 删除一部分索引(尤其是不需要的索引);