es查看集群信息命令_cat和_cluster

冷不防 2021-06-24 13:58 788阅读 0赞

官方API地址：[https://www.elastic.co/guide/en/elasticsearch/reference/7.7/rest-apis.html][https_www.elastic.co_guide_en_elasticsearch_reference_7.7_rest-apis.html]

**查看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)  
关闭节点(\\nodes/\_master/\_shutdown)

以下对常用的命令做了解释·············································································

**verbose**  
每个命令都支持使用?v参数，来显示详细的信息

**help**  
每个命令都支持使用help参数，来输出可以显示的列：

**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 状态，也会长期保有未分配分片（因为缺少主分片）。

钻更深点：找到问题索引编辑

想象一下某天碰到问题了， 而你发现你的集群健康状态看起来像是这样：

好了，从这个健康状态里我们能推断出什么来？嗯，我们集群是 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，是索引总容量的一半。

[https_www.elastic.co_guide_en_elasticsearch_reference_7.7_rest-apis.html]: https://www.elastic.co/guide/en/elasticsearch/reference/7.7/rest-apis.html