Elasticsearch 集群运维常用命令详解

集群相关命令

在介绍 ES 集群常用命令之前，我们先回顾下 ES 集群的分布式基本原理，从下图 1 中可以看出，ES 集群是由多个节点组成，节点中会选举出一个 Master 节点，用于管理、调度集群；每个节点上存储部分索引数据，索引数据由分片来承载，即集群中有多个索引，每个索引中又会有多个分片，分片中有一到多个 segment，segment 中存储具体的 doc 数据。

如下图 1 所示，当我们通过 Client 对集群执行写入操作时，请求首先到达的节点 1 被称为协调节点，协调节点 1 根据请求信息计算出主分片所在节点 3，并将请求转发至该节点 3，节点 3 在主分片写入成功后，再同步将请求转发至副本分片所在的节点 1 和 2，待副本分片所在节点都写入成功后，节点 3 返回请求给协调节点 1，协调节点 1 再返回写入成功信息给 Client。

图 1. Elasticsearch 分布式架构原理图

以上，我们简单回顾了下 ES 集群的分布式基本原理及读写模型。下面我们详细介绍下 ES 集群相关的常用命令。

1、查看集群健康状态

命令 Response：

{
  "cluster_name" : "es-wr-test-cluster",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 6,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 300,
  "active_shards" : 561,
  "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
}

我们知道集群共有三种健康状态，分别是 red、yellow 和 green。通过该命令，我们不仅可以了解集群名称 cluster_name

，集群的健康状态 status，还可以了解到集群当前有多少节点 numberofnodes，多少个数据节点 numberofdatanodes，有多少个主分片 activeprimaryshards，以及正在搬迁中的分片 relocatingshards、初始化中的分片 initializingshards，还未正常分配的分片 unassignedshards 等信息。如果集群是非 green 状态，我们还可以通过 activeshardspercentasnumber 来查看集群恢复的进度。

另外从 numberofpendingtasks 参数也能够看出当前集群的任务堆积情况，如果 numberofpendingtasks 数量较大，则表明 Master 在处理 task 时有点力不从心，承载的压力较大了。

图 2 是我们腾讯云 ES 客户的一个日志集群健康信息，从该图中我们就很清晰得看到集群当前的状态为 yellow，还有 690 个副本分片未正常分配，且有 126 个 task 任务堆积，当前的分片恢复进展为 97.8% 等。

图 2. 腾讯云 ES 客户某日志集群健康信息

从该 API 的官方文档中我们可以看到有一个 level 参数，该参数是一个可选参数，提供了三种枚举值，分别是 cluster、indices 和 shards。默认就是 cluster，如果我们需要查看索引或者分片维度的健康信息，则可以使用如下 API。

GET /_cluster/health?level=indices
GET /_cluster/health?level=shards

同时还支持查看某一个具体的索引的健康信息：

GET /_cluster/health/wr_index_1?level=indices
GET /_cluster/health/wr_index_1?level=shards

2、查看任务堆积详情

返回 Response：

insertOrder timeInQueue priority source
       1685       855ms HIGH     update-mapping [foo][t]
       1686       843ms HIGH     update-mapping [foo][t]
       1693       753ms HIGH     refresh-mapping [foo][[t]]
       1688       816ms HIGH     update-mapping [foo][t]
       1689       802ms HIGH     update-mapping [foo][t]
       1690       787ms HIGH     update-mapping [foo][t]
       1691       773ms HIGH     update-mapping [foo][t]

在上面的 API 中我们可以通过GET _cluster/health来查看集群当前是否有堆积。如果有堆积也只能看到堆积的量，不能看到堆积了哪些任务，而GET/_cat/pending_tasksAPI 则可以直接查看具体是哪些任务在执行。从该 API 返回的信息中我们可以看出有一个 priority 的字段，用于标记该 task 的优先级。翻看源码，我们可以看到 Master 处理的 task 主要有六种优先级。其优先度从高到低如下所示：

IMMEDIATE > URGENT > HIGH > NORMAL > LOW > LANGUID.

通常创建索引的优先级是 URGENT，更新 Mapping 的优先级是 HIGH，如果数据在高压力写入时频繁更新 mapping，则会导致 pending_tasks 堆积的比较严重，对 Master 造成较大压力。

另外与GET/_cat/pending_tasks还有一个相似的 API。即：

GET /_cluster/pending_tasks

返回 Response：

{
   "tasks": [
      {
         "insert_order": 101,
         "priority": "URGENT",
         "source": "create-index [foo_9], cause [api]",
         "executing" : true,
         "time_in_queue_millis": 86,
         "time_in_queue": "86ms"
      },
      {
         "insert_order": 46,
         "priority": "HIGH",
         "source": "shard-started ([foo_2][1], node[tMTocMvQQgGCkj7QDHl3OA], [P], s[INITIALIZING]), reason [after recovery from shard_store]",
         "executing" : false,
         "time_in_queue_millis": 842,
         "time_in_queue": "842ms"
      },
      {
         "insert_order": 45,
         "priority": "HIGH",
         "source": "shard-started ([foo_2][0], node[tMTocMvQQgGCkj7QDHl3OA], [P], s[INITIALIZING]), reason [after recovery from shard_store]",
         "executing" : false,
         "time_in_queue_millis": 858,
         "time_in_queue": "858ms"
      }
  ]
}