statch1. Elasticsearch磁盘告急的幕后真相
第一次遇到Elasticsearch集群突然拒绝写入请求时，我正喝着咖啡准备处理当天的日志数据。控制台突然弹出的红色警告让我差点把咖啡喷在键盘上——集群进入了只读模式！后来才知道，这是Elasticsearch的自我保护机制在起作用，就像汽车在油量过低时会自动熄火保护发动机一样。
Elasticsearch的这套保护机制其实非常智能。当磁盘空间不足时，它会分三个阶段逐步限制写入操作：
- 第一阶段（磁盘使用率≥85%）：系统会开始发出黄色警告，就像汽车油表亮起的黄灯，提醒你该加油了
- 第二阶段（≥90%）：系统会阻止创建新索引，但允许现有索引写入
- 第三阶段（≥95%）：彻底进入只读模式，所有写入操作都会被拒绝
我后来在测试环境做过实验，当磁盘使用率达到95%时，连最简单的文档插入都会返回"cluster_block_exception"错误。这种设计虽然会影响业务，但避免了更严重的数据损坏风险——毕竟在磁盘写满的情况下强行写入，轻则数据丢失，重则整个节点崩溃。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 预防胜于治疗：磁盘空间监控方案
吃过一次亏后，我花了两个月时间搭建了一套完整的监控体系。现在我们的生产环境已经连续300多天没触发过只读模式，关键就在于提前预防。
2.1 原生监控方案配置
Elasticsearch自带的监控API其实非常强大，只需要在elasticsearch.yml中添加这几行配置：
yaml复制cluster.routing.allocation.disk.threshold_enabled: true
cluster.routing.allocation.disk.watermark.low: 85%
cluster.routing.allocation.disk.watermark.high: 90%
cluster.routing.allocation.disk.watermark.flood_stage: 95%
配合Kibana的Stack Monitoring功能，可以实时查看每个节点的磁盘使用情况。我特别喜欢它的预警功能——当某个节点达到85%阈值时，我的Slack就会收到这样格式的告警：
code复制[ES磁盘预警] node-1 磁盘使用