es集群状态查询命令

官方API地址: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参数,来输出可以显示的列:

  1.  
    $ curl localhost:9200/_cat/master?help
  2.  
    id | | node id
  3.  
    host | h | host name
  4.  
    ip | | ip address
  5.  
    node | n | node name

headers
通过h参数,可以指定输出的字段:

  1.  
    $ curl localhost:9200/_cat/master?v
  2.  
    id host ip node
  3.  
    QG6QrX32QSi8C3-xQmrSoA 127.0.0.1 127.0.0.1 Manslaughter
  4.  
     
  5.  
    $ curl localhost:9200/_cat/master?h=host,ip,node
  6.  
    127.0.0.1 127.0.0.1 Manslaughter

参数拼到?后面 和 get请求一样
····································································································
1._cat/allocation 查看分配资源接口

  1.  
    curl 192.168.10.7:9200/_cat/allocation
  2.  
    9 38.8mb 4.7gb 13gb 17.7gb 26 192.168.2.116 192.168.2.116 node-1
  3.  
    9 38.8mb 9.1gb 8.6gb 17.7gb 51 192.168.2.114 192.168.2.114 node-2
  4.  
     
  5.  
    curl 192.168.10.7:9200/_cat/allocation?v ?v表示显示详细信息(字段名)
  6.  
    shards    disk.indices      disk.used      disk.avail      disk.total      disk.percent        host                 ip                node
  7.  
     9    38.8mb      9.1gb     8.6gb    17.7gb      51      192.168.2.114    192.168.2.114      node-1
  8.  
     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

  1.  
    curl 192.168.10.7:9200/_cat/nodes?v
  2.  
    ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
  3.  
    192.168.2.114 10 96 1 0.00 0.01 0.00 mdi - node-1
  4.  
    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 快速检查集群的健康状况

  1.  
    curl localhost:9200/_cluster/health?pretty # ?pretty JSON格式显示,易读
  2.  
    {
  3.  
    "cluster_name" : "RK",
  4.  
    "status" : "green",
  5.  
    "timed_out" : false,
  6.  
    "number_of_nodes" : 2,
  7.  
    "number_of_data_nodes" : 2,
  8.  
    "active_primary_shards" : 9,
  9.  
    "active_shards" : 18,
  10.  
    "relocating_shards" : 0,
  11.  
    "initializing_shards" : 0,
  12.  
    "unassigned_shards" : 0,
  13.  
    "delayed_unassigned_shards" : 0,
  14.  
    "number_of_pending_tasks" : 0,
  15.  
    "number_of_in_flight_fetch" : 0,
  16.  
    "task_max_waiting_in_queue_millis" : 0,
  17.  
    "active_shards_percent_as_number" : 100.0
  18.  
    }

输出里最重要的就是 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 状态,也会长期保有未分配分片(因为缺少主分片)。

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

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

  1.  
    {
  2.  
    "cluster_name":"elasticsearch_zach",
  3.  
    "status":"red",
  4.  
    "timed_out":false,
  5.  
    "number_of_nodes":8,
  6.  
    "number_of_data_nodes":8,
  7.  
    "active_primary_shards":90,
  8.  
    "active_shards":180,
  9.  
    "relocating_shards":0,
  10.  
    "initializing_shards":0,
  11.  
    "unassigned_shards":20
  12.  
    }

好了,从这个健康状态里我们能推断出什么来?嗯,我们集群是 red ,意味着我们缺数据(主分片 + 副本分片)了。我们知道我们集群原先有 10 个节点,但是在这个健康状态里列出来的只有 8 个数据节点。有两个数据节点不见了。我们看到有 20 个未分配分片。

 

这就是我们能收集到的全部信息。那些缺失分片的情况依然是个谜。我们是缺了 20 个索引,每个索引里少 1 个主分片?还是缺 1 个索引里的 20 个主分片?还是 10 个索引里的各 1 主 1 副本分片?具体是哪个索引?

 

要回答这个问题,我们需要使用 level 参数让 cluster-health 答出更多一点的信息:

GET _cluster/health?level=indices

这个参数会让 cluster-health API 在我们的集群信息里添加一个索引清单,以及有关每个索引的细节(状态、分片数、未分配分片数等等):

  1.  
    {
  2.  
    "cluster_name":"elasticsearch_zach",
  3.  
    "status":"red",
  4.  
    "timed_out":false,
  5.  
    "number_of_nodes":8,
  6.  
    "number_of_data_nodes":8,
  7.  
    "active_primary_shards":90,
  8.  
    "active_shards":180,
  9.  
    "relocating_shards":0,
  10.  
    "initializing_shards":0,
  11.  
    "unassigned_shards":20,
  12.  
    "indices":{
  13.  
    "v1":{
  14.  
    "status":"green",
  15.  
    "number_of_shards":10,
  16.  
    "number_of_replicas":1,
  17.  
    "active_primary_shards":10,
  18.  
    "active_shards":20,
  19.  
    "relocating_shards":0,
  20.  
    "initializing_shards":0,
  21.  
    "unassigned_shards":0
  22.  
    },
  23.  
    "v2":{
  24.  
    "status":"red",
  25.  
    "number_of_shards":10,
  26.  
    "number_of_replicas":1,
  27.  
    "active_primary_shards":0,
  28.  
    "active_shards":0,
  29.  
    "relocating_shards":0,
  30.  
    "initializing_shards":0,
  31.  
    "unassigned_shards":20
  32.  
    },
  33.  
    "v3":{
  34.  
    "status":"green",
  35.  
    "number_of_shards":10,
  36.  
    "number_of_replicas":1,
  37.  
    "active_primary_shards":10,
  38.  
    "active_shards":20,
  39.  
    "relocating_shards":0,
  40.  
    "initializing_shards":0,
  41.  
    "unassigned_shards":0
  42.  
    }
  43.  
    }
  44.  
    }

我们可以看到 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,是索引总容量的一半。

posted @ 2021-12-09 15:31  zhaoguanhao  阅读(4088)  评论(0编辑  收藏  举报