03.混沌工程中磁盘写满实验

 

 

在混沌工程的实践中，“磁盘写满导致只读属性”是一个非常经典且具有破坏力的场景。这个场景直接模拟了线上因异常日志打印引发的雪崩效应（服务崩溃 -> 疯狂写日志 -> 磁盘满 -> 服务变为只读无法写入 -> 彻底不可用）。

结合可观测性平台的建设需求，以下是针对该场景的深度解析及管控闭环建议：

一、 场景深度解析：为什么会导致“只读属性”？

1. Linux 内核机制（只读保护）：当 Linux 系统的根分区（/）或特定挂载点（如 /home、/var）的磁盘使用率达到 100% 时，为了防止文件系统损坏，内核会将该分区强制设置为只读（Read-only）状态。此时，任何写入操作（如数据库事务提交、应用日志落盘、临时文件生成）都会失败，并报错 Read-only file system。

2. 容器化环境的灾难性后果：在 K8s 环境中，如果容器的根文件系统变成只读，或者应用无法向标准输出（stdout）写日志，容器通常会触发 OOMKilled 或直接 CrashLoopBackOff，导致服务彻底不可用。

二、 基于可观测性的“实验-告警”管控闭环

为了验证系统在极端情况下的韧性，可观测性平台需要提供一套完整的管控闭环，确保实验的有效性和系统的安全性。

1. 实验前：配置精准的告警规则（防微杜渐）

在执行 blade create disk fill 之前，需要确保监控系统对磁盘空间有敏锐的感知。建议配置以下三级告警策略：

• Warning 级别（容量预警）：当磁盘使用率超过 80%​ 时触发。

  • 目的：给研发和运维团队预留处理时间，防止事态恶化。

• Critical 级别（高危拦截）：当磁盘使用率超过 90%​ 时触发。

  • 目的：这是服务即将不可用的临界点，需立即介入。

• Error 级别（只读拦截）：监控操作系统级别的 inode 使用率，以及应用层面的错误码（如 HTTP 500 中包含 Read-only file system 关键字）。

  • 目的：直接监控最终的业务影响。

2. 实验中：验证告警的及时性与准确性

执行实验命令后，可观测性平台需要捕捉以下关键指标的突变：

bash

blade create disk fill --path /home --size 50000

• 指标突变点：df -h 显示的可用空间（Avail）迅速下降，Use% 飙升。

• 验证标准：告警系统应在 1-2 分钟内同步触发上述配置的 Critical 告警。如果告警延迟或未触发，说明监控采集或规则配置存在问题。

3. 实验后：通过管控台快速排查（根因定位）

一旦收到磁盘写满的告警，分布式核心项目组的开发人员可以通过以下路径进行排查：

• 第一步：确认爆炸半径（Metrics 平台）

  • 登录 Grafana，查看目标机器的磁盘指标。

  • 关键动作：对比 /home、/var/log、/ 等多个挂载点的使用情况，确认是否波及到了其他目录。

• 第二步：定位“罪魁祸首”（Logging 平台）

  • 在日志系统中搜索该时间段内的最新日志文件。

  • 关键动作：如果发现某个应用进程正在疯狂打印异常堆栈（StackOverflow 或 NPE），即可锁定引发写满的服务实例。

• 第三步：验证服务状态（Application 监控）

  • 查看该服务的健康检查结果（Health Check）和错误率（Error Rate）。

  • 关键动作：确认服务是否已经因为无法写入日志而崩溃或降级。

三、 延伸思考：容错方案的落地验证

场景中提到容错方案是“自动开启清理以及自动切换到正常的终端服务实例”。在执行混沌实验时，可观测性平台不仅是用来“发现问题”，更是用来“验证预案是否有效”：

1. 验证“自动清理”：观察告警触发后，自动清理脚本是否在规定时间内执行，磁盘空间是否被释放。

2. 验证“自动切换”：观察服务网格（Service Mesh）或负载均衡器（SLB/Nginx）是否在主实例不可用后，将流量平滑切到了健康的备用实例。

3. 观测恢复指标：记录从磁盘写满到服务完全恢复的 MTTR（平均修复时间），并将此数据作为系统韧性的量化指标。

四、 给你的行动建议

作为可观测性平台的负责人，你可以向混沌测试负责人和分布式核心项目组提供以下支持：

1. 提供“磁盘写满”专属排查卡片：将上述的 Metrics、Logging、Tracing 排查步骤制作成一张卡片，贴在团队的 Wiki 或监控大屏上，降低排查门槛。

2. 推动日志轮转策略的监控：很多时候磁盘写满是因为日志轮转（Log Rotation）失效。建议在可观测性平台中增加对日志文件大小变化率的监控，提前发现轮转失败的隐患。

3. 建立演练报告模板：要求每次磁盘写满实验后，必须附带一份报告，说明告警触发时间、服务崩溃时间、恢复时间，以及容错方案是否生效。