绝地求生 磁盘写入错误

最近，我们团队负责的基于AWS OpenSearch的日志集群出现了一些问题。起初，部分应用在推送日志时，偶尔会遇到“HTTP 429 Too Many Requests”的错误提示。对于承载大量数据的OpenSearch集群来说，这种情况并不罕见。我们初步判断，可能是瞬时写入压力过大，或者某个仪表盘的访问过于频繁，导致了CPU和JVM内存的负荷增加。

我们通常会首先查看CloudWatch的监控数据，但有时为了更直接地感受集群状态，我们也会使用以下命令进行快速检查：

bash

查看集群健康和节点状况

GET _cat/nodes?v

如果怀疑是写入或搜索线程池满载，我们还会查看线程池的详细情况：

bash

GET _cat/thread_pool?v&h=node_name,name,active,queue,rejected,type,size

这些指标虽然偶尔有波动，但并未达到。这时，一条具体的错误日志引起了我们的注意：“OpenSearch exception [type=cluster_block_exception, reason=index [some-index-name] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];]”这条日志明确指出，“磁盘使用率超过泛滥阶段水位线”。

找到问题原因后，解决起来就相对清晰了。我们首先需要：

1. 诊断磁盘状况：确定哪些节点的磁盘已满。我们使用以下命令查看各节点的磁盘使用情况：

bash

GET _cat/allocation?v&h=node,disk.indices,disk.used,disk.avail,disk.total,disk.percent,shards

果然，有几个数据节点的`disk.percent`已经接近满载。

2. 紧急释放空间：我们需要快速找出可以删除的索引以释放空间。使用以下命令按大小列出所有索引，便于我们找到占用空间较大的旧索引：

bash

GET _cat/indices?v&s=store.size:desc

在确认无误后，我们可以删除不再需要的旧索引（请务必在生产环境中谨慎操作）：

bash

DELETE your-old-index-pattern-2023.01.01

例如：DELETE vehicledeletions-2024.01.

随着磁盘可用空间逐渐恢复，我们的心情也放松了许多。

3. 解除封印：一旦磁盘空间恢复到安全线以下，被“冻结”的索引并不会自动解封。我们需要手动解除封印。使用以下命令针对被锁的索引模式，移除只读块：

bash

PUT /the-blocked-index-/_settings

"index.blocks.read_only_allow_delete": null

例如：PUT /vehicledeletions-/_settings { "index.blocks.read_only_allow_delete": null }

在执行这个命令时，我遇到了一个小插曲——由于手抖误将HTTP方法`PUT`也当作JSON内容发送，导致了`json_parse_exception: Unrecognized token 'PUT'`错误。修正这个小错误后，成功解封索引，写入也恢复正常。

虽然问题解决了，但我们需要反思并加强预防措施。为了避免再次发生类似问题，我们采取了以下措施：

索引生命周期管理 (I)：配置好策略，让OpenSearch自动管理索引的生命周期。通过OpenSearch Dashboards的I界面或API进行设置。

加强监控与告警：在CloudWatch中设置更详细的告警，对磁盘使用率、JVM内存压力等关键指标进行实时监控，一旦有异常迹象立即触发预警。

容量规划：定期审视集群的存储和计算容量，确保满足业务需求。避免再次出现因资源不足导致的问题。希望这次排错经验能为大家提供启示，在遇到类似问题时能够迅速定位并解决。也希望大家能熟练掌握OpenSearch的相关命令行工具，确保集群的稳定运行。