在实际服务器运维工作中日常巡检是保障系统稳定、预防故障、优化性能的基础性工作。很多新手运维工程师面对一台或多台服务器时常常感到无从下手不知道应该检查什么、按什么顺序检查、以及检查结果如何解读。而经验丰富的老师傅则有一套固定的检查清单和优先级能够快速定位潜在风险。本文将围绕服务器日常巡检的核心五项详细拆解每一项的检查目标、具体操作命令、结果分析方法以及常见问题的排查路径旨在为运维人员提供一套可落地、可复现的巡检实战指南。这套方法适用于运行 CentOS、RHEL、Ubuntu 等主流发行版的 Linux 服务器无论是物理机、虚拟机还是云主机。学习本文后你将能够建立自己的服务器健康检查体系从被动的故障响应转向主动的系统维护。1. 第一项系统负载与 CPU 使用率检查系统负载是反映服务器繁忙程度的综合指标而 CPU 使用率则更具体地展示了处理器的计算资源消耗情况。两者结合可以判断服务器是否过载、是否存在异常进程或是否需要扩容。1.1 理解负载平均值Load Average负载平均值通常通过uptime或top命令查看显示为三个数字例如0.05, 0.10, 0.15分别代表过去 1 分钟、5 分钟和 15 分钟的系统平均负载。关键概念在于对于单核 CPU 系统负载 1.0 表示 CPU 被完全利用。对于多核系统需要将负载值与 CPU 核心数进行比较。例如一台 4 核 CPU 的服务器如果 15 分钟负载持续在 4.0 以上说明系统可能长期处于满负荷状态。检查命令与解读# 查看系统运行时间、用户数和负载 uptime # 输出示例 10:30:00 up 30 days, 2:15, 1 user, load average: 1.25, 0.98, 0.75 # 查看CPU核心数 grep model name /proc/cpuinfo | wc -l # 或 nproc解读步骤运行uptime获取负载值。运行nproc获取 CPU 逻辑核心数。判断如果 15 分钟负载持续高于CPU核心数 * 0.7则需要警惕如果持续高于 CPU 核心数则系统已过载需要立即分析。1.2 深入分析 CPU 使用率负载高不一定代表 CPU 使用率高可能是 I/O 等待因此需要结合top或vmstat命令进行细化分析。# 使用 top 命令动态查看按1可以显示所有CPU核心的详情 top # 使用 mpstat 查看每个CPU核心的详细统计需安装 sysstat 包 mpstat -P ALL 1 5在top命令的输出中重点关注以下几行%Cpu(s):行us用户空间、sy内核空间、id空闲、waI/O 等待。如果wa值长期过高如 20%说明磁盘 I/O 可能是瓶颈。PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND进程列表按%CPU排序在top界面按ShiftP可以快速找出消耗 CPU 最多的进程。1.3 常见问题与排查路径现象可能原因检查命令/位置处理建议负载很高但 CPUid空闲很高waI/O等待很高磁盘 I/O 瓶颈。进程因等待磁盘读写而阻塞。iostat -x 1 5查看%util和awaitiotop查看具体进程 I/O。优化慢查询、检查日志写入、考虑使用 SSD、分散 I/O 压力。us用户态CPU 异常高应用程序自身计算密集或存在低效代码、死循环。top -c查看具体进程命令perf top或strace -p PID进行深入分析。分析应用代码、优化算法、考虑水平扩展或升级 CPU。sy内核态CPU 异常高系统调用频繁可能由于上下文切换过多、系统资源竞争或驱动问题。vmstat 1 5查看cs上下文切换次数pidstat -w 1查看进程切换情况。减少不必要的进程数、检查内核参数如net.ipv4.tcp_tw_recycle已废弃、更新驱动或内核。CPU 使用率间歇性飙高定时任务、外部请求突增或内存不足触发频繁 GC。检查crontab -l查看应用日志和监控图表dmesg看是否有 OOM 日志。调整定时任务执行时间、为应用设置限流、增加内存或优化应用内存使用。注意单次top查看的是瞬时状态对于间歇性问题建议使用sarsysstat 工具包收集历史数据进行分析sar -u 1 10。2. 第二项内存与交换空间使用情况检查内存不足会直接导致应用运行缓慢、服务崩溃甚至触发 OOM Killer 杀死关键进程。检查内存不仅要看使用量还要看缓存、缓冲和交换空间的使用趋势。2.1 理解内存统计指标使用free -h命令查看内存输出包含以下关键列total: 总物理内存。used: 已使用的内存包含 buffers/cache。free: 完全空闲的内存。shared/buff/cache: 被内核缓冲区buffer和页面缓存cache占用的内存。这部分内存在应用需要时可以被快速回收因此不属于“已消耗”。available:最重要指标。估算可用于启动新应用程序的内存量无需交换。free -h输出示例total used free shared buff/cache available Mem: 7.6G 2.1G 1.2G 123M 4.3G 5.0G Swap: 2.0G 0B 2.0G正确解读不要只看free值小就紧张。上例中available还有 5.0G说明内存非常充足。buff/cache占用了 4.3G这是为了提高磁盘 I/O 性能是好事。2.2 检查交换空间Swap使用交换空间是当物理内存不足时将不活跃的内存页写入磁盘的区域。频繁的 Swap 交换Swapping会带来严重的性能下降。# 查看交换空间使用情况 swapon -s # 或 cat /proc/swaps # 使用 vmstat 查看 siswap in和 soswap out频率 vmstat 1 5如果si每秒从磁盘换入的内存量和so每秒换出到磁盘的内存量长期大于 0说明内存严重不足系统在频繁使用 Swap。即使 Swap 使用量不为 0但只要si/so为 0说明只是有些历史页面被换出了当前没有活跃交换问题不大。2.3 定位内存消耗进程与排查内存泄漏使用top或ps命令定位内存消耗大的进程。# 在 top 界面按 ShiftM 按内存使用率排序 top # 使用 ps 命令按 RSS 排序查看前10个进程 ps aux --sort-rss | head -10对于疑似内存泄漏的 Java 应用可以结合jstat查看 GC 情况# 查看 Java 进程的 GC 统计pid 为 Java 进程ID 1000 表示每1秒输出一次 jstat -gcutil pid 1000关注FGCFull GC 次数是否频繁OU老年代使用率是否持续增长不下降。2.4 常见问题与排查路径现象可能原因检查命令/位置处理建议available内存持续减少接近为 0应用存在内存泄漏或系统承载压力超过设计容量。vmstat 1看free和swap趋势ps aux --sort-rss应用自身监控。重启问题应用临时恢复使用valgrind、jmap等工具分析内存泄漏点扩容内存。si/so持续很高物理内存严重不足系统在频繁交换。vmstat 1sar -B 1dmesggrep -i kill 查看 OOM Killer 日志。buff/cache异常高且available很低可能是文件系统缓存占用了大量内存且应用正在申请内存。slabtop查看内核 slab 使用echo 3 /proc/sys/vm/drop_caches生产环境慎用可手动释放缓存观察。这是 Linux 内存管理机制通常无需干预。除非在应用启动前需要最大空闲内存可临时清缓存。应用进程被意外杀死触发了 OOM Killer。dmesgtail -50或grep -i killed process /var/log/messages。3. 第三项磁盘空间与 I/O 性能检查磁盘空间耗尽会导致服务不可写、日志无法记录、系统异常。磁盘 I/O 性能则是数据库、文件服务等应用的命脉。3.1 检查磁盘空间使用率使用df命令查看文件系统级别的磁盘使用情况。# 以人类可读格式显示所有文件系统 df -h # 重点关注特定挂载点如根目录和关键数据目录 df -h / /home /data巡检要点重点关注使用率超过 80% 的分区需要制定清理或扩容计划。对于使用率超过 90% 的分区需要立即处理否则可能引发服务故障。注意inode的使用情况特别是存在大量小文件的系统。使用df -i查看。3.2 定位大文件与清理策略使用du命令逐层定位占用空间大的目录或文件。# 查看当前目录下各子目录的大小 du -sh ./* | sort -rh | head -10 # 在整个根目录下查找大于100M的文件耗时建议在业务低峰期进行 find / -type f -size 100M 2/dev/null | xargs ls -lh | head -20常见可清理目标应用日志文件配置日志轮转logrotate。临时文件/tmp,/var/tmp。软件包缓存yum clean all(CentOS/RHEL) 或apt-get clean(Ubuntu/Debian)。容器或镜像缓存docker system prune -a确认无用后。旧的备份文件或安装包。3.3 评估磁盘 I/O 性能使用iostat命令来自sysstat包评估磁盘的读写性能和繁忙程度。# 每2秒刷新一次共输出5次显示扩展统计信息 iostat -x 2 5关键指标解读%util设备利用率。接近 100% 表示设备接近满负荷运行I/O 请求可能面临排队。await平均 I/O 等待时间毫秒。包括队列时间和服务时间。值越大说明 I/O 响应越慢。r/s,w/s每秒读写请求数。rkB/s,wkB/s每秒读写数据量KB。avgqu-sz平均请求队列长度。队列越长等待时间可能越长。3.4 常见问题与排查路径现象可能原因检查命令/位置处理建议磁盘空间使用率 90%日志未轮转、临时文件堆积、业务数据增长超预期。df -hdu -sh /var/log/*查找大文件。紧急清理大日志/临时文件扩容磁盘优化业务数据归档策略。%util持续 80%await很高磁盘 I/O 成为瓶颈。可能是大量随机读写、硬件性能不足或 RAID 卡策略问题。iostat -x 1iotop查看进程级 I/O检查RAID状态。优化数据库索引减少随机读将日志移到单独磁盘升级为 SSD检查 RAID 重建状态。inode用尽但磁盘空间充足文件系统存在海量小文件。df -ifind /mount_point -type fwc -l 估算文件数。磁盘读写性能突然下降硬件故障如坏道、RAID 降级、或某个进程异常大量写盘。dmesggrep -i errorsmartctl -a /dev/sda需安装 smartmontoolsiotop -o。4. 第四项网络连接与端口监听检查网络是服务的生命线。需要检查网络连通性、端口监听状态、异常连接以及带宽使用情况。4.1 检查网络连通性与延迟# 检查到网关或核心服务的连通性 ping -c 4 网关IP或外部域名 # 使用 mtr 进行路由追踪结合了 ping 和 traceroute 的功能 mtr -r -c 10 目标IP或域名4.2 检查端口监听与网络连接使用netstat或更现代的ss命令。# 查看所有监听端口 (LISTEN) ss -tulnp # 或 netstat -tulnp # 查看所有已建立的 TCP 连接 ss -tan state established # 查看 TIME-WAIT 状态的连接高并发服务需关注 ss -tan state time-wait命令输出解读-tTCP 协议。-uUDP 协议。-l仅显示监听套接字。-n以数字形式显示地址和端口不解析。-p显示进程信息需要 sudo 权限。state established已建立的连接状态。4.3 分析网络带宽与流量使用sar、iftop或nethogs工具。# 使用 sar 查看历史网络流量需 sysstat sar -n DEV 1 5 # 使用 iftop 实时查看各连接的带宽占用需安装 sudo iftop -i eth0 # 使用 nethogs 查看进程级的网络流量需安装 sudo nethogs eth0sar -n DEV输出关键列rxkB/s每秒接收的千字节数。txkB/s每秒发送的千字节数。%ifutil网络接口利用率估算值。4.4 常见问题与排查路径现象可能原因检查命令/位置处理建议服务端口未监听服务进程未启动、崩溃、或监听地址配置错误。ss -tlnpgrep 端口号systemctl status 服务名检查应用配置文件。TIME-WAIT状态连接过多短连接高并发场景下的正常现象但过多会占用端口资源。ss -tan state time-waitwc -lsysctl net.ipv4.tcp_max_tw_buckets。网络带宽跑满被攻击、爬虫、或某个进程异常上传/下载。iftopnethogs结合iptables或流量监控图表分析。定位异常 IP 或进程配置防火墙规则限流联系网络提供商或调整带宽。网络连接数异常高连接泄漏、未正常关闭、或遭受连接型攻击。ss -s查看统计netstat -nawk /^tcp/ {S[$NF]} END {for(a in S) print a, S[a]} 统计各状态连接数。5. 第五项系统日志与关键服务状态检查日志是排查问题的第一现场。系统关键服务如 sshd, crond的异常可能导致无法登录或定时任务失效。5.1 检查系统关键日志日志文件通常位于/var/log/目录下。# 查看系统最近的重要消息包含内核、系统服务等 sudo tail -100 /var/log/messages # CentOS/RHEL sudo tail -100 /var/log/syslog # Ubuntu/Debian # 查看安全相关日志如认证失败、sudo 使用 sudo tail -100 /var/log/secure # CentOS/RHEL sudo tail -100 /var/log/auth.log # Ubuntu/Debian # 查看内核环形缓冲区消息常用于查看硬件错误或启动信息 dmesg | tail -50 # 查看系统启动以来的所有消息筛选错误 journalctl -xe --no-pager | grep -E -i (error|fail|exception) | tail -30巡检要点关注error,fail,exception,panic,oom,denied等关键字。关注频繁的认证失败记录可能预示暴力破解攻击。关注硬件相关的错误如disk,memory,cpu。5.2 检查关键系统服务状态使用systemctl命令检查服务的运行状态、是否启用和最近日志。# 检查 sshd 服务状态 systemctl status sshd # 检查 crond 服务状态 systemctl status crond # 检查 NTP/Chrony 时间同步服务状态 systemctl status chronyd # 或 ntpd # 检查关键业务服务的状态根据实际情况替换 systemctl status nginx systemctl status mysql systemctl status docker状态解读active (running)服务正在运行。active (exited)单次运行的任务已成功完成。inactive (dead)服务未运行。failed服务启动失败。必须重点关注使用journalctl -u 服务名查看详细错误日志。5.3 检查定时任务Cron Job定时任务异常可能导致备份失败、数据同步中断等问题。# 查看系统级定时任务 sudo cat /etc/crontab sudo ls -la /etc/cron.d/ # 查看当前用户的定时任务 crontab -l # 查看所有用户的定时任务需要 root for user in $(cut -f1 -d: /etc/passwd); do echo $user ; sudo crontab -u $user -l 2/dev/null; done巡检要点确认关键备份或同步任务存在且语法正确。检查任务执行的日志通常配置了输出重定向或查看/var/log/cron。注意环境变量问题在 cron 任务中最好使用绝对路径并设置必要的环境变量。5.4 常见问题与排查路径现象可能原因检查命令/位置处理建议/var/log/messages或syslog中出现大量认证失败日志SSH 暴力破解攻击。grep Failed password /var/log/secure | awk {print $11} | sort | uniq -c | sort -rn统计攻击源 IP。配置防火墙如fail2ban自动封禁修改 SSH 端口使用密钥认证替代密码。关键服务状态为failed配置错误、依赖服务未启动、端口冲突、权限不足。systemctl status 服务名journalctl -u 服务名 --no-pager -n 50。根据日志错误信息修正配置确保依赖服务已启动检查端口占用 (ss -tlnp | grep :端口)检查文件权限和 SELinux 上下文。定时任务未执行cron 服务未运行、环境变量问题、命令路径错误、权限问题。systemctl status crond检查 crontab 语法查看/var/log/cron日志在任务中手动设置PATH变量。启动 cron 服务在 crontab 中使用绝对路径并设置SHELL和PATH以对应用户身份手动执行命令测试。系统时间不同步NTP/Chrony 服务异常、防火墙阻断 NTP 端口。timedatectl statuschronyc sources -vChrony或ntpq -pnNTP。启动并配置时间同步服务放行防火墙 123 端口手动同步chronyc makestep或ntpdate。6. 构建自动化巡检脚本与最佳实践手动执行上述检查费时费力且容易遗漏。将关键检查点脚本化、自动化并定期执行是提升运维效率的必经之路。6.1 编写一个基础的 Shell 巡检脚本以下是一个示例脚本server_check.sh它集成了前文提到的核心检查点并输出到日志文件。#!/bin/bash # 基础服务器巡检脚本 # 作者运维工程师 # 日期$(date %Y%m%d) LOG_FILE/var/log/server_inspection_$(date %Y%m%d_%H%M%S).log { echo 服务器巡检报告 echo 巡检时间: $(date) echo 主机名: $(hostname) echo echo -e \n1. 系统负载与CPU信息 echo ------------------------------------- uptime echo CPU核心数: $(nproc) mpstat -P ALL 1 1 | tail -5 echo -e \n2. 内存使用情况 echo ------------------------------------- free -h echo -e \nSwap使用情况: swapon -s echo -e \n3. 磁盘空间使用率 echo ------------------------------------- df -h echo -e \nInode使用情况: df -i echo -e \n4. 磁盘I/O性能概览 (最近5秒) echo ------------------------------------- iostat -x 1 5 | tail -15 echo -e \n5. 网络连接统计 echo ------------------------------------- ss -s echo -e \n监听端口: ss -tulnp | head -20 echo -e \n6. 关键系统服务状态 echo ------------------------------------- for service in sshd crond chronyd rsyslog; do systemctl is-active $service /dev/null 21 statusActive || statusInactive/Failed echo $service: $status done echo -e \n7. 系统日志关键错误 (最近20条) echo ------------------------------------- journalctl -xe --no-pager -n 20 | grep -E -i (error|fail|exception|panic) | tail -10 || echo 未发现关键错误日志。 echo -e \n 巡检结束 } | tee $LOG_FILE echo 巡检报告已保存至: $LOG_FILE使用说明将脚本保存到服务器例如/usr/local/bin/server_check.sh。赋予执行权限chmod x /usr/local/bin/server_check.sh。可以手动执行或通过cron定时执行如每天凌晨2点。脚本使用tee命令同时输出到屏幕和日志文件。6.2 生产环境巡检最佳实践非侵入性与安全性巡检脚本不应修改系统配置或影响正在运行的服务。避免在脚本中使用rm -rf等危险命令。以最小必要权限运行可通过sudo配置特定命令的执行权限。阈值告警而非仅记录脚本不应只记录信息而应判断关键指标如磁盘使用率 90%、内存可用 10%、服务状态异常并触发告警发送邮件、调用告警平台 API 等。历史数据对比简单的日志记录难以发现趋势。应将关键指标CPU、内存、磁盘、连接数写入时间序列数据库如 InfluxDB并使用 Grafana 等工具进行可视化便于观察趋势和设置智能告警。覆盖全面除了系统层还应包括应用层巡检如Web 服务检查 HTTP 状态码、接口响应时间。数据库检查连接数、慢查询、锁等待。中间件检查队列堆积、缓存命中率。业务层面检查核心交易流水、对账文件是否生成。标准化与文档化为所有服务器制定统一的巡检清单和脚本。记录每次巡检发现的问题和处理结果形成知识库。定期复核与更新业务和系统架构会变化巡检项和告警阈值也需要定期复核和调整。6.3 从巡检到监控的演进日常巡检是主动运维的起点但人力巡检频率有限通常天/周。对于需要秒级/分钟级响应的生产系统必须建立完善的监控体系基础设施监控使用 Zabbix、Prometheus Node Exporter 监控 CPU、内存、磁盘、网络等。应用性能监控 (APM)使用 SkyWalking、Pinpoint 监控应用内部调用链、JVM 状态、SQL 性能等。日志集中分析使用 ELKElasticsearch, Logstash, Kibana或 Loki 收集和分析所有服务器日志便于关联排查。统一告警平台将 Zabbix、Prometheus、业务自检等所有告警信息汇聚到如 Alertmanager、钉钉/企业微信机器人、PagerDuty 等平台并设置合理的升级策略。自动化巡检脚本可以作为监控系统的补充用于执行一些定制化的、非标准化的检查点或者在监控系统失效时提供最后一道保障。服务器日常巡检是运维工程师的基本功其价值在于将隐性的系统风险显性化。固定先看“负载 CPU、内存 Swap、磁盘空间 I/O、网络连接、系统日志服务状态”这五项能够快速构建起对服务器健康度的整体认知。掌握每一项背后的命令、指标解读和排查路径则能让你从“知道有问题”进阶到“快速定位并解决问题”。最终通过脚本化、自动化和与监控告警体系的结合可以将你从重复的日常检查中解放出来更专注于架构优化和故障深层根因分析。