凌晨 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 快件（业务请求），只能等着，自然就超时了。

🛠️ 如何确认这个猜想？

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

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

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

👍️ 做得好的地方

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

👎 需要改进的地方

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

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

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

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

🤔对云服务的更多思考

经历了这次问题, 我专门查找了相关的资料, 发现云服务的限制不止这些.

云服务虽带来弹性与可扩展性，但网络节流（带宽限制）常被忽视，是导致应用响应慢、卡顿的重要原因。即便CPU、内存等指标正常，网络节流仍会通过丢包、重传大幅增加延迟，引发服务中断、性能不稳定，甚至造成数百万美元收入损失。

核心问题

• 云服务商（AWS、Azure、GCP等）根据实例大小设定带宽基线，超出后触发自动节流（如AWS的突发积分耗尽后降速）。
• 节流规则复杂、不透明，传统监控（如仅测RTT）无法有效识别，NTP精度不足，PTP成本高。

常见场景与解决方案

• 持续高利用率：升级实例、负载分散、智能缓存。
• 微突发（Microburst）：应用级限速、流量整形、高粒度监控。

未来应对策略

• 实施实时单向延迟监控。
• 架构设计考虑弹性，容忍带宽限制。
• 平衡实例大小与网络需求，避免过度配置。
• 建立性能基线，主动测试。
• 核心转变：从反应式扩缩容转向主动自动化延迟自愈，将网络节流管理视为业务必需，而非仅IT问题。

📝总结

排查应用故障，不能只看「有多少水（IOPS）」，更要关注「水的流速（吞吐量）」和「水管子堵不堵（IO 利用率）」。

📚️参考文档

1. Amazon EBS 卷类型 - AWS 官方文档
2. 监控 Amazon EBS 卷 - CloudWatch 指标
3. node_exporter 磁盘指标说明
4. Cloud Apps Slow? Network Throttling Could Be Why