1. 服务器错误排查的核心思路当服务器出现异常时很多运维人员会陷入头痛医头、脚痛医脚的困境。实际上优雅的排查应该遵循系统化的方法论。我总结了一套三层定位法1.1 现象层快速症状识别首先需要明确问题的外在表现特征服务响应缓慢SSH卡顿、API超时监控指标异常CPU/内存/磁盘持续高位服务中断进程被kill、实例重启连接失败SSH拒绝、端口不通重要提示记录问题发生的时间点、影响范围和异常指标的具体数值这些信息对后续分析至关重要。1.2 资源层瓶颈定位分析通过系统工具快速锁定资源瓶颈点CPU问题特征load average CPU核心数%user或%system持续高位runq-sz进程队列堆积内存问题特征free内存接近0swap使用率持续增长oom_killer频繁触发I/O问题特征%iowait 20%await延迟 20ms%util接近100%1.3 根因层进程级诊断定位到具体的问题进程后需要进一步分析对于Java应用使用jstack抓取线程栈分析是否存在锁竞争或死循环对于C/C程序通过perf工具生成火焰图定位热点函数对于数据库检查慢查询日志分析执行计划2. 必备排查工具链2.1 实时监控三件套# 综合监控 htop # 动态进程查看 top -c # 系统负载概览 glances这些工具可以实时显示CPU、内存、IO等关键指标按F6可以切换不同的排序方式。我的习惯是先用top看整体负载再用htop看具体进程最后用glances检查网络和磁盘2.2 历史数据分析工具# 安装sysstat包 sudo yum install -y sysstat # CentOS sudo apt-get install -y sysstat # Ubuntu # 查看CPU历史数据 sar -u -f /var/log/sa/sa$(date %d -d yesterday) # 查看内存历史数据 sar -r -f /var/log/sa/sa$(date %d -d yesterday) # 查看IO历史数据 sar -d -f /var/log/sa/sa$(date %d -d yesterday)经验之谈sar数据默认保存一个月对于周期性出现的问题特别有用。比如每周一早上出现的CPU高峰可以通过历史数据对比分析。2.3 网络排查工具集# 连通性测试 ping -c 4 example.com mtr --report example.com # 端口检查 telnet example.com 80 nc -zv example.com 80-90 # 连接状态统计 ss -s netstat -antp3. 典型问题排查流程3.1 CPU高负载排查定位异常进程ps -eo pid,ppid,cmd,%mem,%cpu --sort-%cpu | head分析线程状态top -H -p [PID] pstree -p [PID]生成火焰图以Java为例# 采集数据 jstack [PID] thread_dump.txt perf record -F 99 -p [PID] -g -- sleep 30 # 生成图形 ./FlameGraph/stackcollapse-perf.pl out.perf out.folded ./FlameGraph/flamegraph.pl out.folded cpu.svg3.2 内存泄漏排查监控内存变化watch -n 1 free -m生成堆转储Java示例jmap -dump:formatb,fileheap.hprof [PID]分析工具推荐Eclipse MATVisualVMYourKit3.3 磁盘IO问题排查查看IO等待iostat -x 1定位高IO进程iotop -oP分析文件访问lsof D /path/to/directory4. 排查技巧与避坑指南4.1 必须记录的关键信息每次排查都应该记录问题发生时间点系统基础指标快照CPU/内存/IO/网络相关日志片段包括前后各100行当时的业务量QPS、并发数等4.2 常见误区和解决方案误区1一看到CPU高就加机器解决方案先分析是否代码问题比如死循环、算法复杂度等误区2内存用满就认为是泄漏解决方案区分缓存占用和实际使用Java的堆外内存也要检查误区3网络不通就重启服务解决方案按顺序检查物理链路→IP配置→路由→防火墙→服务监听4.3 性能优化checklist[ ] 是否有不必要的同步锁[ ] 缓存是否合理设置过期时间[ ] 日志级别是否适当避免大量DEBUG日志[ ] 线程池配置是否合理[ ] 数据库查询是否有优化空间5. 自动化监控方案5.1 基础监控配置推荐使用Prometheus Grafana组合# prometheus.yml 示例配置 scrape_configs: - job_name: node static_configs: - targets: [localhost:9100] - job_name: jvm static_configs: - targets: [localhost:1234]5.2 关键告警规则# alert.rules 示例 groups: - name: instance.rules rules: - alert: HighCPU expr: 100 - (avg by(instance)(irate(node_cpu_seconds_total{modeidle}[5m])) * 100) 80 for: 10m - alert: HighMemory expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 90 for: 5m5.3 日志收集方案ELK Stack配置要点# filebeat.yml 示例 filebeat.inputs: - type: log paths: - /var/log/*.log output.logstash: hosts: [logstash:5044]6. 排查案例实录6.1 案例一周期性CPU飙升现象每天上午10点CPU达到90%以上持续约20分钟排查过程通过sar查看历史数据确认问题时间点检查crontab发现定时任务分析任务脚本发现全表扫描SQL解决方案为查询字段添加索引调整任务执行时间为业务低峰期6.2 案例二内存缓慢增长现象服务运行3天后内存耗尽排查工具jmap -histo:live [PID] | head -20发现某个缓存类实例数异常增长修复实现缓存过期策略增加内存监控6.3 案例三网络连接失败排查路线图ping测试基础连通性telnet检查端口开放tcpdump抓包分析发现防火墙DROP规则关键命令tcpdump -i eth0 port 80 -w capture.pcap在实际运维中我养成了保存典型排查案例的习惯。每个案例都会记录完整的排查过程和最终解决方案这对团队知识积累非常有帮助。建议每个运维人员都建立自己的案例库遇到类似问题时可以快速参考。