监控linux磁盘写延迟需聚焦w_await与%util，用iostat -dx定位设备瓶颈，iotop+lsof识别写进程，脚本阈值告警（如连续3次超15ms），辅以ioping验证真实写延迟。
监控 Linux 系统磁盘写延迟并自动通知，关键在于准确采集写操作的响应时间（尤其是 w_await），结合进程级写行为识别，并在超出业务可接受阈值时触发告警。不依赖主观猜测，而是用工具链分层验证。
盯紧写延迟核心指标：w_await 与 %util
iostat -x 是第一道防线，必须针对性监控目标设备（如数据库数据盘 /dev/sdb）：
- 运行 iostat -dx /dev/sdb 1，跳过首行历史均值，专注实时流
- 重点看 w_await（写请求平均等待时间），而非笼统的 await：SSD/NVMe 超过 5ms 就需关注，持续 >20ms 很可能拖慢事务；HDD 超过 15ms 即偏高
- 同步观察 %util：若 w_await 高但 %util 远低于 100%，说明写请求在队列堆积（并发压过调度能力），不是磁盘本身慢
- 避免只看汇总：多盘系统中，iostat -x 1 默认汇总所有设备，易掩盖单盘瓶颈
定位真实写入源头：iotop + lsof 闭环验证
高 w_await 时，立刻确认是哪个进程在持续写：
- 执行 iotop -o -b -n 1，只显示正在 I/O 的进程，抓取 IO%、DISK WRITE 列
- 对高 IO% 进程，用 lsof -p PID 查它打开的文件，确认是否在写日志、刷脏页或归档数据
- 特别注意 systemd-journald、rsyslogd、数据库后台进程（如 postgres writer）、备份脚本等常见写源
- 若发现大量“deleted”文件被写（lsof +L1），说明有进程仍在向已删文件句柄写入，占空间又不释放
设置可落地的自动通知机制
用轻量脚本实现阈值判断与通知，避免过度依赖复杂平台：
- 定义合理阈值：例如 THRES_W_AWAIT=15（单位 ms），针对 SSD 可设为 8，HDD 可设为 25
- 每分钟执行一次检测：iostat -dx /dev/sdb 1 2 | tail -1 | awk '{if ($11 > ENVIRON["THRES_W_AWAIT"]) print "ALERT: w_await=" $11 "ms"}'
- 告警通道选最稳的：用 mail 命令发邮件（需提前配好 ssmtp 或 mutt），或写入本地日志后由 logrotate 触发外部通知
- 加防抖逻辑：连续 3 次超阈值再告警，避免瞬时尖峰误报；同时记录 w_await 历史值到日志，便于回溯趋势
补充验证手段：绕过缓存测真实写延迟
当怀疑应用层 sync 行为异常或存储栈某层引入延迟时，用 ioping 直击底层：
- 安装 ioping：apt install ioping（Debian/Ubuntu）或 yum install ioping（RHEL/CentOS）
- 强制落盘测试：ioping -C -c 5 /dev/sdb，-C 确保每次写都 sync，返回 avg 值即真实设备写延迟
- 对比结果：若 ioping avg 明显低于 iostat w_await，说明延迟主要来自内核队列或上层（如文件系统 journal、RAID 卡缓存策略）
