【摘要】线上服务故障如502错误的排查效率直接影响业务恢复时间。本文总结了一套标准化的三步排查流程系统资源检查→错误日志分析→网络流量诊断并附各环节的常用Shell命令与判断标准。通过结构化排查替代盲目重启可显著缩短定位时间。关键词故障排查, 502错误, 日志分析, 服务器诊断, Nginx一、 故障排查的基本原则常见误区未保留现场证据即重启服务导致故障原因无法追溯依赖直觉盲目尝试成功率低。正确流程由底层向上逐级排查先确认基础设施状态再分析应用层日志最后检查流量与外部因素。本文以一次502故障为例拆解完整的排查路径。二、 第一步系统资源检查目标排除CPU、内存、磁盘、IO等基础设施层面的瓶颈。核心命令与判断标准检查项命令异常信号CPU/负载top -cCPU使用率持续100%负载超过核心数内存free -havailable列接近0磁盘空间df -h任一挂载点Use% ≥ 95%磁盘IOiostat -x 1%util持续接近100%处置建议CPU过载 → 排查挖矿进程、代码死循环或正常流量超出容量内存不足 → 检查内存泄漏或升级配置磁盘写满 → 清理日志、临时文件必要时扩容IO瓶颈 → 优化慢查询或升级磁盘类型本文案例中资源指标均正常排除基础设施问题。三、 第二步错误日志分析目标从日志中提取故障的直接原因。关键日志路径bash# Nginx错误日志 /var/log/nginx/error.log # Nginx访问日志 /var/log/nginx/access.log # 应用日志根据项目配置 # 如Node.js项目自建日志目录 # systemd管理服务可使用 journalctl -u service-name --since 10 minutes ago # 系统日志 /var/log/syslog查看最近日志bashtail -100 /var/log/nginx/error.log案例分析Nginx error.log显示大量connect() failed (111: Connection refused) while connecting to upstream表明Nginx无法连接后端服务。进一步查看应用日志发现Error: Redis connection timeout定位为Redis连接池耗尽。分析方法以故障发生时间为中心查看前后数秒的error级别日志。优先关注重复出现的报错信息。四、 第三步网络流量诊断目标判断是否因恶意请求或突发流量导致服务不可用。诊断命令bash# 当前TCP连接总数 netstat -an | grep ESTABLISHED | wc -l # 按IP统计连接数定位高频访问来源 netstat -an | grep :80 | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -nr | head -20 # Nginx访问日志中按IP统计请求频率 tail -1000 /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -nr | head -10处置方案单个IP请求数异常 → 在安全组中封禁该IP整体连接数远超常态 → 评估扩容或限流本案例中流量正常排除外部攻击。五、 标准化排查SOP步骤操作预期耗时1查看监控面板CPU/内存/带宽/磁盘30秒2登录服务器执行资源检查命令1分钟3查看Nginx/应用/系统错误日志2-3分钟4诊断网络连接与高频请求IP1分钟5若以上均无异常考虑重启服务保留日志—六、 经验沉淀建议每次故障处理后将以下信息记录至知识库text日期[时间] 现象[用户/系统表现] 原因[根因定位] 解决方案[具体操作] 预防措施[配置调整/监控添加]多次积累后可识别重复性问题并提前优化。如本案例中Redis maxclients参数即为事后调整。七、 总结线上故障排查的核心是结构化的逐级定位资源层→日志层→流量层。配置完善的监控与日志系统是快速排查的前提。建议在故障发生前完成日志聚合与监控告警配置避免事后被动应对。