1. 一个 Elasticsearch 集群至少包括一个节点和一个索引。或者它 可能有一百个数据节点、三个单独的主节点，以及一小打客户端节点——这些共同操作一千个索引（以及上万个分片）。但是不管集群扩展到多大规模，你都会想要一个快速获取集群状态的途径。Cluster Health API 充当的就是这个角色。你可以把它想象成是在一万英尺的高度鸟瞰集群。它可以告诉你安心吧一切都好，或者警告你集群某个地方有问题。Elasticsearch 里其他 API 一样，cluster-health 会返回一个 JSON 响应。这对自动化和告警系统来说，非常便于解析。响应中包含了和你集群有关的一些关键信息:
    4. {
    5.   "cluster_name" : "kevin-elk",             #集群名称
    6.   "status" : "green",                             #为 green 则代表健康没问题，如果是 yellow 或者 red 则是集群有问题
    7.   "timed_out" : false,                           #是否有超时
    8.   "number_of_nodes" : 3,                    #集群中的节点数量
    9.   "number_of_data_nodes" : 3,
    10.   "active_primary_shards" : 2234,
    11.   "active_shards" : 4468,
    12.   "relocating_shards" : 0,
    13.   "initializing_shards" : 0,
    14.   "unassigned_shards" : 0,
    15.   "delayed_unassigned_shards" : 0,
    16.   "number_of_pending_tasks" : 0,
    17.   "number_of_in_flight_fetch" : 0,
    18.   "task_max_waiting_in_queue_millis" : 0,
    19.   "active_shards_percent_as_number" : 100.0      #集群分片的可用性百分比，如果为0则表示不可用
    20. }
    24. 发起get请求  http://10.0.8.47:9200/_cluster/health?pretty
    26. 正常情况下，Elasticsearch 集群健康状态分为三种：
    27. green      最健康得状态，说明所有的分片包括备份都可用; 这种情况Elasticsearch集群所有的主分片和副本分片都已分配, Elasticsearch集群是 100% 可用的。
    28. yellow     基本的分片可用，但是备份不可用（或者是没有备份）;  这种情况Elasticsearch集群所有的主分片已经分片了，但至少还有一个副本是缺失的。不会有数据丢失，所以搜索结果依然是完整的。不过，你的高可用性在某种程度上被弱化。如果 更多的 分片消失，你就会丢数据了。把 yellow 想象成一个需要及时调查的警告。
    29. red    部分的分片可用，表明分片有一部分损坏。此时执行查询部分数据仍然可以查到，遇到这种情况，还是赶快解决比较好; 这种情况Elasticsearch集群至少一个主分片（以及它的全部副本）都在缺失中。这意味着你在缺少数据：搜索只能返回部分数据，而分配到这个分片上的写入请求会返回一个异常。
    32. Elasticsearch 集群不健康时的排查思路
    33. ->  首先确保 es 主节点最先启动，随后启动数据节点;
    34. ->  允许 selinux（非必要），关闭 iptables;
    35. ->  确保数据节点的elasticsearch配置文件正确;
    36. ->  系统最大打开文件描述符数是否够用;
    37. ->  elasticsearch设置的内存是否够用 ("ES_HEAP_SIZE"内存设置 和 "indices.fielddata.cache.size"上限设置);
    38. ->  elasticsearch的索引数量暴增 , 删除一部分索引(尤其是不需要的索引);