1. 为什么需要一份Linux故障排查作战地图凌晨3点15分刺耳的告警铃声把你从睡梦中惊醒。手机屏幕上密密麻麻的报警信息让你瞬间清醒——服务器CPU负载爆表、磁盘空间告急、关键服务无响应。作为运维人员这种深夜惊魂的场景你一定不陌生。在高压和困倦的双重夹击下如何快速定位并解决问题这就是我们需要一份系统化作战地图的原因。2. 作战地图核心框架设计2.1 故障分类体系根据多年实战经验我将Linux服务器故障划分为六大核心战区资源枯竭型CPU、内存、磁盘、IO等硬件资源耗尽服务异常型关键进程崩溃、服务无响应网络连通型网络延迟、丢包、端口不可达配置错误型参数设置不当、文件权限错误安全攻击型恶意扫描、暴力破解、DDoS依赖故障型数据库、中间件等下游服务异常2.2 排查工具矩阵每个战区配备专属武器库故障类型核心工具关键指标CPU问题top, vmstat, pidstat, perfus% 70%, sy% 30%, wa% 20%内存问题free, vmstat, slabtopMemAvailable 10%, swap使用30%磁盘IOiostat, iotop, dmesgutil% 80%, await 50ms网络问题ping, traceroute, tcpdump, ss丢包率1%, 延迟100ms进程异常ps, pstree, strace, lsof僵尸进程数, OOM killer记录3. 实战排查流程详解3.1 资源类故障排查路径场景示例收到CPU负载告警load average达到154核服务器快速定位热点进程top -c -o %CPU # 按CPU排序 pidstat -u 1 5 # 细粒度进程统计分析系统调用perf top -g # 实时函数级热点 strace -p PID # 跟踪可疑进程常见问题特征用户态CPU高业务代码存在死循环系统态CPU高频繁系统调用或上下文切换IO等待高磁盘成为瓶颈经验当CPU负载高但使用率低时很可能是IO等待导致此时应优先检查磁盘性能3.2 服务异常排查手册典型场景Nginx返回502 Bad Gateway服务状态检查systemctl status nginx --no-pager journalctl -u nginx -n 50 --no-pager后端健康检查curl -I http://upstream_server/health telnet upstream_ip 8080连接池分析ss -tnp | grep nginx # 查看连接状态 netstat -s | grep -i drop\|timeout # 统计错误4. 高级排查技巧汇编4.1 内存泄漏定位术监控工具组合拳watch -n 1 free -m; echo; slabtop -o -s cpmap深度分析pmap -x PID | sort -nk3 | tail -10valgrind内存检测valgrind --leak-checkfull ./your_program4.2 网络问题终极排查当常规ping/traceroute无法定位时全链路抓包分析tcpdump -i eth0 -w /tmp/debug.pcap host 10.0.0.1TCP状态机诊断ss -t4 state time-wait | wc -l # 统计TIMEWAIT状态内核参数检查sysctl -a | grep -E net.ipv4.tcp|net.core5. 排查工具箱增强方案5.1 自动化巡检脚本#!/bin/bash # 系统健康检查脚本 check_cpu() { local threshold80 local usage$(top -bn1 | grep Cpu(s) | sed s/.*, *\([0-9.]*\)%* id.*/\1/ | awk {print 100 - $1}) (( $(echo $usage $threshold | bc -l) )) \ echo [CRITICAL] CPU usage ${usage}% ${threshold}% } check_memory() { local threshold90 local free$(free | awk /Mem/{printf %.0f, $3/$2*100}) (( $free $threshold )) \ echo [CRITICAL] Memory usage ${free}% ${threshold}% } # 添加更多检查项...5.2 历史问题知识库建议建立包含以下字段的故障案例库故障现象描述完整排查过程根本原因分析解决方案预防措施6. 避坑指南那些年踩过的雷日志陷阱/var/log空间占满导致服务异常定期轮转日志logrotate -f /etc/logrotate.conf关键目录监控df -h /var/log权限黑洞误操作chmod -R导致系统崩溃关键目录保护chattr i /usr/bin操作前备份tar -zcpf backup.tar.gz /path配置误区sysctl参数调整引发连锁反应变更前记录sysctl -a sysctl_backup.conf灰度验证先在测试环境验证参数变更7. 应急响应checklist当半夜收到告警时按此清单有序处理[ ] 确认告警真实性是否误报[ ] 评估影响范围单点还是全局[ ] 收集基础信息系统负载、网络状态[ ] 定位问题进程top/ps/ss[ ] 分析日志线索/var/log, journalctl[ ] 实施临时方案重启/扩容/降级[ ] 记录完整过程时间线操作[ ] 次日深度复盘根因分析8. 性能优化进阶路线对于想深入Linux性能优化的同学建议掌握BPF工具链bpftrace动态追踪BCC工具集opensnoop, execsnoop内核调优调度器参数sched_latency_ns内存回收策略vm.swappiness架构级优化NUMA绑核优化IRQ中断平衡9. 推荐学习资源书籍《Linux性能优化大师》《BPF之巅》工具sysdig, netdata, GrafanaPrometheus社区Linux内核邮件列表Perf专题会议这份作战地图是我在数百次深夜故障处理中积累的实战经验。建议打印出来贴在工位或保存为手机备忘录。记住好的运维不是不遇到问题而是能快速消灭问题。
1. 为什么需要一份Linux故障排查作战地图凌晨3点15分刺耳的告警铃声把你从睡梦中惊醒。手机屏幕上密密麻麻的报警信息让你瞬间清醒——服务器CPU负载爆表、磁盘空间告急、关键服务无响应。作为运维人员这种深夜惊魂的场景你一定不陌生。在高压和困倦的双重夹击下如何快速定位并解决问题这就是我们需要一份系统化作战地图的原因。2. 作战地图核心框架设计2.1 故障分类体系根据多年实战经验我将Linux服务器故障划分为六大核心战区资源枯竭型CPU、内存、磁盘、IO等硬件资源耗尽服务异常型关键进程崩溃、服务无响应网络连通型网络延迟、丢包、端口不可达配置错误型参数设置不当、文件权限错误安全攻击型恶意扫描、暴力破解、DDoS依赖故障型数据库、中间件等下游服务异常2.2 排查工具矩阵每个战区配备专属武器库故障类型核心工具关键指标CPU问题top, vmstat, pidstat, perfus% 70%, sy% 30%, wa% 20%内存问题free, vmstat, slabtopMemAvailable 10%, swap使用30%磁盘IOiostat, iotop, dmesgutil% 80%, await 50ms网络问题ping, traceroute, tcpdump, ss丢包率1%, 延迟100ms进程异常ps, pstree, strace, lsof僵尸进程数, OOM killer记录3. 实战排查流程详解3.1 资源类故障排查路径场景示例收到CPU负载告警load average达到154核服务器快速定位热点进程top -c -o %CPU # 按CPU排序 pidstat -u 1 5 # 细粒度进程统计分析系统调用perf top -g # 实时函数级热点 strace -p PID # 跟踪可疑进程常见问题特征用户态CPU高业务代码存在死循环系统态CPU高频繁系统调用或上下文切换IO等待高磁盘成为瓶颈经验当CPU负载高但使用率低时很可能是IO等待导致此时应优先检查磁盘性能3.2 服务异常排查手册典型场景Nginx返回502 Bad Gateway服务状态检查systemctl status nginx --no-pager journalctl -u nginx -n 50 --no-pager后端健康检查curl -I http://upstream_server/health telnet upstream_ip 8080连接池分析ss -tnp | grep nginx # 查看连接状态 netstat -s | grep -i drop\|timeout # 统计错误4. 高级排查技巧汇编4.1 内存泄漏定位术监控工具组合拳watch -n 1 free -m; echo; slabtop -o -s cpmap深度分析pmap -x PID | sort -nk3 | tail -10valgrind内存检测valgrind --leak-checkfull ./your_program4.2 网络问题终极排查当常规ping/traceroute无法定位时全链路抓包分析tcpdump -i eth0 -w /tmp/debug.pcap host 10.0.0.1TCP状态机诊断ss -t4 state time-wait | wc -l # 统计TIMEWAIT状态内核参数检查sysctl -a | grep -E net.ipv4.tcp|net.core5. 排查工具箱增强方案5.1 自动化巡检脚本#!/bin/bash # 系统健康检查脚本 check_cpu() { local threshold80 local usage$(top -bn1 | grep Cpu(s) | sed s/.*, *\([0-9.]*\)%* id.*/\1/ | awk {print 100 - $1}) (( $(echo $usage $threshold | bc -l) )) \ echo [CRITICAL] CPU usage ${usage}% ${threshold}% } check_memory() { local threshold90 local free$(free | awk /Mem/{printf %.0f, $3/$2*100}) (( $free $threshold )) \ echo [CRITICAL] Memory usage ${free}% ${threshold}% } # 添加更多检查项...5.2 历史问题知识库建议建立包含以下字段的故障案例库故障现象描述完整排查过程根本原因分析解决方案预防措施6. 避坑指南那些年踩过的雷日志陷阱/var/log空间占满导致服务异常定期轮转日志logrotate -f /etc/logrotate.conf关键目录监控df -h /var/log权限黑洞误操作chmod -R导致系统崩溃关键目录保护chattr i /usr/bin操作前备份tar -zcpf backup.tar.gz /path配置误区sysctl参数调整引发连锁反应变更前记录sysctl -a sysctl_backup.conf灰度验证先在测试环境验证参数变更7. 应急响应checklist当半夜收到告警时按此清单有序处理[ ] 确认告警真实性是否误报[ ] 评估影响范围单点还是全局[ ] 收集基础信息系统负载、网络状态[ ] 定位问题进程top/ps/ss[ ] 分析日志线索/var/log, journalctl[ ] 实施临时方案重启/扩容/降级[ ] 记录完整过程时间线操作[ ] 次日深度复盘根因分析8. 性能优化进阶路线对于想深入Linux性能优化的同学建议掌握BPF工具链bpftrace动态追踪BCC工具集opensnoop, execsnoop内核调优调度器参数sched_latency_ns内存回收策略vm.swappiness架构级优化NUMA绑核优化IRQ中断平衡9. 推荐学习资源书籍《Linux性能优化大师》《BPF之巅》工具sysdig, netdata, GrafanaPrometheus社区Linux内核邮件列表Perf专题会议这份作战地图是我在数百次深夜故障处理中积累的实战经验。建议打印出来贴在工位或保存为手机备忘录。记住好的运维不是不遇到问题而是能快速消灭问题。
