有kibana最好了。
https://www.elastic.co/guide/en/elasticsearch/reference/current/cat.html 感兴趣的，英语OK的同学可以去官网自查
·························································
查看API
查看别名接口(_cat/aliases): 查看索引别名
查看分配资源接口(_cat/allocation)
查看文档个数接口(_cat/count)
查看字段分配情况接口(_cat/fielddata)
查看健康状态接口(_cat/health)
查看索引信息接口(_cat/indices)
查看master信息接口(_cat/master)
查看nodes信息接口(_cat/nodes)
查看正在挂起的任务接口(_cat/pending_tasks)
查看插件接口(_cat/plugins)
查看修复状态接口(_cat/recovery)
查看线城池接口(_cat/thread_pool)
查看分片信息接口(_cat/shards)
查看lucence的段信息接口(_cat/segments)
··························································································
集群API
查看集群健康状态接口(_cluster/health)
查看集群状况接口(_cluster/state)
查看集群统计信息接口(_cluster/stats)
查看集群挂起的任务接口(_cluster/pending_tasks)
集群重新路由操作(_cluster/reroute)
更新集群设置(_cluster/settings)
节点状态(_nodes/stats)
节点信息(_nodes)
节点的热线程(_nodes/hot_threads)
关闭节点(
odes/_master/_shutdown)
以下对常用的命令做了解释·············································································
verbose
每个命令都支持使用?v参数，来显示详细的信息
help
每个命令都支持使用help参数，来输出可以显示的列：
$ curl localhost:9200/_cat/master?help
id | | node id
host | h | host name
ip | | ip address
node | n | node name
headers
通过h参数，可以指定输出的字段：
$ curl localhost:9200/_cat/master?v
id host ip node
QG6QrX32QSi8C3-xQmrSoA 127.0.0.1 127.0.0.1 Manslaughter
$ curl localhost:9200/_cat/master?h=host,ip,node
127.0.0.1 127.0.0.1 Manslaughter
参数拼到？后面 和 get请求一样
····································································································
1._cat/allocation 查看分配资源接口
curl 192.168.10.7:9200/_cat/allocation
9 38.8mb 4.7gb 13gb 17.7gb 26 192.168.2.116 192.168.2.116 node-1
9 38.8mb 9.1gb 8.6gb 17.7gb 51 192.168.2.114 192.168.2.114 node-2
curl 192.168.10.7:9200/_cat/allocation?v ?v表示显示详细信息（字段名）
shards disk.indices disk.used disk.avail disk.total disk.percent host ip node
9 38.8mb 9.1gb 8.6gb 17.7gb 51 192.168.2.114 192.168.2.114 node-1
9 38.8mb 4.7gb 13gb 17.7gb 26 192.168.2.116 192.168.2.116 node-2
shards:分片个数
disk.indices：索引所占磁盘大小
disk.used：已用磁盘大小
disk.avail：可以使用磁盘大小
disk.total：磁盘总容量
disk.percent：磁盘使用百分比
host：主机名
ip：服务ip
node：节点名称
------------------------------------------------------------
2._cat/nodes?v
curl 192.168.10.7:9200/_cat/nodes?v
ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
192.168.2.114 10 96 1 0.00 0.01 0.00 mdi - node-1
192.168.2.116 3 100 0 0.00 0.00 0.00 mdi * node-2
heap.percent：堆内存占的内存百分比
ram.percent：物理内存占用百分比
cpu：表示使用的cpu核心
load_1m load_5m load_15m：1分钟 5分钟 15分钟 占用系统cup百分比
node.role：表示节点能充当的角色主、数据 节点
master：表示当前是否为主节点，*表示当前为主
------------------------------------------------------------
3._cluster/health 快速检查集群的健康状况
curl localhost:9200/_cluster/health?pretty # ?pretty JSON格式显示，易读
{
"cluster_name" : "RK",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 2,
"number_of_data_nodes" : 2,
"active_primary_shards" : 9,
"active_shards" : 18,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
}
输出里最重要的就是 status 这行。很多开源的 ES 监控脚本，其实就是拿这行数据做报警判断。status 有三个可能的值：
green 绿灯，所有分片都正确运行，集群非常健康。
yellow 黄灯，所有主分片都正确运行，但是有副本分片缺失。这种情况意味着 ES 当前还是正常运行的，但是有一定风险。注意，在 Kibana4 的 server 端启动逻辑中，即使是黄灯状态，Kibana 4 也会拒绝启动，死循环等待集群状态变成绿灯后才能继续运行。
red 红灯，有主分片缺失。这部分数据完全不可用。而考虑到 ES 在写入端是简单的取余算法，轮到这个分片上的数据也会持续写入报错。
curl 'localhost:9200/_cluster/health?level=cluster&pretty'
接口请求的时候，可以附加一个 level 参数，指定输出信息以 indices 还是 shards 级别显示。当然，有三个级别：cluster，indices，shards （如果写错了就默认输出cluster级别）一般来说，indices 级别就够了。
green
所有的主分片和副本分片都已分配。你的集群是 100% 可用的。
yellow
所有的主分片已经分片了，但至少还有一个副本是缺失的。不会有数据丢失，所以搜索结果依然是完整的。不过，你的高可用性在某种程度上被弱化。如果 更多的 分片消失，你就会丢数据了。把 yellow 想象成一个需要及时调查的警告。
red
至少一个主分片（以及它的全部副本）都在缺失中。这意味着你在缺少数据：搜索只能返回部分数据，而分配到这个分片上的写入请求会返回一个异常。
green/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 状态，也会长期保有未分配分片（因为缺少主分片）。
钻更深点：找到问题索引编辑
想象一下某天碰到问题了， 而你发现你的集群健康状态看起来像是这样：
{
"cluster_name": "elasticsearch_zach",
"status": "red",
"timed_out": false,
"number_of_nodes": 8,
"number_of_data_nodes": 8,
"active_primary_shards": 90,
"active_shards": 180,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 20
}
好了，从这个健康状态里我们能推断出什么来？嗯，我们集群是 red ，意味着我们缺数据（主分片 + 副本分片）了。我们知道我们集群原先有 10 个节点，但是在这个健康状态里列出来的只有 8 个数据节点。有两个数据节点不见了。我们看到有 20 个未分配分片。
这就是我们能收集到的全部信息。那些缺失分片的情况依然是个谜。我们是缺了 20 个索引，每个索引里少 1 个主分片？还是缺 1 个索引里的 20 个主分片？还是 10 个索引里的各 1 主 1 副本分片？具体是哪个索引？
要回答这个问题，我们需要使用 level 参数让 cluster-health 答出更多一点的信息：
GET _cluster/health?level=indices
这个参数会让 cluster-health API 在我们的集群信息里添加一个索引清单，以及有关每个索引的细节（状态、分片数、未分配分片数等等）：
{
"cluster_name": "elasticsearch_zach",
"status": "red",
"timed_out": false,
"number_of_nodes": 8,
"number_of_data_nodes": 8,
"active_primary_shards": 90,
"active_shards": 180,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 20
"indices": {
"v1": {
"status": "green",
"number_of_shards": 10,
"number_of_replicas": 1,
"active_primary_shards": 10,
"active_shards": 20,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0
},
"v2": {
"status": "red",
"number_of_shards": 10,
"number_of_replicas": 1,
"active_primary_shards": 0,
"active_shards": 0,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 20
},
"v3": {
"status": "green",
"number_of_shards": 10,
"number_of_replicas": 1,
"active_primary_shards": 10,
"active_shards": 20,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0
},
....
}
}
我们可以看到 v2 索引就是让集群变 red 的那个索引。
由此明确了，20 个缺失分片全部来自这个索引。
一旦我们询问要索引的输出，哪个索引有问题立马就很清楚了：v2 索引。我们还可以看到这个索引曾经有 10 个主分片和一个副本，而现在这 20 个分片全不见了。可以推测，这 20 个索引就是位于从我们集群里不见了的那两个节点上。
level 参数还可以接受其他更多选项：
GET _cluster/health?level=shards
shards 选项会提供一个详细得多的输出，列出每个索引里每个分片的状态和位置。这个输出有时候很有用，但是由于太过详细会比较难用。如果你知道哪个索引有问题了，本章讨论的其他 API 显得更加有用一点。
阻塞等待状态变化编辑
当构建单元和集成测试时，或者实现和 Elasticsearch 相关的自动化脚本时，cluster-health API 还有另一个小技巧非常有用。你可以指定一个 wait_for_status 参数，它只有在状态达标之后才会返回。比如：
GET _cluster/health?wait_for_status=green
这个调用会 阻塞 （不给你的程序返回控制权）住直到 cluster-health 变成 green ，也就是说所有主分片和副本分片都分配下去了。这对自动化脚本和测试非常重要。
如果你创建一个索引，Elasticsearch 必须在集群状态中向所有节点广播这个变更。那些节点必须初始化这些新分片，然后响应给主节点说这些分片已经 Started 。这个过程很快，但是因为网络延迟，可能要花 10–20ms。
如果你有个自动化脚本是 (a) 创建一个索引然后 (b) 立刻写入一个文档，这个操作会失败。因为索引还没完全初始化完成。在 (a) 和 (b) 两步之间的时间可能不到 1ms —— 对网络延迟来说这可不够。
比起使用 sleep 命令，直接让你的脚本或者测试使用 wait_for_status 参数调用 cluster-health 更好。当索引完全创建好，cluster-health 就会变成 green ，然后这个调用就会把控制权交还给你的脚本，然后你就可以开始写入了。
有效的选项是： green 、 yellow 和 red 。这个调回会在达到你要求（或者『更高』）的状态时返回。比如，如果你要求的是 yellow ，状态变成 yellow 或者 green 都会打开调用。
4.查看集群的健康状态。
http://127.0.0.1:9200/_cat/health?v
URL中_cat表示查看信息，health表明返回的信息为集群健康信息，?v表示返回的信息加上头信息，跟返回JSON信息加上?pretty同理，就是为了获得更直观的信息，当然，你也可以不加，不要头信息，特别是通过代码获取返回信息进行解释，头信息有时候不需要，写shell脚本也一样，经常要去除一些多余的信息。
通过这个链接会返回下面的信息，下面的信息包括：
集群的状态（status）：red红表示集群不可用，有故障。yellow黄表示集群不可靠但可用，一般单节点时就是此状态。green正常状态，表示集群一切正常。
节点数（node.total）：节点数，这里是2，表示该集群有两个节点。
数据节点数（node.data）：存储数据的节点数，这里是2。数据节点在Elasticsearch概念介绍有。
分片数（shards）：这是12，表示我们把数据分成多少块存储。
主分片数（pri）：primary shards，这里是6，实际上是分片数的两倍，因为有一个副本，如果有两个副本，这里的数量应该是分片数的三倍，这个会跟后面的索引分片数对应起来，这里只是个总数。
激活的分片百分比（active_shards_percent）：这里可以理解为加载的数据分片数，只有加载所有的分片数，集群才算正常启动，在启动的过程中，如果我们不断刷新这个页面，我们会发现这个百分比会不断加大。
5.查看集群的索引数。
http://127.0.0.1:9200/_cat/indices?v
通过该连接返回了集群中的所有索引：
索引健康（health），green为正常，yellow表示索引不可靠（单节点），red索引不可用。与集群健康状态一致。
状态（status），表明索引是否打开。
索引名称（index），这里有.kibana和school。
uuid，索引内部随机分配的名称，表示唯一标识这个索引。
主分片（pri），.kibana为1，school为5，加起来主分片数为6，这个就是集群的主分片数。
文档数（docs.count），school在之前的演示添加了两条记录，所以这里的文档数为2。
已删除文档数（docs.deleted），这里统计了被删除文档的数量。
索引存储的总容量（store.size），这里school索引的总容量为6.4kb，是主分片总容量的两倍，因为存在一个副本。
主分片的总容量（pri.store.size），这里school的主分片容量是7kb，是索引总容量的一半。
1.查看集群的健康状态。
http://127.0.0.1:9200/_cat/health?v
URL中_cat表示查看信息，health表明返回的信息为集群健康信息，?v表示返回的信息加上头信息，跟返回JSON信息加上?pretty同理，就是为了获得更直观的信息，当然，你也可以不加，不要头信息，特别是通过代码获取返回信息进行解释，头信息有时候不需要，写shell脚本也一样，经常要去除一些多余的信息。
通过这个链接会返回下面的信息，下面的信息包括：
集群的状态（status）：red红表示集群不可用，有故障。yellow黄表示集群不可靠但可用，一般单节点时就是此状态。green正常状态，表示集群一切正常。
节点数（node.total）：节点数，这里是2，表示该集群有两个节点。
数据节点数（node.data）：存储数据的节点数，这里是2。数据节点在Elasticsearch概念介绍有。
分片数（shards）：这是12，表示我们把数据分成多少块存储。
主分片数（pri）：primary shards，这里是6，实际上是分片数的两倍，因为有一个副本，如果有两个副本，这里的数量应该是分片数的三倍，这个会跟后面的索引分片数对应起来，这里只是个总数。
激活的分片百分比（active_shards_percent）：这里可以理解为加载的数据分片数，只有加载所有的分片数，集群才算正常启动，在启动的过程中，如果我们不断刷新这个页面，我们会发现这个百分比会不断加大。
2.查看集群的索引数。
http://127.0.0.1:9200/_cat/indices?v
通过该连接返回了集群中的所有索引：
索引健康（health），green为正常，yellow表示索引不可靠（单节点），red索引不可用。与集群健康状态一致。
状态（status），表明索引是否打开。
索引名称（index），这里有.kibana和school。
uuid，索引内部随机分配的名称，表示唯一标识这个索引。
主分片（pri），.kibana为1，school为5，加起来主分片数为6，这个就是集群的主分片数。
文档数（docs.count），school在之前的演示添加了两条记录，所以这里的文档数为2。
已删除文档数（docs.deleted），这里统计了被删除文档的数量。
索引存储的总容量（store.size），这里school索引的总容量为6.4kb，是主分片总容量的两倍，因为存在一个副本。
主分片的总容量（pri.store.size），这里school的主分片容量是7kb，是索引总容量的一半。