深色模式
云上故障排查
摘要：云上排查与自建机房最大的不同是「你摸不到机器」，但云平台提供了专属工具：VNC/串行控制台、实例状态检查、VPC 流日志、快照排查。本文按「进不去、访问慢、服务异常」三类症状给出平台侧排查路径。
适用环境
bash
# 本地终端 + 云 CLI（需在机器失联时能操作云资源）
aws --version
which ssh nc curl mtr
# 机器内排查工具（若能登录）
which dmesg journalctl ss iostat1
2
3
4
5
2
3
4
5
操作步骤
一、症状 A：SSH 进不去
先判断是「网络不通」还是「机器本身挂了」。
bash
# 1) 看平台侧的实例状态检查（这是自建机房没有的能力）
aws ec2 describe-instance-status --instance-id i-0abc \
--query 'InstanceStatuses[].[InstanceState.Name,InstanceStatus.Status,SystemStatus.Status]' --output table
# instance-status 失败 → 机器内部问题（内核、磁盘、进程）
# system-status 失败 → 宿主机/硬件故障，通常需要停机再启动迁移宿主机
# 2) 看控制台截图 / 串行控制台输出（机器卡在开机阶段时特别有用）
aws ec2 get-console-screenshot --instance-id i-0abc --output text | base64 -d > screen.jpg
aws ec2 get-console-output --instance-id i-0abc | tail -50
# 3) 检查安全组与路由是否被改动
aws ec2 describe-security-groups --group-ids sg-0abc \
--query 'SecurityGroups[].IpPermissions[]' --output table
aws ec2 describe-route-tables --filters Name=association.subnet-id,Values=subnet-0abc
# 4) 检查 SSH 服务本身（用串行控制台登录后）
sudo systemctl status sshd
sudo sshd -t && echo "配置语法 OK"
sudo journalctl -u sshd -n 50 --no-pager1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
危险
通过串行控制台/VNC 登录仍需要系统用户名密码。如果机器上从未设置过本地可登录的密码，串行控制台也进不去——所以要在镜像构建阶段就预置一个可用的应急本地账号。
二、症状 B：访问慢 / 时快时慢
bash
# 1) 平台侧网络指标：是否打满带宽或出现限速
aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name NetworkOut \
--dimensions Name=InstanceId,Value=i-0abc \
--start-time 2026-10-09T00:00:00Z --end-time 2026-10-09T12:00:00Z \
--period 300 --statistics Sum --output table
# 2) 逐跳定位
mtr -r -c 30 <目标IP>
# 3) 打开 VPC 流日志，看流量到底有没有被拒绝
aws ec2 create-flow-logs --resource-type VPC --resource-id vpc-0abc \
--traffic-type ALL --log-destination-type cloud-watch-logs \
--log-group-name vpc-flow-logs --deliver-logs-permission-arn arn:aws:iam::123456789012:role/flowlogs
# 4) 机器内看磁盘 IO 是否被拖慢（云盘 IOPS 有上限）
iostat -x 1 5
# %util 接近 100 且 await 很高 → 磁盘瓶颈1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
三、症状 C：机器在但服务异常
bash
# 1) 先看负载均衡视角：后端是否健康
aws elbv2 describe-target-health --target-group-arn arn:aws:...web-tg \
--query 'TargetHealthDescriptions[].[Target.Id,TargetHealth.State,TargetHealth.Description]' --output table
# 2) 对比「打 LB」与「直连实例」，判断问题在哪一层
curl -s -o /dev/null -w "LB: %{http_code} %{time_total}\n" http://<ALB域名>/
curl -s -o /dev/null -w "直连: %{http_code} %{time_total}\n" http://<实例内网IP>:8080/
# 3) 看平台事件（计划内维护、宿主机退役等常被忽略）
aws ec2 describe-instance-status --instance-id i-0abc \
--query 'InstanceStatuses[].Events[]'1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
四、终极手段：离线排查快照
当机器完全无法启动，又必须保留现场时：
bash
# 1) 对系统盘打快照（不影响原盘）
aws ec2 create-snapshot --volume-id vol-0abc --description "crash-20261009"
# 2) 从快照创建新卷，挂载到一台正常的救援机上
aws ec2 create-volume --snapshot-id snap-0abc --availability-zone ap-east-1a
aws ec2 attach-volume --volume-id vol-new --instance-id i-rescue --device /dev/xvdf
# 3) 在救援机上只读挂载并检查日志
sudo mount -o ro /dev/xvdf1 /mnt
sudo tail -n 200 /mnt/var/log/messages
sudo grep -i "oom\|panic" /mnt/var/log/messages | tail -201
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
注意
排查用卷必须以只读方式挂载（mount -o ro）。以读写方式挂载 ext4/xfs 再卸载可能触发文件系统修复，破坏原始现场。
五、事后必做的两件事
- 保存现场：导出 console output、监控截图、流日志片段，避免实例被回收后线索消失。
- 写故障记录：时间线、根因、影响面、改进项。云上资源随时可能被伸缩组替换，不记录就等于没发生过。
验证
- [ ] 能用 CLI 查到实例状态检查与系统事件
- [ ] 串行控制台可用，且镜像内预置了应急账号
- [ ] VPC 流日志已开启，能查到被拒绝的流量记录
- [ ] 演练过一次「从快照挂载到救援机」的完整流程
常见坑
- 机器一挂就重启：重启后内存中的现场（OOM 进程、panic 信息）全部丢失，务必先抓 console output 和截图。
- 串行控制台没密码：镜像里没预置应急账号，真正进不去时才发现。
- 只看应用层不看平台：宿主机故障、AZ 级故障这类只有平台侧指标能看到。
- 忘记关 VPC 流日志：长期全量采集会产生可观的费用，排查完应及时关闭或降采样。
- 被伸缩组自动替换：排查中途实例被判定不健康而回收，现场消失——排查期间可临时暂停伸缩的替换动作。