## 背景2026年6月22日凌晨4点01分手机弹出一条阿里云监控告警 **云服务器ECS 发生告警** 监控指标(Agent)network.out.rate_IP 的1分钟统计值 报警条件平均值 150 Mibit/s **当前值343.9968 Mibit/s**凌晨4点低峰期业务流量应该是低谷却跑出了白天都少见的高带宽。这到底是正常业务还是出了问题---## 第一步确认报警信息从阿里云控制台拿到关键数据| 字段 | 值 ||------|-----|| 实例 | 一台业务ecs || 监控指标 | network.out.rate_IP出方向网卡速率 || 当前值 | 343.99 Mibit/s ≈ 2.75 Gbit/s || 报警阈值 | 150 Mibit/s || 持续时间 | 0分钟即单次超标 |150 Mibit/s 看起来不高但这是**凌晨4点**的数值。平时业务平均带宽只有5~6 Mibit/s突然跑到344 Mibit/s超了阈值18倍绝对不正常。---## 第二步上服务器看网卡流量登录 ecs执行 sar -n DEV 1 5 看实时网卡IFACE rxpck/s txpck/s rxkB/s txkB/s eth0 312.00 289.00 186.23 22568.00txkB/s 22568 KB/s ≈ **22 MB/s**换算成带宽**22 × 8 176 Mbit/s**在阈值附近抖动。注意这里是 **tx发送** 流量异常不是 rx接收。说明是服务器在向外发数据。---## 第三步排除业务流量### 3.1 查 Tomcat 访问日志凌晨4点前后的 localhost_access_logawk $4[22/Jun/2026:03:5 $4[22/Jun/2026:04:1 \ xxx/tomcat/apache-tomcat-8.5.57-8080/logs/localhost_access_log.*.txt结果凌晨4点窗口内 Tomcat 访问量很低。### 3.2 查 Nginx访问日志因为nginx日志做了压缩解压gunzip -c /usr/local/nginx/logs/backup/access.log_20260622.gz | \ awk $422/Jun/2026:03:5 $422/Jun/2026:04:1 | wc -l凌晨4点窗口请求量虽然多但是都是正常的业务数据。### 3.3 查 神策SDK日志grep 2026:04:0 xxx/logs/2026-06-22/backup_job-*.log发现 04:10 有一个 getEvaluationHall 接口被调用了1万多次但这个接口是广告回调流量不应该跑到 22MB/s。第四步查磁盘活动执行 sar -d 1 10 看磁盘读写Device tps rd_sec/s wr_sec/s await utilvda1 312.00 0.00 **25312.00** 8.23 85.30%有大量磁盘写操作util 85%。但服务器在凌晨4点没有什么写入任务HBR 备份是每天凌晨2点执行的已经结束了。第五步查阿里云控制台 - 快照登录阿里云控制台 → 云服务器 ECS → 快照找到如下事件快照策略: auto2.0_20260623_sp-wz96214dwqj100618y9j快照类型: 自动快照状态: 成功--- 快照1 ---开始时间: 2026-06-23 04:02:06完成时间: 2026-06-23 04:10:14磁盘: /dev/vda--- 快照2 ---开始时间: 2026-23 04:14:03完成时间: 2026-06-23 04:19:40找到了 凌晨4点02分有自动快照在创建。第六步理解快照和带宽的关系ECS 创建快照时发生的是磁盘块读取数据通过内网推送到 OSS 备份。这个过程产生的是服务器出方向tx流量。计算快照写 OSS 内网速率约 22 MB/s换算带宽22 × 8 176 Mbit/s与监控报警的 343 Mibit/s 数值量级吻合监控采集的是1分钟平均值峰值会更高而 HBR混合云备份每天凌晨2点执行03:00:06 已完成与4点报警无关。根因确认ECS 自动快照策略auto2.0凌晨4点触发快照创建磁盘读 22MB/s 推送到 OSS产生出方向带宽峰值触发云监控报警。这不是业务问题也不是攻击是云厂商基础设施行为。处置方案方案一调整快照执行时间推荐阿里云控制台 → 快照策略 → 找到 auto2.0 相关策略 → 将执行时间从 04:00 改为 08:00业务低峰期且不影响当天备份方案二调整监控报警阈值云监控 → 报警规则 → 带宽150M报警 → 阈值调整为 500 Mibit/s留足余量避免正常备份行为触发报警两个方案可以同时执行互不冲突。排查路径回顾报警触发↓sar -n DEV 确认是 tx出方向流量异常↓sar -d 发现大量磁盘写↓排除 Tomcat/Nginx 业务日志零请求↓查 HBR 日志发现 03:00 已完成不是 HBR↓阿里云控制台查快照策略发现 04:02 自动快照执行中↓确认快照创建时磁盘读推 OSS → 出方向带宽峰值经验总结1. 凌晨报警先查基础设施凌晨4点的流量异常业务嫌疑往往最低。HBR备份、自动快照、系统定时任务logrotate、tmp清理等才是高发区。2. sar 是排查利器sar -n DEV 分辨是 tx 还是 rx 异常sar -d 分辨是磁盘读还是写sar -q 看进程负载3. 阿里云相关的基础设施行为往往有规律ECS 自动快照、ESS弹性伸缩、云监控数据上报等这些行为的时间点往往和报警时间高度吻合排查时优先查云控制台的事件记录。4. 报警阈值要结合业务特点设置凌晨4点正常带宽5 Mibit/s150 Mibit/s 的阈值太紧了。阈值应该是日常峰值的3~5倍而不是硬编码一个数字。相关命令速查bash# 查看网卡流量实时sar -n DEV 1 10# 查看磁盘活动sar -d 1 10# 查看HBR备份日志grep 2026-06-22 xxx/aegis/hbrclient/logs/backup_job-*.log# 查看定时任务排除计划任务crontab -lcat /etc/cron.d/*# 查看端口连接分布找外部IP大头ss -tnp state established | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -rn | head -20