ES集群健康状态巡检评估

1024点线面
1,735 阅读4分钟

ES集群状态巡检和评估

基本状态检查

  1. 首先通过ES的health API检查集群状态

    网页可以直接输入：http://es-masster-ip:9200/_cluster/health?pretty获得以下回应：

    {
  "cluster_name" : "es_cluster_name",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 6,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 7,
  "active_shards" : 14,
  "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：是否为green，如果是yellow暂无需处理，如果是red需要进一步判断和处理，查看第2步。
  • number_of_nodes：是否为集群Master与Slave数的总和。
  • number_of_data_nodes：是否为集群Slave数的总和。
  • active_shards_percent_as_number：如果集群状态不是green，则此值小于100。

如果是需要输入密码，后台访问API改为：

curl -XGET -k -u name:passwd https://es-ip:9200/_cluster/health?pretty

注意：没有开启Xpack时不需要输入密码。否则http改为https，且需要输入用户名和密码才可以访问。

  1. 非正常状态的处理流程：

    1. 如果status值是yellow，表示所有主分片都已就绪，不影响业务的运行与搜索结果，可能是副本正在复制（副本增加），故障迁移等情形。可以观察initializing_shards和relocating_shards的数量是否在逐渐减小，以及active_shards_percent_as_number是否逐渐增大，大部分情况可以自行恢复green。

    2. 如果status值是red，表示有主分片没有恢复或缺失，需要处理。

      如果initializing_shards不为0，则等待并观察其是否下降。

      如果initializing_shards为0，但unassigned_shards或delayed_unassigned_shards不为0，则需要查询为何。查询的命令是:

      curl -XGET -k -u name:pass https:esip:9200/_cluster/allocation/explain?pretty

      如果显示原因有达到最大尝试次数而不恢复，可以手动执行:

      POST /_cluster/reroute?retry_failed=true&pretty。

    3. 其他原因，查看ES后台日志进一步分析处理。

集群健康状态评估

上一步基本健康状态检查可以查看当前的运行情况，根据最佳实践与官方指导，可以对ES集群做出更多建议和提醒。

  1. 单分片的大小不能过大，不建议超过40GB，大分片的索引速度和故障迁移恢复较慢。

    这个可以从以下命令进行检查：

    curl -XGET "http://es-ip:9200/_cat/indices?v"
​
health status index                uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   .kibana_task_manager Y_IEmN36RHCbtGn-qVYrew   1   1          2            0     59.3kb         29.6kb
green  open   .security-7          fl8slH16S7WFphBU8EzgVA   1   1         44            0      144kb           72kb
green  open   .management-beats    m_xoJuseSt-7hewrnvPTng   1   1          2            0     24.3kb         12.1kb
green  open   .kibana_1            ZuZH3TLKSUehBN1SlESKdw   1   1          4            1       48kb           24kb
green  open   test-log-index       bw2V0fC7S8KsPDG-FRcy_A   3   1     100000            0     23.6mb         11.8mb
    • 其中只看最后一列的大小，如果超过40GB，建议用户对该超大索引进行拆分，如原来按月存储的按周、按天进行拆分。
    • 如果某个索引已创建一定时间，但分片大小仍小于1GB，建议在业务运行的情况下合并小索引或删除不用的索引。

  2. 单节点的分片数量不宜超过600，这个可以直接进行计算：

    active_shards ÷ number_of_data_nodes = X
    • 单实例按heapsize为30G进行估算，如果计算得到的值X大于600，说明分片数过多，会造成额外的内存消耗和管理难度。

  3. 内存使用情况分析，命令如下：

    curl -XGET "http://es-ip:9200/_nodes/stats"
​
## 结果摘要，每个节点一份数据，主要看data节点……
"mem" : {
          "total_in_bytes" : 33566429184,
          "free_in_bytes" : 6087385088,
          "used_in_bytes" : 27479044096,
          "free_percent" : 18,
          "used_percent" : 82
        },
……
"jvm" : {
        "timestamp" : 1677466646931,
        "uptime_in_millis" : 238897033,
        "mem" : {
          "heap_used_in_bytes" : 876785456,
          "heap_used_percent" : 42,
          "heap_committed_in_bytes" : 2077753344,
          "heap_max_in_bytes" : 2077753344,
          "non_heap_used_in_bytes" : 139616024,
          "non_heap_committed_in_bytes" : 151498752,
          "pools"
# 或者使用节点统计：
GET _cat/nodes?v
# 关注其heap.percent大小
    • 如图free_percent过低，表示系统没有给搜索留足够的缓存，建议增大可用内存。
    • heap_used_percent表示分配给ES 的内存已使用的比例，现在是42%，过高则表示内存不足，需调大Heap Size。

  4. 线程使用情况分析：

    curl -XGET "http://es-ip:9200/_cat/thread_pool?v"
# 或查看全部列信息：
curl -XGET "http://es-ip:9200/_cat/thread_pool?v&h=*"
​
## 结果摘要：
node_name        name                active queue rejected
master81-slave   analyze                  0     1        0
master81-slave   data_frame_indexing      0     0        0
master81-slave   fetch_shard_started      0     0        0
master81-slave   fetch_shard_store        0     0        0
master81-slave   flush                    1     0        0
master81-slave   force_merge              0     0        0
master81-slave   generic                  0     0        0
master81-slave   get                      0     1        0
master81-slave   listener                 0     0        0
master81-slave   management               1     0        0
master81-slave   refresh                  0     0        0
    • 如果没有rejected（拒绝），则无需优化调整，否则增大相关的线程。
    • queue的值较多是，需要留意并提前应对，队列满就会拒绝请求。
avatar
文章
阅读
粉丝