代表es索引快照的存储方式，es默认是先把索引存放到内存中，当内存满了时再持久化到本地硬盘。gateway对索引快照进行存储，当这个es集群关闭再重新启动时就会从gateway中读取索引备份数据。es支持多种类型的gateway，有本地文件系统（默认），分布式文件系统，Hadoop的HDFS和amazon的s3云存储服务。

discovery.zen

代表es的自动发现节点机制，es是一个基于p2p的系统，它先通过广播寻找存在的节点，再通过多播协议来进行节点之间的通信，同时也支持点对点的交互。

Transport

代表es内部节点或集群与客户端的交互方式，默认内部是使用tcp协议进行交互，同时它支持http协议（json格式）、thrift、servlet、memcached、zeroMQ等的传输协议（通过插件方式集成）。

注意事项

同一个索引的分片和副本不能存在同一台机器上，因为在一台机器上没有意义，因此你如果使用的是单机版的话，不必指定副本的个数，即使指定了，那么es也不会将其存放在一台机器上的

监控集群健康状况

https://www.elastic.co/guide/cn/elasticsearch/guide/current/_cluster_health.html#_cluster_health
API：GET _cluster/health。返回的结果如下：
- 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 状态，也会长期保有未分配分片（因为缺少主分片）

{
   "cluster_name": "elasticsearch_zach",     //集群名称
   "status": "green",    //集群的状态名称
   "timed_out": false,     
   "number_of_nodes": 1,    //节点的个数
   "number_of_data_nodes": 1,    
   "active_primary_shards": 10,    //主分片的个数
   "active_shards": 10,     //涵盖了所有索引的_所有_分片的汇总值，即包括副本分片。
   "relocating_shards": 0,    //分片的个数
   "initializing_shards": 0,   
   "unassigned_shards": 0
}

其中的status状态如下：
- green：所有的主分片和副本分片都已分配。你的集群是 100% 可用的。
- yellow：所有的主分片已经分片了，但至少还有一个副本是缺失的。不会有数据丢失，所以搜索结果依然是完整的。不过，你的高可用性在某种程度上被弱化。如果 更多的 分片消失，你就会丢数据了。把 yellow 想象成一个需要及时调查的警告。
- red：至少一个主分片（以及它的全部副本）都在缺失中。这意味着你在缺少数据：搜索只能返回部分数据，而分配到这个分片上的写入请求会返回一个异常。
使用GET _cluster/health?level=indices能够获取更加详细的信息
GET _cluster/health?level=shards：
- shards 选项会提供一个详细得多的输出，列出每个索引里每个分片的状态和位置。这个输出有时候很有用，但是由于太过详细会比较难用。如果你知道哪个索引有问题了，本章讨论的其他 API 显得更加有用一点。