DevOps知识中心
DevOps知识中心

故障排除：检查和解释 Elasticsearch 集群健康状态

掌握诊断 Elasticsearch 集群健康状况的基本技巧。本指南详细介绍了如何使用 `_cat/health` API 来检查状态并解释至关重要的 Green（绿色）、Yellow（黄色）和 Red（红色）指示灯。了解未分配分片的基本原因，学习如何使用 `_cat/shards` 和 `_cluster/allocation/explain` 等高级 API 进行深度诊断，以及快速有效地解决关键集群不稳定所需的行动步骤。

46 浏览量

故障排除：检查和解释 Elasticsearch 集群健康状态

Elasticsearch 是一个强大的分布式搜索和分析引擎，但其分布式特性需要持续监控以确保数据完整性和高可用性。管理的第一步，也是最关键的一步，是检查集群健康状态。健康的状态确保所有主分片和副本分片（shard）都正确分配给节点并正常运行。

本指南提供了一种使用关键的 _cat/health API 检查集群健康的实用方法。我们将详细说明如何解释颜色编码的状态（绿色、黄色、红色），并提供诊断和解决常见不稳定问题的可操作步骤，帮助管理员快速恢复最佳集群性能。

理解 Elasticsearch 健康状态

Elasticsearch 使用一个简单的颜色编码交通灯系统来传达集群索引和分片的操作状态。此状态反映了主分片和副本分片的分配情况。

三种核心健康状态

状态 含义 数据可用性 冗余性 需要的操作
绿色 (Green) 所有主分片和副本分片都已分配并运行正常。 100% 可用 完全 仅监控
黄色 (Yellow) 所有主分片都已分配，但一个或多个副本分片未分配。 100% 可用 受损 调查/解决副本分配问题
红色 (Red) 一个或多个主分片未分配。 数据部分或完全丢失/不可用 严重受损 立即干预

使用 _cat/health 检查集群健康状态

_cat API 专为快速、人类可读的诊断而设计。_cat/health 端点是获取集群当前状态概览的最快方式。

基本命令

You can execute this command using cURL, the Kibana Dev Tools console, or any HTTP client.

# 使用 cURL (人类可读格式)
curl -X GET "localhost:9200/_cat/health?v&pretty"

解释 _cat/health 输出

成功的查询会返回一个包含关键指标的表格：

列名 描述
epoch 执行请求的时间（Unix 时间戳）。
timestamp 时间，格式为 HH:MM:SS。
cluster 集群的名称。
status 关键的颜色指示器（绿色、黄色或红色）。
node.total 当前加入集群的节点总数。
node.data 集群中的数据节点数量。
shards 应处于活动状态的分片总数（主分片 + 副本分片）。
pri 主分片总数。
relo 当前在节点间迁移的分片数量。
init 当前正在初始化的分片数量。
unassign 当前未分配的分片数量。

健康（绿色）集群示例：

epoch      timestamp cluster       status node.total node.data shards pri relo init unassign
1678886400 10:30:00  my-cluster-dev green         3         3     30  15    0    0        0

诊断状态：黄色 (Yellow)

当集群报告 黄色 状态时，这意味着虽然所有数据在技术上都是可用的（所有主分片都已分配），但定义的冗余级别未得到满足。一个或多个副本分片未能被分配。

黄色状态的常见原因

  1. 节点丢失（临时性）： 托管副本分片的数据节点已离线。Elasticsearch 会等待该节点返回或等待新节点加入，然后才会尝试重新分配。
  2. 节点不足： 如果您需要 2 个副本（数据总共 3 份拷贝），但只有 2 个数据节点，则第三个副本无法放置，导致永久性黄色状态，直到添加另一个节点为止。
  3. 延迟分配： 集群配置为在节点发生故障后延迟副本分配，以防止节点快速返回时立即进行昂贵的再平衡。
  4. 磁盘空间限制： 节点可能没有足够的磁盘空间来托管副本分片。

黄色状态的可操作步骤

  1. 检查未分配的分片： 使用 _cat/shards API 来确定具体哪些分片未分配 (u) 并且它们正在等待的原因。

    bash curl -X GET "localhost:9200/_cat/shards?v"

  2. 使用分配解释 API (Allocation Explain API)： 要详细诊断特定分片未分配的原因，请使用分配解释 API。请将下面的 index_name 和 shard_id 替换为通过 _cat/shards 找到的实际值。

    bash curl -X GET "localhost:9200/_cluster/allocation/explain?pretty" -H 'Content-Type: application/json' -d' { "index": "index_name", "shard": 0, "primary": false } '

    请特别关注 unassigned_info 和 decisions 字段，以查找诸如 CLUSTER_REBALANCE_ALLOCATION_DELAY 或 NO_VALID_TARGET_NODE 等原因。

  3. 验证节点数量和配置： 确保数据节点数量满足或超过所需的副本数量加一（N 个副本 + 1 个主分片）。

提示： 如果集群因已知的、短期的节点维护而呈黄色，通常可以暂时忽略，但请注意，此时您的运行是没有冗余保护的。

诊断状态：红色 (Red)

红色 状态是关键的，它表示一个或多个主分片未分配。这意味着存储在该分片中的数据在索引或搜索时完全不可用。

红色状态的常见原因

  1. 大规模节点故障： 主节点发生故障，并且由于数据损坏或在剩余集群中完全不可用，其他节点未能成功接管主角色。
  2. 磁盘损坏/故障： 包含主分片的存储设备发生故障，并且没有可提升的副本。
  3. 索引设置问题： 在文件系统级别对索引文件进行了错误的配置或不正确的删除。

红色状态的立即干预

在尝试手动恢复操作之前，请务必备份您的集群（通过快照）。

  1. 立即检查日志： 查看主节点和托管失败主分片的节点的日志，以确定确切的异常或崩溃原因（通常与磁盘故障或内存不足错误有关）。

  2. 识别失败的索引： 使用 _cat/shards 查找与未分配的主分片 (p) 关联的索引。

    ```bash

    查找 state 为 'UNASSIGNED' 且 primary 为 'p' 的行

    curl -X GET "localhost:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason"
    ```

  3. 尝试强制重路由 (危险 - 仅在最后手段使用)： 如果您确定数据存在于某个节点上（例如，某个节点已恢复但路由未更正），您可以尝试手动重路由。当主分片永久丢失，并且您决定丢弃丢失的数据并强制在健康节点上创建新的空主分片时，通常会使用此方法。

    ```bash

    警告：如果使用不当，此命令可能导致数据丢失。

    它会将一个空的主分片分配给一个节点，使索引变健康。

    curl -X POST "localhost:9200/_cluster/reroute?pretty" -H 'Content-Type: application/json' -d'
    {
    "commands" : [
    {
    "allocate_empty_primary" : {
    "index" : "failed_index_name",
    "shard" : 0,
    "node" : "target_node_name",
    "accept_data_loss" : true
    }
    }
    ]
    }
    '
    ```

  4. 从快照恢复： 如果失败的主分片无法恢复，恢复数据完整性的唯一安全方法是从最近成功的快照中恢复受影响的索引。

高级诊断：集群设置

有时，集群状态为红色或黄色是由于管理操作或预先配置的操作保护措施造成的。

检查集群路由分配

_cluster/settings API 允许您检查是否已明确禁用分片的自动分配，这会阻止集群自我修复。

# 检索当前的集群设置
curl -X GET "localhost:9200/_cluster/settings?include_defaults=true&pretty"

请特别关注以下设置：

{
  "persistent": {
    "cluster": {
      "routing": {
        "allocation": {
          "enable": "none" 
        }
      }
    }
  }
}

如果 cluster.routing.allocation.enable 设置为 none（或 primaries），Elasticsearch 将不会分配分片，从而使集群锁定在其当前状态（很可能是黄色或红色）。

重新启用分配

要恢复正常的shard分配，请将设置更新为 all：

curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "cluster.routing.allocation.enable": "all"
  }
}
'

结论

解释 Elasticsearch 集群健康状态是任何管理员的基本技能。_cat/health API 提供了对数据操作完整性的即时洞察。虽然 绿色 状态是目标，但理解 黄色 意味着冗余度降低，而 红色 意味着数据不可用，这使得可以使用 _cat/shards 和分配解释 API 等辅助工具进行精确、即时的故障排除。定期监控和主动快照仍然是防止集群发生关键故障的最佳防御措施。