番摊机器人 告警突发：凌晨的紧急呼叫
一、告警突发：凌晨的紧急呼叫
凌晨3点30分，一阵急促的电话铃声打破了夜晚的宁静——这是UTC时间的美国站点夜间，却是我们的正常工作时段。值班同事的声音带着焦虑：“生产环境应用响应极慢，大量请求超时，用户已经开始投诉了！”
我的第一反应是排查定时任务：“是不是凌晨的日志备份任务在运行？”登录系统后，确实发现有一个日志备份的CronJob正在执行，它会先将日志压缩写入磁盘，再读取文件通过网络传输到S3存储。但仔细查看任务参数后，我排除了它的嫌疑：这次备份的日志量并不大，远不足以拖垮整个服务。
问题变得扑朔迷离。应用卡顿的症状真实存在，可当前唯一的异常操作却不具备“作案动机”。我决定启动基础设施瓶颈排查的标准流程，从最基础的资源指标入手。
二、常规排查：指标迷雾下的困惑
登录Prometheus+Grafana监控系统，我首先检查了“传统三件套”指标：
CPU使用率：仅20%左右，远未达到瓶颈阈值；
内存占用：维持在50%上下，剩余资源充足；
网络带宽：当前使用量约1Gbps，而EC2实例的基线带宽为3Gbps，尚有大量富余。
接着聚焦磁盘核心指标，挂载的gp3卷性能参数显示：基线IOPS为3000，峰值可达12000。但监控数据显示，当时的读写IOPS仅500余次，远未触及上限。所有常规指标都显示资源充足，可应用的卡顿症状却愈发明显。
就在我陷入困惑时，一个被忽略的指标引起了注意——磁盘IO利用率。Prometheus中的instance_device:node_disk_io_time_seconds:rate5m指标清晰显示，磁盘利用率已达到100%，且持续居高不下。这意味着磁盘正处于满负荷运转状态，所有IO请求都在排队等待处理。
三、真相浮现：吞吐量限制的隐形枷锁
矛盾点出现了：IOPS和网络带宽都未打满，为何磁盘会持续100%繁忙？我将目光转向磁盘吞吐量指标，发现了关键线索：
网络流量通过
node_network_receive_bytes_total计算约为1Gbps；磁盘吞吐量通过
node_disk_bytes_total计算同样约为1Gbps，两者数值几乎完全吻合。
这时我突然想起gp3卷的性能特性：与gp2卷不同，gp3卷的吞吐量是单独计价的，默认基础吞吐量为125MB/s（约1Gbps），且不具备burst积分机制。也就是说，一旦吞吐量达到1Gbps，系统会直接进行硬性限速，所有后续IO请求都会被阻塞。
真相终于水落石出：日志备份任务产生的大量磁盘读写操作，瞬间将gp3卷的吞吐量占满至1Gbps上限。虽然IOPS数值不高，但大流量的数据传输完全占用了磁盘的处理能力。应用的业务请求虽然数据量不大，但也被卷入排队队列，导致响应超时。
为了验证这个结论，我做了两项确认：
对比网络入流量与磁盘写入量，确认两者高度一致，证明磁盘负载完全由数据传输任务导致；
登录AWS控制台检查卷配置，确认该gp3卷确实采用默认的125MB/s吞吐量设置，未购买额外的吞吐量配额。
四、复盘总结：经验与教训
这次排查经历暴露了我们在监控和知识储备上的不足，也积累了宝贵的经验：
值得肯定的地方
监控覆盖全面：通过node_exporter采集了包括磁盘IO利用率在内的完整指标，没有出现监控盲区；
排查流程规范：第一时间从CPU、内存、网络等基础指标入手，逐步缩小排查范围；
数据关联分析：能够通过网络流量与磁盘吞吐量的数值关联，发现问题的核心矛盾点。
需要改进的方向
深化指标理解：此前仅关注IOPS和带宽等显性指标，忽视了磁盘利用率这个反映IO排队情况的关键指标；
强化产品知识：对gp3与gp2卷的性能差异理解不足，尤其是吞吐量限制机制的细节掌握不够；
完善排查手册：需要补充针对不同存储卷类型的专项排查流程，制作性能参数速查表；
优化资源配置：对于有大流量数据传输需求的场景，应提前评估并配置足够的吞吐量配额，避免突发任务影响核心业务。
五、后续优化：构建更稳固的性能防线
针对此次暴露出的问题，我们立即启动了三项优化措施：
调整备份策略：将日志备份任务的执行时间窗口调整至业务低峰期，并采用增量备份方式减少数据传输量；
升级存储配置：为受影响的gp3卷购买了额外的吞吐量配额，将上限提升至500MB/s；
增强监控告警：新增磁盘吞吐量利用率的告警规则，当达到阈值80%时触发预警，提前发现潜在瓶颈。
这次凌晨的告警排查，不仅解决了当前的性能问题，更让我们对AWS存储服务的特性有了更深刻的理解。在云原生环境中，性能瓶颈往往隐藏在看似正常的指标背后，只有建立完善的监控体系、深入掌握产品特性、形成规范的排查流程，才能在复杂的系统环境中快速定位问题，保障业务的稳定运行。
<< 上一篇
下一篇 >>