在实际 Linux 运维工作中最考验工程师能力的往往不是日常的部署和配置而是面对突发的、原因不明的系统故障时能否快速定位并解决问题。一个没有章法的排查过程就像在黑暗中摸索不仅耗时耗力还可能因为错误的操作导致问题恶化。相反一套结构化的、通用的故障排查思路能将复杂的故障现象拆解为清晰的检查步骤极大地提升排障效率和成功率。无论你是刚入行的运维新人还是经验丰富的资深工程师掌握并内化一套“万能”的排查框架都能让你在面对任何未知故障时保持冷静从容应对。本文旨在为你构建一套从现象到根因的通用故障排查方法论。我们将从最顶层的排查原则讲起逐步深入到具体的排查路径、常用命令和实战案例。这套思路不局限于某一特定服务如 Nginx、MySQL而是适用于 Linux 系统层面绝大多数常见问题如系统负载高、服务异常、网络不通、磁盘空间不足等。通过本文你将学会如何像侦探一样系统地收集线索、分析证据、验证假设最终精准地解决生产环境中的棘手问题。1. 构建故障排查的核心原则与通用流程在动手敲任何命令之前必须先建立正确的排查心态和流程。盲目操作是排障大忌不仅可能错过关键信息甚至可能引发二次故障。1.1 排障第一原则先观察再行动先备份再修改遇到报警或用户反馈故障时第一反应不应该是立即登录服务器执行rm -rf或reboot。正确的流程是明确现象与影响范围故障是什么是服务不可用、响应慢还是功能异常影响的是单个用户、单个服务还是整个集群这一步需要与反馈人用户、监控系统清晰沟通。收集初始信息在不做任何变更的前提下通过监控系统如 Zabbix、Prometheus、日志平台如 ELK快速查看相关指标CPU、内存、磁盘、网络流量和错误日志的历史趋势。这能帮你判断故障是突然发生还是缓慢积累。制定应急预案如果故障影响重大在深入排查前应先思考并准备好回滚或临时规避方案。例如是否可以通过重启服务、切换负载均衡后端、或启用备用节点来快速恢复业务形成排查假设基于收集到的初始信息对故障根因做一个初步假设。例如“应用响应慢可能是数据库连接池耗尽”或者“磁盘空间报警可能是某个日志文件快速增长”。注意整个排查过程应遵循“最小影响原则”尽量使用只读命令如top,df,cat收集信息避免在业务高峰期进行可能引起服务中断的写操作或重启。1.2 通用排障流程从全局到局部逐层下钻一个高效的排障流程通常是分层、递进的。你可以将其想象成一个漏斗从上到下逐步缩小怀疑范围。第一层用户体验层问题通常首先表现为用户端异常。此时需要确认是全体用户都异常还是特定区域、特定操作异常这有助于区分是客户端问题、网络问题还是服务端问题。第二层应用服务层确认服务本身的状态。应用进程是否在运行端口是否在监听应用日志是否有错误这层排查需要你对服务的部署架构和日志位置有基本了解。第三层系统资源层如果应用服务层无异常问题可能出在底层资源。这是 Linux 运维排查的核心战场主要包括四大资源CPU、内存、磁盘 I/O 和网络。使用系统级命令如top,vmstat,iostat,netstat来定位瓶颈。第四层系统配置与内核层资源使用异常的背后可能是系统配置不当如文件描述符限制、内核参数或更底层的内核问题如内存泄漏、TCP 连接队列溢出。第五层硬件与基础设施层最后考虑硬件问题如磁盘坏道、内存故障、网卡异常或机房网络故障。在实际操作中我们常从第三层系统资源层开始快速检查因为它能最快地给出全局健康状态视图。2. 系统资源层排查四大核心资源的检查命令与解读系统资源瓶颈是导致服务异常的常见原因。你需要熟练使用一组核心命令来快速获取系统状态。2.1 CPU 使用率排查不只是看top的%CPU运行top命令后重点看以下几行top - 10:30:01 up 100 days, 1 user, load average: 2.01, 1.85, 1.72 Tasks: 125 total, 1 running, 124 sleeping, 0 stopped, 0 zombie %Cpu(s): 15.3 us, 8.2 sy, 0.0 ni, 76.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 stLoad Average (平均负载):1.72, 1.85, 2.01分别代表过去1、5、15分钟的系统平均负载。对于单核CPU持续高于1通常意味着CPU资源紧张。对于多核CPU需要将负载除以核心数来判断。例如4核CPU负载持续高于4才表示满负荷。%Cpu 行:us(user): 用户空间进程占用CPU百分比。过高可能意味着应用业务逻辑繁忙。sy(system): 内核空间进程占用CPU百分比。过高可能意味着系统调用频繁或存在内核态瓶颈。wa(iowait): CPU等待磁盘I/O完成的时间百分比。这是关键指标如果wa持续很高例如 20%说明磁盘I/O是瓶颈CPU在空等即使us和sy不高系统也会很慢。id(idle): CPU空闲百分比。进阶排查如果us或sy很高在top界面按Shift P按CPU使用率排序找到占用最高的进程。记下其PID然后可以使用pidstat或perf进行更细粒度的分析。# 查看特定进程的详细CPU使用情况每秒采样一次共5次 pidstat -p PID 1 5 # 或者使用更直观的htop如果已安装 htop2.2 内存使用排查理解free与available运行free -h命令total used free shared buff/cache available Mem: 7.6G 3.2G 1.1G 123M 3.3G 3.9G Swap: 2.0G 0B 2.0G关键看available列而不是free列Linux 会利用空闲内存做磁盘缓存buff/cache以提高性能。因此free内存少是正常现象。available列表示系统估算的、可供新应用程序使用的内存量这个值如果很小比如小于总内存的10%则说明内存可能不足。Swap 使用情况如果Swap的used持续增长说明物理内存不足系统开始使用硬盘作为虚拟内存这会导致性能严重下降。排查内存泄漏如果available持续下降且buff/cache没有显著变化可能是应用内存泄漏。使用top命令按Shift M按内存使用排序找到占用最高的进程。对于 Java 应用可以结合jstat或jmap分析堆内存。2.3 磁盘 I/O 与空间排查iostat与df/du组合I/O 性能排查使用iostat查看磁盘活动。# 每2秒刷新一次显示所有磁盘的扩展统计信息 iostat -dx 2关键列%util设备利用率。接近100%表示设备I/O饱和。await平均每次I/O请求的等待时间毫秒。值越大说明I/O越慢。r/s,w/s每秒读写请求数。rkB/s,wkB/s每秒读写数据量KB。如果%util和await都很高说明磁盘是系统瓶颈。磁盘空间排查这是最常见的故障之一。# 查看文件系统磁盘空间使用情况 df -h # 如果发现某个分区使用率过高如/根分区需要定位大文件或目录 # 查看当前目录下各子目录的大小 du -sh ./* | sort -rh | head -10 # 查找系统中大于100M的文件从根目录开始可能需要sudo find / -type f -size 100M 2/dev/null | xargs ls -lh | head -202.4 网络连接排查netstat与ss网络问题通常表现为连接超时、拒绝服务或端口不通。查看连接状态与监听端口# 传统命令显示所有TCP连接和监听端口 netstat -tlnp # 更现代、更快的命令推荐使用 ss -tlnp-tTCP协议。-l仅显示监听状态的套接字。-n以数字形式显示地址和端口。-p显示进程信息。排查连接数问题如果遇到“Cannot assign requested address”或连接数满的错误需要检查。# 统计各种TCP状态的数量 ss -ant | awk NR1 {S[$1]} END {for(a in S) print a, S[a]} # 查看某个服务如Nginx建立了多少连接 ss -ant sport :80 | wc -l网络连通性测试从问题服务器出发逐段测试。# 测试到目标IP的连通性和路由 ping -c 4 目标IP traceroute 目标IP # 测试到目标IP特定端口的连通性最常用 telnet 目标IP 端口号 # 或者使用nc nc -zv 目标IP 端口号3. 应用服务层与日志排查锁定问题进程当系统资源层面没有明显瓶颈时问题很可能出在具体的应用程序上。3.1 检查进程状态与服务状态# 1. 查看进程是否存在 ps aux | grep 进程名或关键字 # 2. 查看系统服务状态Systemd系统 systemctl status 服务名.service # 3. 查看服务日志的最后20行 journalctl -u 服务名.service -n 20 --no-pager # 或直接查看服务的日志文件 tail -f /var/log/服务名/error.log3.2 日志分析的通用技巧日志是定位应用问题最直接的证据。分析日志时确定时间范围根据故障发生时间查看对应时间段的日志。grep结合时间戳非常有效。grep “2024-05-27 10:30” /var/log/nginx/access.log关注错误级别优先查看ERROR、FATAL、Exception、Failed等关键词。grep -E “ERROR|FATAL|Exception” /var/log/myapp/app.log上下文关联不要只看错误行要查看错误前后的若干行日志以了解触发错误的操作和上下文。grep -A 5 -B 5 “NullPointerException” /var/log/myapp/app.log使用日志聚合工具对于分布式系统必须使用像 ELKElasticsearch, Logstash, Kibana或 LokiGrafana 这样的工具来集中查看和搜索日志。3.3 一个经典案例磁盘空间被日志文件占满这是运维日常中最高频的故障之一。现象是df -h显示/或/var分区使用率 100%应用无法写入日志或文件。排查步骤df -h确认哪个分区满。du -sh /var/* | sort -rh | head -10定位/var下哪个目录最大。假设是/var/log继续du -sh /var/log/* | sort -rh。发现是某个应用日志文件如app.log巨大。不要直接rm app.log因为文件可能被进程持有直接删除不会释放磁盘空间空间会在进程关闭文件后释放。正确做法# 方法一清空文件内容保留文件句柄 cat /dev/null /var/log/app.log # 或 : /var/log/app.log # 方法二使用日志轮转工具如logrotate管理日志这是治本之策。4. 网络问题深度排查从本机到远端网络问题排查需要遵循从近到远、从底层到上层的原则。4.1 本地检查清单检查项命令正常现象/说明网卡状态ip addr show或ifconfig网卡UP有正确的IP地址。路由表ip route show或route -n有通往目标网络的默认路由或特定路由。本地端口监听ss -tlnp | grep :端口目标端口处于LISTEN状态且有对应进程。本地防火墙iptables -L -n或firewall-cmd --list-all规则未阻止目标端口的入站/出站流量。DNS解析nslookup 域名或dig 域名能正确解析出IP地址。4.2 外部连通性检查如果本地配置无误开始向外排查网关可达性ping 网关IP。目标IP可达性ping 目标IP。如果不通可能是中间网络设备交换机、路由器、安全组阻断了ICMP或所有流量。目标端口可达性telnet 目标IP 端口或nc -zv 目标IP 端口。这是最关键的一步它能确认TCP/UDP层面的连通性。路由追踪traceroute 目标IP或mtr 目标IP。可以查看数据包在哪个网络节点丢失或延迟激增。4.3 连接数相关故障排查高并发场景下常遇到连接数耗尽的问题。客户端错误Cannot assign requested address。这通常是因为客户端短时间内创建了大量连接端口被耗尽。需要检查# 查看本地端口范围 sysctl net.ipv4.ip_local_port_range # 增加可用端口范围临时 sysctl -w net.ipv4.ip_local_port_range1024 65000服务端错误Address already in use或连接被拒绝。需要检查服务是否在监听ss -tlnp \| grep :端口。连接数是否超过服务限制如MySQL的max_connectionsNginx的worker_connections。服务端文件描述符限制ulimit -n。系统全局连接跟踪表是否满针对有状态防火墙如iptablescat /proc/sys/net/netfilter/nf_conntrack_max。5. 性能问题综合排查实战系统响应缓慢假设收到报警某台服务器上的Web应用响应缓慢。第一步快速全局检查1分钟内top查看load average,%Cpu特别是%wa, 以及占用资源最高的进程。free -h查看available内存和Swap使用。df -h查看磁盘空间。ss -ant \| awk ...快速查看TCP连接状态分布。第二步根据第一步结果下钻如果%wa高使用iostat -dx 2确认磁盘I/O瓶颈再用iotop找到哪个进程在大量读写磁盘。如果load average高但%CPU不高可能是等待I/O的进程太多同样排查磁盘I/O。如果某个进程%CPU异常高使用pidstat -p PID 1或perf top -p PID分析该进程的CPU热点。如果available内存极低Swap使用高系统在频繁换页内存是瓶颈。找到内存消耗最大的进程。如果TIME_WAIT连接数异常多可能是应用没有正确关闭连接需要检查代码或调整TCP参数如net.ipv4.tcp_tw_reuse。第三步检查应用本身查看应用日志tail -f /var/log/nginx/error.log或应用日志。检查应用依赖的中间件数据库连接池是否正常Redis是否响应慢可以使用对应客户端的监控命令。模拟请求使用curl带上时间参数分析耗时在哪一阶段curl -o /dev/null -s -w “time_total: %{time_total}\ntime_connect: %{time_connect}\n” http://localhost/api6. 运维工具箱必备脚本与长期可观测性建设6.1 编写实用的排查小脚本将常用排查命令封装成脚本可以一键输出系统健康状态。#!/bin/bash # 文件名system_health_check.sh echo “ System Health Check ” echo “检查时间$(date)” echo “” echo “1. 系统负载与运行时间” uptime echo “” echo “2. 内存使用情况” free -h echo “” echo “3. 磁盘空间使用情况” df -h echo “” echo “4. CPU使用率最高的10个进程” ps aux --sort-%cpu | head -11 echo “” echo “5. 内存使用率最高的10个进程” ps aux --sort-%mem | head -11 echo “” echo “6. 网络连接统计TCP” ss -ant | awk ‘NR1 {S[$1]} END {for(a in S) print a, S[a]}’ echo “” echo “7. 检查关键服务状态” for service in nginx mysql redis; do if systemctl is-active --quiet $service; then echo “$service: Running” else echo “$service: NOT Running” fi done6.2 构建可观测性体系从被动救火到主动预防真正的“万能”排查思路离不开完善的监控和日志系统。这能让你在用户投诉之前就发现问题。基础监控使用 Zabbix、Prometheus Node Exporter 监控所有服务器的 CPU、内存、磁盘、网络、关键进程。日志中心使用 ELK Stack 或 Loki 集中收集所有应用和系统日志便于关联查询。应用性能监控使用 SkyWalking、Pinpoint 或商业 APM 工具追踪分布式调用链定位慢请求根因。设置智能告警基于监控指标设置合理的阈值告警如 CPU 持续5分钟90%并区分警告P4/P3和严重P2/P1级别避免告警疲劳。故障排查能力的提升是一个将通用思路与具体领域知识如数据库、网络、特定中间件相结合的过程。掌握本文所述的从原则到流程从资源层到应用层的排查路径能为你解决大部分常见的、突发的线上问题提供清晰的行动指南。更重要的是要将“先观察后行动”、“逐层下钻”的思维模式变成肌肉记忆。同时不断积累在特定技术栈如 JVM、MySQL、K8s下的深度排查经验并最终通过建设强大的可观测性体系将被动排障转变为主动运维这才是运维工程师从“救火队员”成长为“系统架构守护者”的关键路径。
Linux系统故障排查：从核心原则到实战命令的通用方法论
在实际 Linux 运维工作中最考验工程师能力的往往不是日常的部署和配置而是面对突发的、原因不明的系统故障时能否快速定位并解决问题。一个没有章法的排查过程就像在黑暗中摸索不仅耗时耗力还可能因为错误的操作导致问题恶化。相反一套结构化的、通用的故障排查思路能将复杂的故障现象拆解为清晰的检查步骤极大地提升排障效率和成功率。无论你是刚入行的运维新人还是经验丰富的资深工程师掌握并内化一套“万能”的排查框架都能让你在面对任何未知故障时保持冷静从容应对。本文旨在为你构建一套从现象到根因的通用故障排查方法论。我们将从最顶层的排查原则讲起逐步深入到具体的排查路径、常用命令和实战案例。这套思路不局限于某一特定服务如 Nginx、MySQL而是适用于 Linux 系统层面绝大多数常见问题如系统负载高、服务异常、网络不通、磁盘空间不足等。通过本文你将学会如何像侦探一样系统地收集线索、分析证据、验证假设最终精准地解决生产环境中的棘手问题。1. 构建故障排查的核心原则与通用流程在动手敲任何命令之前必须先建立正确的排查心态和流程。盲目操作是排障大忌不仅可能错过关键信息甚至可能引发二次故障。1.1 排障第一原则先观察再行动先备份再修改遇到报警或用户反馈故障时第一反应不应该是立即登录服务器执行rm -rf或reboot。正确的流程是明确现象与影响范围故障是什么是服务不可用、响应慢还是功能异常影响的是单个用户、单个服务还是整个集群这一步需要与反馈人用户、监控系统清晰沟通。收集初始信息在不做任何变更的前提下通过监控系统如 Zabbix、Prometheus、日志平台如 ELK快速查看相关指标CPU、内存、磁盘、网络流量和错误日志的历史趋势。这能帮你判断故障是突然发生还是缓慢积累。制定应急预案如果故障影响重大在深入排查前应先思考并准备好回滚或临时规避方案。例如是否可以通过重启服务、切换负载均衡后端、或启用备用节点来快速恢复业务形成排查假设基于收集到的初始信息对故障根因做一个初步假设。例如“应用响应慢可能是数据库连接池耗尽”或者“磁盘空间报警可能是某个日志文件快速增长”。注意整个排查过程应遵循“最小影响原则”尽量使用只读命令如top,df,cat收集信息避免在业务高峰期进行可能引起服务中断的写操作或重启。1.2 通用排障流程从全局到局部逐层下钻一个高效的排障流程通常是分层、递进的。你可以将其想象成一个漏斗从上到下逐步缩小怀疑范围。第一层用户体验层问题通常首先表现为用户端异常。此时需要确认是全体用户都异常还是特定区域、特定操作异常这有助于区分是客户端问题、网络问题还是服务端问题。第二层应用服务层确认服务本身的状态。应用进程是否在运行端口是否在监听应用日志是否有错误这层排查需要你对服务的部署架构和日志位置有基本了解。第三层系统资源层如果应用服务层无异常问题可能出在底层资源。这是 Linux 运维排查的核心战场主要包括四大资源CPU、内存、磁盘 I/O 和网络。使用系统级命令如top,vmstat,iostat,netstat来定位瓶颈。第四层系统配置与内核层资源使用异常的背后可能是系统配置不当如文件描述符限制、内核参数或更底层的内核问题如内存泄漏、TCP 连接队列溢出。第五层硬件与基础设施层最后考虑硬件问题如磁盘坏道、内存故障、网卡异常或机房网络故障。在实际操作中我们常从第三层系统资源层开始快速检查因为它能最快地给出全局健康状态视图。2. 系统资源层排查四大核心资源的检查命令与解读系统资源瓶颈是导致服务异常的常见原因。你需要熟练使用一组核心命令来快速获取系统状态。2.1 CPU 使用率排查不只是看top的%CPU运行top命令后重点看以下几行top - 10:30:01 up 100 days, 1 user, load average: 2.01, 1.85, 1.72 Tasks: 125 total, 1 running, 124 sleeping, 0 stopped, 0 zombie %Cpu(s): 15.3 us, 8.2 sy, 0.0 ni, 76.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 stLoad Average (平均负载):1.72, 1.85, 2.01分别代表过去1、5、15分钟的系统平均负载。对于单核CPU持续高于1通常意味着CPU资源紧张。对于多核CPU需要将负载除以核心数来判断。例如4核CPU负载持续高于4才表示满负荷。%Cpu 行:us(user): 用户空间进程占用CPU百分比。过高可能意味着应用业务逻辑繁忙。sy(system): 内核空间进程占用CPU百分比。过高可能意味着系统调用频繁或存在内核态瓶颈。wa(iowait): CPU等待磁盘I/O完成的时间百分比。这是关键指标如果wa持续很高例如 20%说明磁盘I/O是瓶颈CPU在空等即使us和sy不高系统也会很慢。id(idle): CPU空闲百分比。进阶排查如果us或sy很高在top界面按Shift P按CPU使用率排序找到占用最高的进程。记下其PID然后可以使用pidstat或perf进行更细粒度的分析。# 查看特定进程的详细CPU使用情况每秒采样一次共5次 pidstat -p PID 1 5 # 或者使用更直观的htop如果已安装 htop2.2 内存使用排查理解free与available运行free -h命令total used free shared buff/cache available Mem: 7.6G 3.2G 1.1G 123M 3.3G 3.9G Swap: 2.0G 0B 2.0G关键看available列而不是free列Linux 会利用空闲内存做磁盘缓存buff/cache以提高性能。因此free内存少是正常现象。available列表示系统估算的、可供新应用程序使用的内存量这个值如果很小比如小于总内存的10%则说明内存可能不足。Swap 使用情况如果Swap的used持续增长说明物理内存不足系统开始使用硬盘作为虚拟内存这会导致性能严重下降。排查内存泄漏如果available持续下降且buff/cache没有显著变化可能是应用内存泄漏。使用top命令按Shift M按内存使用排序找到占用最高的进程。对于 Java 应用可以结合jstat或jmap分析堆内存。2.3 磁盘 I/O 与空间排查iostat与df/du组合I/O 性能排查使用iostat查看磁盘活动。# 每2秒刷新一次显示所有磁盘的扩展统计信息 iostat -dx 2关键列%util设备利用率。接近100%表示设备I/O饱和。await平均每次I/O请求的等待时间毫秒。值越大说明I/O越慢。r/s,w/s每秒读写请求数。rkB/s,wkB/s每秒读写数据量KB。如果%util和await都很高说明磁盘是系统瓶颈。磁盘空间排查这是最常见的故障之一。# 查看文件系统磁盘空间使用情况 df -h # 如果发现某个分区使用率过高如/根分区需要定位大文件或目录 # 查看当前目录下各子目录的大小 du -sh ./* | sort -rh | head -10 # 查找系统中大于100M的文件从根目录开始可能需要sudo find / -type f -size 100M 2/dev/null | xargs ls -lh | head -202.4 网络连接排查netstat与ss网络问题通常表现为连接超时、拒绝服务或端口不通。查看连接状态与监听端口# 传统命令显示所有TCP连接和监听端口 netstat -tlnp # 更现代、更快的命令推荐使用 ss -tlnp-tTCP协议。-l仅显示监听状态的套接字。-n以数字形式显示地址和端口。-p显示进程信息。排查连接数问题如果遇到“Cannot assign requested address”或连接数满的错误需要检查。# 统计各种TCP状态的数量 ss -ant | awk NR1 {S[$1]} END {for(a in S) print a, S[a]} # 查看某个服务如Nginx建立了多少连接 ss -ant sport :80 | wc -l网络连通性测试从问题服务器出发逐段测试。# 测试到目标IP的连通性和路由 ping -c 4 目标IP traceroute 目标IP # 测试到目标IP特定端口的连通性最常用 telnet 目标IP 端口号 # 或者使用nc nc -zv 目标IP 端口号3. 应用服务层与日志排查锁定问题进程当系统资源层面没有明显瓶颈时问题很可能出在具体的应用程序上。3.1 检查进程状态与服务状态# 1. 查看进程是否存在 ps aux | grep 进程名或关键字 # 2. 查看系统服务状态Systemd系统 systemctl status 服务名.service # 3. 查看服务日志的最后20行 journalctl -u 服务名.service -n 20 --no-pager # 或直接查看服务的日志文件 tail -f /var/log/服务名/error.log3.2 日志分析的通用技巧日志是定位应用问题最直接的证据。分析日志时确定时间范围根据故障发生时间查看对应时间段的日志。grep结合时间戳非常有效。grep “2024-05-27 10:30” /var/log/nginx/access.log关注错误级别优先查看ERROR、FATAL、Exception、Failed等关键词。grep -E “ERROR|FATAL|Exception” /var/log/myapp/app.log上下文关联不要只看错误行要查看错误前后的若干行日志以了解触发错误的操作和上下文。grep -A 5 -B 5 “NullPointerException” /var/log/myapp/app.log使用日志聚合工具对于分布式系统必须使用像 ELKElasticsearch, Logstash, Kibana或 LokiGrafana 这样的工具来集中查看和搜索日志。3.3 一个经典案例磁盘空间被日志文件占满这是运维日常中最高频的故障之一。现象是df -h显示/或/var分区使用率 100%应用无法写入日志或文件。排查步骤df -h确认哪个分区满。du -sh /var/* | sort -rh | head -10定位/var下哪个目录最大。假设是/var/log继续du -sh /var/log/* | sort -rh。发现是某个应用日志文件如app.log巨大。不要直接rm app.log因为文件可能被进程持有直接删除不会释放磁盘空间空间会在进程关闭文件后释放。正确做法# 方法一清空文件内容保留文件句柄 cat /dev/null /var/log/app.log # 或 : /var/log/app.log # 方法二使用日志轮转工具如logrotate管理日志这是治本之策。4. 网络问题深度排查从本机到远端网络问题排查需要遵循从近到远、从底层到上层的原则。4.1 本地检查清单检查项命令正常现象/说明网卡状态ip addr show或ifconfig网卡UP有正确的IP地址。路由表ip route show或route -n有通往目标网络的默认路由或特定路由。本地端口监听ss -tlnp | grep :端口目标端口处于LISTEN状态且有对应进程。本地防火墙iptables -L -n或firewall-cmd --list-all规则未阻止目标端口的入站/出站流量。DNS解析nslookup 域名或dig 域名能正确解析出IP地址。4.2 外部连通性检查如果本地配置无误开始向外排查网关可达性ping 网关IP。目标IP可达性ping 目标IP。如果不通可能是中间网络设备交换机、路由器、安全组阻断了ICMP或所有流量。目标端口可达性telnet 目标IP 端口或nc -zv 目标IP 端口。这是最关键的一步它能确认TCP/UDP层面的连通性。路由追踪traceroute 目标IP或mtr 目标IP。可以查看数据包在哪个网络节点丢失或延迟激增。4.3 连接数相关故障排查高并发场景下常遇到连接数耗尽的问题。客户端错误Cannot assign requested address。这通常是因为客户端短时间内创建了大量连接端口被耗尽。需要检查# 查看本地端口范围 sysctl net.ipv4.ip_local_port_range # 增加可用端口范围临时 sysctl -w net.ipv4.ip_local_port_range1024 65000服务端错误Address already in use或连接被拒绝。需要检查服务是否在监听ss -tlnp \| grep :端口。连接数是否超过服务限制如MySQL的max_connectionsNginx的worker_connections。服务端文件描述符限制ulimit -n。系统全局连接跟踪表是否满针对有状态防火墙如iptablescat /proc/sys/net/netfilter/nf_conntrack_max。5. 性能问题综合排查实战系统响应缓慢假设收到报警某台服务器上的Web应用响应缓慢。第一步快速全局检查1分钟内top查看load average,%Cpu特别是%wa, 以及占用资源最高的进程。free -h查看available内存和Swap使用。df -h查看磁盘空间。ss -ant \| awk ...快速查看TCP连接状态分布。第二步根据第一步结果下钻如果%wa高使用iostat -dx 2确认磁盘I/O瓶颈再用iotop找到哪个进程在大量读写磁盘。如果load average高但%CPU不高可能是等待I/O的进程太多同样排查磁盘I/O。如果某个进程%CPU异常高使用pidstat -p PID 1或perf top -p PID分析该进程的CPU热点。如果available内存极低Swap使用高系统在频繁换页内存是瓶颈。找到内存消耗最大的进程。如果TIME_WAIT连接数异常多可能是应用没有正确关闭连接需要检查代码或调整TCP参数如net.ipv4.tcp_tw_reuse。第三步检查应用本身查看应用日志tail -f /var/log/nginx/error.log或应用日志。检查应用依赖的中间件数据库连接池是否正常Redis是否响应慢可以使用对应客户端的监控命令。模拟请求使用curl带上时间参数分析耗时在哪一阶段curl -o /dev/null -s -w “time_total: %{time_total}\ntime_connect: %{time_connect}\n” http://localhost/api6. 运维工具箱必备脚本与长期可观测性建设6.1 编写实用的排查小脚本将常用排查命令封装成脚本可以一键输出系统健康状态。#!/bin/bash # 文件名system_health_check.sh echo “ System Health Check ” echo “检查时间$(date)” echo “” echo “1. 系统负载与运行时间” uptime echo “” echo “2. 内存使用情况” free -h echo “” echo “3. 磁盘空间使用情况” df -h echo “” echo “4. CPU使用率最高的10个进程” ps aux --sort-%cpu | head -11 echo “” echo “5. 内存使用率最高的10个进程” ps aux --sort-%mem | head -11 echo “” echo “6. 网络连接统计TCP” ss -ant | awk ‘NR1 {S[$1]} END {for(a in S) print a, S[a]}’ echo “” echo “7. 检查关键服务状态” for service in nginx mysql redis; do if systemctl is-active --quiet $service; then echo “$service: Running” else echo “$service: NOT Running” fi done6.2 构建可观测性体系从被动救火到主动预防真正的“万能”排查思路离不开完善的监控和日志系统。这能让你在用户投诉之前就发现问题。基础监控使用 Zabbix、Prometheus Node Exporter 监控所有服务器的 CPU、内存、磁盘、网络、关键进程。日志中心使用 ELK Stack 或 Loki 集中收集所有应用和系统日志便于关联查询。应用性能监控使用 SkyWalking、Pinpoint 或商业 APM 工具追踪分布式调用链定位慢请求根因。设置智能告警基于监控指标设置合理的阈值告警如 CPU 持续5分钟90%并区分警告P4/P3和严重P2/P1级别避免告警疲劳。故障排查能力的提升是一个将通用思路与具体领域知识如数据库、网络、特定中间件相结合的过程。掌握本文所述的从原则到流程从资源层到应用层的排查路径能为你解决大部分常见的、突发的线上问题提供清晰的行动指南。更重要的是要将“先观察后行动”、“逐层下钻”的思维模式变成肌肉记忆。同时不断积累在特定技术栈如 JVM、MySQL、K8s下的深度排查经验并最终通过建设强大的可观测性体系将被动排障转变为主动运维这才是运维工程师从“救火队员”成长为“系统架构守护者”的关键路径。