1. 当深夜告警轰炸你的手机时
凌晨3点15分,手机突然开始疯狂震动。连续十几条告警短信让你的心跳瞬间加速——服务器CPU负载突破95%,磁盘I/O延迟超过500ms,关键业务接口成功率跌至60%。作为运维人员,这种场景你一定不陌生。但面对海量的监控指标和日志,从哪里开始排查?先看CPU还是先查磁盘?网络问题还是代码缺陷?
这就是为什么我们需要一份清晰的"作战地图"。不同于普通的检查清单,真正的故障排查需要建立系统化的思维框架。就像急诊医生面对危重病人时,会按照ABC(Airway-Breathing-Circulation)原则优先处理最关键的生命体征,服务器故障排查同样需要分层次、有重点的推进策略。
2. 构建四层诊断模型:从宏观到微观的排查路径
2.1 第一层:基础设施健康度速查
当告警响起时,首先运行这套组合命令快速获取系统全景:
bash复制# 系统负载与CPU
uptime; mpstat -P ALL 1 3; top -b -n 1 | head -15
# 内存与交换分区
free -h; vmstat 1 5
# 磁盘I/O
iostat -x 1 3; df -h; dmesg | grep -i 'error\|oom'
# 网络状况
ss -s; netstat -s | grep -i 'drop\|error'; ping -c 4 <网关IP>
这个检查清单的设计逻辑是:先看整体负载(uptime),再细分CPU各核心利用率(mpstat),接着检查是否有进程异常占用资源(top)。内存检查要同时关注free内存和swap使用情况,因为某些Java应用可能在free内存充足时就开始使用swap。磁盘检查必须包含inode使用率(df -i),这是许多"磁盘未满但无法写入"问题的元凶。
2.2 第二层:服务依赖拓扑分析
现代分布式系统的故障往往源于服务间依赖问题。使用这些命令绘制服务依赖图:
bash复制# 查看开放端口与服务
ss -tulnp; lsof -i :<端口号>
# 进程树分析
pstree -pan <PID>; systemctl list-dependencies <服务名>
# 网络连接追踪
tcpdump -i eth0 -nn 'host <目标IP> and port <端口号>' -w /tmp/debug.pcap
我曾遇到一个典型案例:某核心服务超时,实际原因是其依赖的Redis连接数被某个异常脚本耗尽。通过ss -s发现TCP连接数异常增长,再用lsof定位到具体进程,最终找到那个忘记关闭连接的Python脚本。
2.3 第三层:应用级深度诊断
当基础设施正常时,问题可能出在应用本身。这些命令能帮你深入应用内部:
bash复制# Java应用
jstat -gcutil <PID> 1000 5; jstack <PID> > /tmp/thread_dump.log
# 容器环境
docker stats --no-stream; docker inspect <容器ID> | grep -i 'error\|fail'
# 日志实时分析
tail -n 200 /var/log/<服务>/error.log | grep -A 10 -B 10 'ERROR\|Exception'
特别提醒:Java应用的GC日志一定要配置-XX:+PrintGCDetails,这是排查内存泄漏的黄金标准。某次线上事故中,我们通过jstat发现Full GC频率从每小时1次突然增加到每分钟5次,立即触发回滚避免了OOM崩溃。
2.4 第四层:内核级疑难杂症
对于涉及内核参数的复杂问题,这些工具能提供底层视角:
bash复制# 系统调用追踪
strace -ff -T -tt -p <PID> -o /tmp/strace.log
# 内核日志
journalctl -k --since "10 minutes ago" | grep -i 'oom\|kill'
# 性能剖析
perf top -p <PID>; perf record -g -p <PID> -- sleep 30
曾经有个诡异案例:某服务每隔几小时就会卡顿30秒。最终通过perf record发现是透明大页(THP)的碎片整理导致,在/etc/sysctl.conf添加vm.nr_hugepages=1024后问题消失。
3. 经典故障模式与速查手册
3.1 CPU飙高问题排查流程
- 定位异常进程:
top -c查看%CPU列 - 分析线程级负载:
top -H -p <PID> - 查看系统调用:
pidstat -t -p <PID> 1 5 - 检查用户态/内核态时间:
pidstat -u -p <PID> 1 5 - 生成火焰图:
bash复制perf record -F 99 -g -p <PID> -- sleep 30 perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > cpu.svg
经验之谈:如果发现sys%异常高,常见原因是线程上下文切换过多(vmstat 1看cs列)或系统调用频繁(通过strace统计)。
3.2 内存泄漏定位方法
- 监控内存趋势:
watch -n 1 'free -h' - 检查slab占用:
slabtop -o - 进程内存详情:
pmap -x <PID> - Java堆分析:
bash复制jmap -histo:live <PID> | head -20 jmap -dump:live,format=b,file=heap.hprof <PID> - GDB内存分析(谨慎使用):
bash复制
gdb -p <PID> (gdb) dump memory /tmp/mem.dump 0x<start_addr> 0x<end_addr>
关键技巧:在容器环境中,docker stats显示的内存可能包含缓存,真实内存压力要看/sys/fs/cgroup/memory/memory.usage_in_bytes。
3.3 磁盘I/O问题排查指南
- 确认I/O等待:
top看%wa,iostat -x 1看%util和await - 定位高IO进程:
iotop -oP - 分析文件操作:
lsof +D /path/to/dir - 检查文件系统错误:
fsck -y /dev/sdX - LVM诊断:
lvdisplay、vgdisplay
血泪教训:某次RAID卡电池故障导致writeback缓存失效,磁盘性能骤降。通过smartctl -a /dev/sdX发现Media_Wearout_Indicator异常才定位问题。
4. 构建你的自动化排查工具包
4.1 常用诊断脚本集
bash复制#!/bin/bash
# 系统快照脚本
echo "===== $(date) =====" > /tmp/system_snapshot.log
echo "---- Load Average ----" >> /tmp/system_snapshot.log
uptime >> /tmp/system_snapshot.log
echo "---- Memory Usage ----" >> /tmp/system_snapshot.log
free -h >> /tmp/system_snapshot.log
echo "---- Disk Space ----" >> /tmp/system_snapshot.log
df -h >> /tmp/system_snapshot.log
# 更多检查项...
4.2 日志分析三板斧
-
时间范围过滤:
bash复制sed -n '/2023-08-01 14:00:00/,/2023-08-01 15:00:00/p' app.log -
关键错误提取:
bash复制awk '/ERROR/{print $0; getline; print $0}' app.log | less -
统计排序:
bash复制grep -oP 'Exception: \K.*' app.log | sort | uniq -c | sort -nr
4.3 网络问题诊断包
bash复制# 连通性测试
mtr -n -c 100 <目标IP>
# 带宽测试
iperf3 -c <服务器IP> -t 30 -i 5
# HTTP请求分析
curl -v -o /dev/null -s -w """
time_namelookup: %{time_namelookup}
time_connect: %{time_connect}
time_appconnect: %{time_appconnect}
time_total: %{time_total}\n""" https://example.com
5. 预防胜于治疗:构建防御性运维体系
5.1 监控指标黄金四件套
- 基础资源:CPU、内存、磁盘、网络
- 服务健康:响应时间、错误率、吞吐量
- 业务指标:订单量、支付成功率
- 日志指标:ERROR日志频率、异常堆栈类型
5.2 告警分级策略示例
| 级别 | 条件 | 响应时间 | 通知方式 |
|---|---|---|---|
| P0 | 核心业务不可用 | 5分钟 | 电话+短信 |
| P1 | 性能严重下降 | 15分钟 | 企业微信 |
| P2 | 潜在风险 | 1小时 | 邮件 |
5.3 混沌工程实践清单
- 随机杀死节点:
kill -9 $(ps -ef | grep <服务> | awk '{print $2}') - 网络延迟注入:
tc qdisc add dev eth0 root netem delay 100ms - 磁盘空间模拟:
fallocate -l 10G /var/log/fake_disk_full - CPU压力测试:
stress -c 4 -t 300
6. 我的故障排查兵器谱
经过多年实战,这些工具已成为我的"瑞士军刀":
- 性能分析:perf、bpftrace、BCC工具集
- 日志处理:lnav、jq、mlr
- 网络诊断:tcpdump、wireshark、tshark
- 系统检查:sysdig、htop、glances
- 可视化分析:Grafana、Kibana、Prometheus
特别推荐bpftrace,可以用单行命令实现复杂诊断:
bash复制# 跟踪文件打开
bpftrace -e 'tracepoint:syscalls:sys_enter_open { printf("%s %s\n", comm, str(args->filename)); }'
记住,最好的工具是你的系统化思维。下次当告警在深夜响起时,深呼吸,拿出这份地图,从外到内层层剖析,你一定能快速定位问题根源。毕竟,我们不是在解决告警,而是在守护用户体验。
