当前位置：首页 > news >正文

凌晨告警排查记：一次AWS EBS磁盘IO利用率100%的真相

news 2026/5/24 15:51:36

凌晨 3:30(其实是UTC时间, 美国站点的晚上, 我们这边正常上班时间, 嘿嘿嘿)，电话响了。心里咯噔一下：这个时间点的告警，十有八九不是什么好事。果然，值班同事反馈应用变得特别慢，大量请求超时，用户已经开始骂了。

我第一反应：是不是有什么 job 跑起来了？比如凌晨的日志备份。

查了一圈，发现确实有一个日志备份(先压缩写入, 再读取通过网络传到S3上去)的 cronjob 正在执行。正当我以为是元凶时，仔细一看，这 job 的日志量不算大，不至于把服务搞趴。但问题又确确实实发生了，那个时间点也只有这一个明显的操作。

好吧，排障的经典套路来了：先看基础设施层面有没有瓶颈。

💥 常规指标一切正常？

登录监控系统（Prometheus + Grafana），先扫了一眼传统三件套：

CPU：不高，才 20% 左右。
内存：也正常，50% 左右。
网络：带宽用了 1Gbps 左右，而 EC2 实例的基线带宽是 3Gbps，离打满还远着呢。
磁盘 IOPS：EC2 跑的应用，挂载的是 gp3 卷，IOPS 基线 3000，峰值可以飙到 12000 左右。当时的读写 IOPS 也就 500 多，也没达到上限。

这数据看着好像没什么问题……那应用为什么会慢？

等等。

有个指标被我忽略了——磁盘 IO 利用率。

🐾 注意：
Prometheus 中的 node_disk_io_time_seconds 或 rate() 化之后，(具体是: instance_device:node_disk_io_time_seconds:rate5m)
反映的是磁盘完成 IO 请求所花费的时间占比，可以理解为磁盘的 '忙碌程度'。
如果这个值维持在 100%，说明磁盘一直是满负荷运转的，IO 请求排着队，应用能不卡吗。

赶紧查了下这个指标，好家伙，直接 100%！

这就矛盾了：明明 IOPS 和网络带宽都没打满，为啥磁盘会一直 100% 忙？

🔍 隐藏的凶手：gp3 卷的吞吐量限制

这时候我突然觉得不对劲，仔细看了下网络流量和磁盘的指标。

网络流量：通过 node_network_receive_bytes_total 计算，大约 1Gbps。
磁盘吞吐量：通过 node_disk_bytes_total 计算，也是大约 1Gbps，和网卡流量几乎完全吻合。

等等，gp3 卷的吞吐量上限是多少？

AWS 官网写得明明白白：gp3 卷的吞吐量单独计价，基础的吞吐量是 125 MB/s（约 1 Gbps）。不像 gp2, 如果你的 IOPS 和吞吐量都超出了基线，可以利用积分（burst credits），但一旦积分耗尽，吞吐量就会被硬性限制在 1 Gbps。
gp3 卷的吞吐量上限默认就是 125 MB/s（约 1 Gbps）, burst 不了。除非你提前花钱买额外的吞吐量.

🤔 网卡流量 1 Gbps，磁盘吞吐量 1Gbps？这显然已经达到了 gp3 卷的 1Gbps 吞吐量限制。

真相只有一个：日志备份 job 产生了大量的磁盘写入/读取，瞬间吃光了 gp3 卷的吞吐量积分，导致后续所有的 IO 请求都被限速。 应用发起的业务请求虽然 IOPS 不高，但数据量不小，也被堵在了队列里。磁盘 IO 利用率 100%，并非 IOPS 不够，而是吞吐量被卡住了。

这就像是：一个快递站（gp3 卷）的处理速度（吞吐量）是固定的，突然来了一大卡车货（日志备份），把整条传送带占满了。后面来的一箱箱 VIP 快件（业务请求），只能等着，自然就超时了。

🛠️ 如何确认这个猜想？

为了验证，我快速查了以下信息：

对比网络入流量和磁盘写入量：确认两者高度一致，都达到了 1Gbps。这说明磁盘写入和网络流量是'一路货'。
确认 gp3 卷的吞吐量配置：检查控制台，确认该卷的吞吐量配置确实是默认的 125MB/s（1Gbps）。

🤔 这次排查教会了我们什么？

👍️ 做得好的地方

监控覆盖全面：我们部署了 node_exporter，采集了磁盘 IO 利用率、IOPS、网络带宽等几乎全部的关键指标，没有出现盲区。
常规指标都排查了：第一时间排查了 CPU、内存、IOPS、带宽，这是非常正确的第一反应。
数据对比能力强：能迅速对比网络流量和磁盘吞吐量，发现两者数值吻合，这是最关键的一步。

👎 需要改进的地方

对监控指标理解不够深：只关注了 "IOPS" 和 "带宽" 是否打满，而忽视了 IO 利用率 这个关键指标。它才是反映"应用是否在排队等待 IO"的望远镜。
对 AWS 卷类型特性不熟：虽然最后发现是 gp3 限速，但排查过程中对 gp3/gp2 等不同卷类型的 IOPS/吞吐量/积分机制 缺乏系统了解。当时是 gp3，真真切切被它坑了。
- 😱 所以，一个"卷性能速查表"是多么重要。
排查流程不够完整：排查时，应该在"常规指标正常"后就立刻转向磁盘 IO 队列深度（instance_device:node_disk_io_time_weighted_seconds:rate5m），这是判断 IO 是否真的 '拥堵' 的核心指标，而不是只看利用率。

💡 写在最后：一份实用的 EBS 性能排查清单

这次 Case 让我意识到，很多'云原生' '云计算'的坑，都是对底层基础设施的'一知半解'导致的。以后排查类似问题，建议按以下顺序走：

看现象：应用慢、超时。
扫硬件：CPU、内存、IOPS、带宽。
- ⚠️ 如果这些指标都正常，立刻进入第三步。
看 IO 队列：检查 instance_device:node_disk_io_time_weighted_seconds:rate5m 指标，判断是否有 IO 拥堵。
- 如果 IO 队列高，但 IOPS 不高，大概率是吞吐量或 IO 模型问题。
对比流量：查看网卡流量和磁盘写入/读取吞吐量，看它们是否匹配。
验证假设：
- 确认是 EBS 限速？根据EBS类型判断是查 BurstBalance 指标, 还是查 IOPS 和吞吐量等指标。
- 确认是应用 IO 模型问题？分析具体是哪个文件的读写导致 IO 高（如 /var/log 的日志）。
调整配置：
- EBS 限速：升级卷类型（如 gp3 → io2）或调整吞吐量基线。
- 应用问题：优化日志输出（如异步、批量、减少日志级别），调整 cronjob 的执行周期或错峰, 日志备份限速等。