真实命令 · 少走弯路·已沉淀 95 篇排障/命令手册，25 份速查表，15 个配置工具进入排障台
LaoHand开发者排障手册
配置生成

search Troubleshooting

Elasticsearch 磁盘水位线排查方法

Elasticsearch 磁盘占用超过 flood_stage 水位线导致索引被置为 read_only_allow_delete、节点被踢出集群时，用 _cat/allocation 查磁盘使用率，清理无用索引和 forcemerge 释放空间，再手动 PUT _settings 解除只读限制。

磁盘超 flood_stage 会触发 index.blocks.read_only_allow_delete，清理磁盘后重置该设置即可恢复写入

适用环境Elasticsearch / Logstash / Kibana
风险等级低
最后验证2026-07-04
建议权限普通用户

2026-07-04 更新·约 4 分钟阅读

Scenario

这篇文章解决什么问题

适用于“Elasticsearch 磁盘水位线排查方法”对应的线上或本地排障场景。不要只根据最终报错下结论，应先把问题拆成入口、链路、目标服务和资源限制几层，再用命令逐层证实。磁盘超 flood_stage 会触发 index.blocks.read_only_allow_delete，清理磁盘后重置该设置即可恢复写入

Symptoms

典型现象

  • Elasticsearch 磁盘占用超过 flood_stage 水位线导致索引被置为 read_only_allow_delete、节点被踢出集群时，用 _cat/allocation 查磁盘使用率，清理无用索引和 forcemerge 释放空间，再手动 PUT _settings 解除只读限制。
  • 相关日志、命令或页面中反复出现 elasticsearch、磁盘水位线、只读 等关键词。
  • 同一服务在不同机器、不同入口或不同时间段表现不一致，需要通过证据链缩小范围。

Before Debugging

排查前先确认

  • 先确认是索引设计、查询写法还是集群资源问题，避免在错误的层面调参。
  • 保留慢查询、分片状态和节点资源水位，作为定位依据。
  • 区分查询慢（读路径）和写入慢（写路径），两者优化方向相反。

Root Causes

常见根因分层

分片未分配或磁盘水位线触发

节点磁盘超 flood watermark 会拒绝写入、分片无法分配，集群变 red 或 yellow，表现为大面积失败。

  • 看集群 health 和分片分配
  • 检查节点磁盘水位
  • 看 allocation explain

查询未用 filter 上下文或聚合过高基数

用 query 而非 filter 不走缓存、聚合字段基数过高、深分页 from+size 过大，都会让查询又慢又耗资源。

  • 区分 filter 和 query
  • 看聚合基数和分桶数
  • 排查深分页改 search_after

线程池满或熔断器触发

search/write 线程池队列打满会拒绝请求，parent breaker 触发会让大查询直接失败。

  • 看线程池 queue 和 rejected
  • 确认是否触发 breaker
  • 排查大聚合和全量扫描

Diagnosis Path

分步诊断流程

1. 固定现场，避免追着变化状态跑

先记录故障时间、影响入口、完整错误和最近一次变更。Elasticsearch 磁盘水位线排查方法 这类问题经常在重启、重试或缓存刷新后短暂消失，没有现场信息会很难复盘。

  • 截图或保存完整错误文本
  • 记录请求域名/IP/端口/namespace/服务名
  • 标出最近发布、配置、证书、镜像或依赖变更
1. 固定现场，避免追着变化状态跑
curl -X GET "http://localhost:9200/_cat/allocation?v"
curl -X GET "http://localhost:9200/_cluster/settings?include_defaults=true&filter_path=**.cluster.routing.allocation.disk.watermark*"

2. 在故障发生的同一位置复现

很多误判来自测试位置不同：本机通不代表服务器通，容器内通不代表宿主机通，集群外通也不代表 Pod 内通。复现命令要尽量贴近真实流量路径。

  • 从报错服务所在机器执行测试
  • 必要时加 Host、SNI、namespace 或代理参数
  • 把成功路径和失败路径的输出并排比较
2. 在故障发生的同一位置复现
curl -X GET "http://localhost:9200/_cluster/settings?include_defaults=true&filter_path=**.cluster.routing.allocation.disk.watermark*"
curl -X GET "http://localhost:9200/_all/_settings?pretty"
curl -X PUT "http://localhost:9200/<index>/_settings" -H 'Content-Type: application/json' -d'{"index.blocks.read_only_allow_delete": null}'

3. 读取服务端证据，而不是只看客户端提示

客户端报错通常是结果摘要。真正能区分根因的是服务端日志、内核日志、事件、进程状态或数据库状态。

  • 用 _cat/allocation 查看各节点磁盘使用率，确认是否触发 high/flood 水位线
  • 查看 _cluster/settings 中 disk.watermark.low/high/flood_stage 阈值（默认 85%/90%/95%）
  • 检查 _settings 是否存在 index.blocks.read_only_allow_delete 为 true
3. 读取服务端证据，而不是只看客户端提示
curl -X GET "http://localhost:9200/_all/_settings?pretty"
curl -X PUT "http://localhost:9200/<index>/_settings" -H 'Content-Type: application/json' -d'{"index.blocks.read_only_allow_delete": null}'

4. 做最小修复并立即回归验证

每次只改一个变量，修复后用同一条复现命令回测，并观察日志是否停止增长。这样可以避免多个临时改动互相掩盖。

  • 检查 _settings 是否存在 index.blocks.read_only_allow_delete 为 true
  • 清理磁盘空间（删除无用索引、forcemerge、清理日志）使使用率降到 flood_stage 以下
  • 手动解除 read_only_allow_delete 限制，验证索引可正常写入
4. 做最小修复并立即回归验证
curl -X GET "http://localhost:9200/_all/_settings?pretty"
curl -X PUT "http://localhost:9200/<index>/_settings" -H 'Content-Type: application/json' -d'{"index.blocks.read_only_allow_delete": null}'

Commands

排查命令与使用意图

命令 1

用于从指定位置模拟真实请求。加 -v 可以看到 DNS、TCP、TLS、HTTP 头和代理连接过程，是定位链路阶段的关键证据。

命令 1
curl -X GET "http://localhost:9200/_cat/allocation?v"

命令 2

用于从指定位置模拟真实请求。加 -v 可以看到 DNS、TCP、TLS、HTTP 头和代理连接过程，是定位链路阶段的关键证据。

命令 2
curl -X GET "http://localhost:9200/_cluster/settings?include_defaults=true&filter_path=**.cluster.routing.allocation.disk.watermark*"

命令 3

用于从指定位置模拟真实请求。加 -v 可以看到 DNS、TCP、TLS、HTTP 头和代理连接过程，是定位链路阶段的关键证据。

命令 3
curl -X GET "http://localhost:9200/_all/_settings?pretty"

命令 4

用于从指定位置模拟真实请求。加 -v 可以看到 DNS、TCP、TLS、HTTP 头和代理连接过程，是定位链路阶段的关键证据。

命令 4
curl -X PUT "http://localhost:9200/<index>/_settings" -H 'Content-Type: application/json' -d'{"index.blocks.read_only_allow_delete": null}'

Risk Notes

容易踩坑的地方

  • 不要在集群 red 状态下强制分配分片，可能造成数据丢失或不一致。
  • 不要随意调大熔断器阈值掩盖大查询问题，会让节点 OOM 导致更大的集群故障。
  • 不要使用深分页（from+size 超过 10000），应改用 search_after 或 scroll API。

Verification

修复后怎么确认

  • 原始故障现象已经消失，且使用同一入口重新测试 Elasticsearch 磁盘水位线 能稳定成功。
  • 服务端日志不再出现同类错误，监控中的错误率、重启次数、连接数或延迟回到正常区间。
  • 如果做过临时绕过，已经记录恢复计划，例如还原宽松策略、补监控、补限制或提交正式配置。

Prevention

后续预防

  • 监控集群 health、磁盘水位和线程池 rejected，建立趋势告警，提前发现集群问题。
  • 为索引设置 ILM 策略，自动滚动、收缩和删除，避免单索引无限膨胀导致性能下降。
  • 查询统一用 filter 上下文，并按数据量规划合理分片数，避免过度分片或分片不足。
  • 定期使用 Profile API 分析慢查询，优化查询 DSL 和索引映射。

常见问题

为什么磁盘清理后索引还是只读？

read_only_allow_delete 不会自动解除，需要手动 PUT _settings 把 index.blocks.read_only_allow_delete 设为 null。

节点磁盘满被踢出集群怎么办？

立即清理该节点磁盘，重启节点；若数据丢失需从副本或快照恢复，必要时临时调高 flood_stage 阈值应急。

Long-tail SEO

你可能正在搜索这些报错

下面这些错误原文、场景词和中英文搜索词，都是排查同类问题时常见的入口。

  • elasticsearch 磁盘水位线
  • ES 索引只读 read_only_allow_delete
  • elasticsearch flood_stage
  • _cat/allocation 磁盘使用率
  • elasticsearch 磁盘满 节点被踢出
  • elasticsearch watermark 阈值修改

Related

相关排障 / 命令 / 工具

按分类和标签关联的排障流程、命令模板和配置工具，方便顺着同一个问题继续往下查。

速查

Elasticsearch 常用命令速查表

Elasticsearch 常用命令一页速查：_cluster/health 与 _cat/nodes/shards 集群健康、allocation/explain 未分配诊断、_cat/indices 与 ILM 生命周期、thread_pool/breaker/slowlog 慢查询排查、水位线与 forcemerge 运维操作。

search命令

搜索引擎常用排障命令

Elasticsearch、Logstash、Kibana 排障命令速查，ES 用 _cluster/health、_cat/shards、_cluster/allocation/explain 查集群与分片，_cat/allocation 看磁盘水位，_cat/thread_pool/search 判断慢查询瓶颈，Logstash 用 _node/stats/pipelines 看 event 流转。

search排障

Elasticsearch 分片未分配排查方法

Elasticsearch 分片长期处于 UNASSIGNED、recovery 卡在 INITIALIZING 时，用 _cat/shards 记录索引与主副本，再调 _cluster/allocation/explain 查看 DISK_WATERMARK、NODE_LEFT、CLUSTER_RECOVERED 等 decider 原因，必要时用 _cluster/reroute 手动分配。

search排障

Elasticsearch 慢查询排查方法

Elasticsearch 查询变慢或聚合超时时，开启 index.search.slowlog 抓取慢 query，用 _nodes/stats/indices/search 观察 query_time，_cat/thread_pool/search 看 active/queue/rejected 判断是 CPU 瓶颈还是队列堆积，再优化聚合、深分页和 wildcard 查询。

search排障

Elasticsearch 集群状态 RED 排查方法

Elasticsearch 集群 health=red、主分片未分配时，用 _cluster/health 记录 unassigned_shards，通过 _cat/shards 和 _cluster/allocation/explain 定位 NODE_LEFT、DISK_FULL 等原因，恢复离线节点、清理磁盘或从副本/快照 reroute 恢复。

search排障

Logstash Pipeline 堵塞排查方法

Logstash pipeline 堵塞、消息堆积或 dead_letter_queue 增长时，用 _node/stats/pipelines 查看 event_in/filtered/out 和 inflight_count 定位卡在 input/filter/output 哪一环，检查 ES 端 429 拒绝和 output duration_in_millis，再调优 pipeline.workers 与 batch.size。

search