当服务器出现异常时，系统性地测试和排查是快速定位问题的关键，你需要像一个侦探一样，从外到内、从现象到根源，层层递进地检查。
以下是一个结构化的排查思路和清单，你可以根据实际情况按顺序或重点进行检查：
第一阶段：现象确认与基础连通性（从外向内）
这是判断问题范围的第一步。
1、网络连通性：
ping测试服务器IP地址是否能通，不通则可能是网络中断、防火墙丢弃ICMP包、或服务器关机。
端口连通性使用telnet 或nc 命令测试具体业务端口（如80, 443, 22, 3306）是否开放。ping通但端口不通，通常是服务未启动或防火墙阻止。
DNS解析如果是域名访问，检查域名是否能正确解析到服务器IP（nslookup 或dig）。
2、服务可访问性：
* 通过浏览器、客户端工具等，模拟真实用户访问，确认错误现象（如502 Bad Gateway, 504 Timeout, 连接被拒绝等）。
第二阶段：服务器自身状态检查（登录服务器后）
一旦能连接到服务器（如通过SSH），开始内部检查。
使用top、htop、vmstat、iostat、df 等命令。
1、CPU：
top 查看%CPU、%wa（等待I/O的CPU时间）。
* 使用率是否长期高于80%？哪个进程占用高？
2、内存：
free -h 查看总内存、已用、缓存/缓冲区、可用内存。
* 是否用尽？是否有大量Swap被使用？内存耗尽会触发OOM Killer，杀死关键进程。
3、磁盘I/O：
iostat -x 1 查看%util（设备利用率）、await（I/O等待时间）。
* 磁盘是否满？df -h 检查关键分区（如/,/var,/home）。
* 磁盘是否读写缓慢？I/O等待高会拖慢整个系统。
4、磁盘空间：
df -h 是基础，也要检查inode 是否用尽df -i。
* 日志文件（如/var/log）、临时文件可能快速占满空间。
1、关键进程状态：
* 你的应用程序进程（如Java, Nginx, MySQL, Docker容器）是否在运行？ps aux | grep [进程名] 或systemctl status [服务名]。
* 进程是挂了，还是在崩溃重启的循环中？
2、服务日志：
这是最重要的线索来源！ 立即查看相关日志。
journalctl -u [服务名] --since "10 minutes ago" （Systemd系统）。
* 直接查看应用日志文件，通常在/var/log/ 下，如nginx/error.log，mysql/error.log，或应用自定义的日志路径。
* 查找ERROR、FATAL、Exception、timeout、OOM 等关键词。
3、系统日志：
/var/log/messages、/var/log/syslog（Linux通用）。
dmesg | tail 查看内核环形缓冲区信息，可能包含硬件错误、驱动问题或OOM信息。
如果资源正常，进程也在，但服务异常。
1、应用配置：
* 最近是否更改过配置文件？检查Nginx/Apache配置、数据库参数、应用配置文件。
* 配置文件语法是否正确？nginx -t 可以测试Nginx配置。
2、依赖服务：
* 你的应用是否依赖其他服务？如数据库、缓存（Redis）、消息队列（Kafka/RabbitMQ）、其他API接口。
* 测试这些依赖服务的连通性和状态，从应用服务器telnet 数据库的3306端口，或用客户端连接测试。
3、安全限制：
防火墙检查服务器本地防火墙（iptables、firewalld、ufw）规则是否阻止了必要端口。
SELinux/AppArmor安全模块是否阻止了应用的关键操作？可尝试临时设置为宽松模式测试。
文件权限应用进程用户是否有权限读写所需的目录和文件？
4、外部攻击或异常流量：
* 检查是否有异常的访问模式，使用netstat 查看大量连接是否来自少数IP（可能遭遇DDoS或爬虫）。
* 查看Web服务器访问日志，分析请求量、URI、用户代理。
1、时间同步：
* 服务器时间是否准确？date 命令查看，时间不同步会导致证书验证失败、日志混乱等问题，检查ntp 或chronyd 服务。
2、内核参数限制：
检查打开文件数限制ulimit -n，高并发应用可能需要调整fs.file-max 和进程限制。
3、硬件问题：
物理服务器需注意RAID卡电池、硬盘SMART错误、内存故障（ECC错误）、网卡故障等，查看dmesg 和硬件管理工具。
4、虚拟化/云平台层面：
在云服务器上，检查云控制台实例是否运行在 degraded 的主机上？是否有底层维护事件？云硬盘性能是否达到上限？安全组规则是否正确？
5、版本与依赖冲突：
* 最近是否进行了系统或软件更新？可能存在新版本不兼容、库文件冲突等问题。
监控与告警建立完善的监控系统（如 Prometheus + Grafana + Alertmanager），持续监控上述所有指标（CPU、内存、磁盘、服务状态、业务指标），在问题发生前或发生时立即收到告警。
变更管理任何对生产环境的变更（代码发布、配置修改、系统更新）都应有记录和回滚方案，很多问题源于变更。
遵循排查路径从用户端 -> 网络 -> 系统资源 -> 服务状态 -> 应用日志，这个顺序可以高效地缩小问题范围。
记录与复盘问题解决后，记录根本原因和解决步骤，形成知识库，便于后续参考和进行架构优化。
你可以根据服务器的具体症状（如“网站打开慢”、“完全无法连接”、“数据库报错”），结合上面的清单，选择最可能的方向开始排查，日志通常是揭开谜底的最后一把钥匙。
文章摘自：https://idc.huochengrm.cn/js/24935.html
评论