Kibana 连接 Elasticsearch 显示 Status Red 集群健康状态异常怎么回事？

Elasticsearch 集群状态显示 Red 意味着至少有一个主分片未分配，数据存在丢失风险。这通常是 Elasticsearch 集群本身的健康状态，Kibana 仅负责展示。建议优先通过集群分配解释接口定位具体原因，再决定是恢复节点还是调整副本策略。

先说结论：Red 状态表示部分主分片不可用，需立即排查节点存活与磁盘水位，不可长期忽略。

先确认：调用 _cluster/health 接口确认受影响的索引范围
先处理：使用 _cluster/allocation/explain 查看分片未分配的具体理由
再验证：修复后观察集群状态是否转绿或黄，确认数据可查询

命令速用版

以下命令可在 Kibana Dev Tools 或通过 curl 直接执行，用于快速定位问题：

GET _cluster/health?v=true
GET _cat/nodes?v
GET _cat/allocation?v
GET _cluster/allocation/explain?pretty

如果集群无法响应，需先检查 Elasticsearch 服务进程是否存活，以及 9200 端口是否监听。

为什么会这样

Elasticsearch 集群健康状态分为 Green、Yellow、Red 三种。Green 表示所有主分片和副本分片都正常；Yellow 表示所有主分片正常，但部分副本分片未分配；Red 则表示至少有一个主分片未分配。

主分片未分配通常意味着这部分数据完全不可用。常见原因包括承载该分片的节点宕机且无其他副本、磁盘空间已满触发水位保护、或者分片分配规则（Allocation Rules）限制导致无法找到合适节点。节点故障和磁盘满是生产环境中最常见的两类情况。

分步处理

1. 检查节点存活情况

首先确认集群中实际存活的节点数量是否符合预期。使用 _cat/nodes 查看，如果预期 3 个节点却只显示 2 个，说明有节点掉线。

Kibana 连接 Elasticsearch 显示 Status Red 集群健康状态异常怎么回事？

GET _cat/nodes?v

如果节点缺失，优先尝试重启该节点上的 Elasticsearch 服务，并检查该节点日志（通常位于 /var/log/elasticsearch/ 或安装目录下的 logs 文件夹）。

2. 查看分片未分配原因

如果节点都正常，需查询具体哪个分片出了问题以及原因。使用分配解释接口：

GET _cluster/allocation/explain?pretty

返回结果中的 unassigned_info 字段会说明原因，例如 CLUSTER_RECOVERED、INDEX_CREATED 或 ALLOCATION_FAILED。重点关注 allocation_decisions 部分，它会告诉你是因为磁盘不足、分片数量限制还是其他规则导致无法分配。

3. 处理磁盘水位问题

首先使用以下命令检查各节点磁盘使用率：

GET _cat/allocation?v
GET _nodes/stats/fs?pretty

如果返回提示磁盘空间不足（disk watermark exceeded），需优先清理磁盘旧数据或扩容。若需临时紧急恢复以允许分片分配，可调整水位设置（生产环境慎用，操作后需验证）：

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.disk.watermark.low": "85%",
    "cluster.routing.allocation.disk.watermark.high": "90%",
    "cluster.routing.allocation.disk.watermark.flood_stage": "95%"
  }
}

注意：默认低水位通常为 85%，设置为过高值（如 95%）可能导致磁盘写满后 ES 进程崩溃或数据损坏。上述配置仅为恢复默认安全阈值，若需临时放宽，建议 flood_stage 最高不超过 90%，且必须在扩容后立即还原。

配置生效验证：

GET _cluster/settings?include_defaults=true

检查返回结果中 watermark 相关配置是否已更新。

4. 处理节点永久丢失

如果某个节点确实无法恢复，且该节点上的主分片没有副本，数据可能已丢失。若需强制移除该节点分配记录，可使用 reroute 命令（需谨慎，确认数据可放弃）：

POST _cluster/reroute?retry_failed=true

警告：盲目使用 reroute 命令可能在未确认数据副本情况下导致数据永久丢失，操作前请务必备照重要数据。

怎么验证是否生效

执行修复操作后，再次运行健康检查命令：

GET _cluster/health?v=true

观察 status 字段是否从 red 变为 yellow 或 green。同时检查 unassigned_shards 数量是否减少。在 Kibana 界面中，集群健康指示器应不再显示红色警告。

此外，尝试查询之前报错的索引数据，确认是否能正常返回结果：

GET //_search?size=1

常见坑

1. 忽略日志直接重启

很多情况下重启并不能解决分配问题，反而可能掩盖了磁盘满或内存不足的真相。务必先看日志和分配解释接口。

2. 盲目关闭副本

将副本数设为 0 可以让状态变绿，但这会失去数据冗余保护。仅建议在测试环境或确认数据可丢失的临时场景使用。

3. 版本不兼容

如果刚升级过版本，需注意主版本之间不支持直接滚动升级，可能导致分片无法分配。升级前务必查阅官方兼容性矩阵，确认大版本跨越是否需要重建索引。

参考来源

Elastic, "Cluster health API", Elastic Guide, https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html
Elastic, "Cluster allocation explain API", Elastic Guide, https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-allocation-explain.html
Elastic, "Shard allocation", Elastic Guide, https://www.elastic.co/guide/en/elasticsearch/reference/current/shard-allocation.html