这次我们来看一个非常实际的 Linux 运维问题服务器日常巡检。很多新手面对一台服务器感觉千头万绪不知从何下手。这篇文章不搞长篇大论直接聚焦老师傅们上机后固定会先检查的 5 个核心项。无论你是管理单台服务器还是维护一个小型集群这套方法都能帮你快速建立巡检的“肌肉记忆”在几分钟内对服务器健康状况有个基本判断。这 5 项检查覆盖了系统负载、资源瓶颈、服务状态、安全登录和存储空间是排查绝大多数线上问题的起点。它们不依赖复杂的监控工具仅用最基础的 Linux 命令即可完成非常适合在 SSH 登录后第一时间执行。本文将逐一拆解每项检查的命令、关键指标解读以及异常排查思路让你看完就能用。1. 核心能力速览五分钟快速巡检清单在深入细节之前我们先通过一个表格快速了解这 5 项核心巡检内容及其价值。这相当于一份“上机检查单”帮你建立系统性思维。检查项核心命令/工具关注关键指标主要目的1. 系统负载与进程top/htop/uptime负载平均值(1,5,15分钟)、CPU使用率、僵尸进程判断系统当前繁忙程度识别异常高负载进程。2. 内存与交换空间free -h总内存、已用内存、可用内存、交换空间使用率发现内存泄漏或内存不足导致的性能瓶颈。3. 磁盘空间与I/Odf -h/du -sh/iostat磁盘使用率、Inode使用率、I/O等待时间(%iowait)预防因磁盘写满导致的服务崩溃发现磁盘I/O瓶颈。4. 关键服务状态systemctl status 服务名服务Active状态、日志中的错误信息确保Web、数据库、中间件等核心服务正常运行。5. 安全与登录日志last/who/grep查看日志异常登录IP、失败登录尝试、非授权用户排查潜在的安全入侵和暴力破解行为。这套方法的特点是直接、快速、可重复。它不追求大而全的监控报表而是强调在紧急情况或日常登录时用最短时间抓住主要矛盾。2. 适用场景与使用边界这套巡检方法主要适用于以下场景日常健康检查每天或每周登录服务器进行的例行检查。故障初步定位当收到报警或用户反馈服务缓慢、不可用时快速缩小问题范围。新服务器上线验收验证新部署的服务器基础运行状态是否良好。缺乏完善监控系统时在监控平台尚未覆盖或临时失效时作为手动补充手段。使用边界与注意事项非实时监控替代品这是“点检”无法替代Zabbix、Prometheus等实时监控系统的“线”和“面”的监控。需要人工执行本文介绍的是手动命令适用于服务器数量不多或临时检查。对于成百上千台的运维必须实现自动化巡检脚本或平台。命令结果需结合上下文解读例如高CPU使用率在业务高峰期可能是正常的在凌晨则可能是异常的。需要结合业务周期判断。安全合规检查登录日志时需遵守公司安全审计规定不得用于非授权访问。3. 环境准备与前置条件进行巡检前你需要确保具备以下条件操作系统绝大多数Linux发行版如CentOS/RHEL 7 Ubuntu 18.04 Debian等均可。命令可能存在细微差异本文以通用格式为主。访问权限拥有目标服务器的SSH登录权限并且是root用户或具有sudo权限的普通用户。部分命令如查看所有进程、某些日志文件需要较高权限。终端工具任意SSH客户端如PuTTY, SecureCRT, Xshell或本地终端。基础命令系统默认应已安装top,free,df,du,iostat可能需安装sysstat包systemctl,last,who,grep等核心工具。对于iostat等可能未预装的工具可使用包管理器安装# 对于 CentOS/RHEL/Fedora sudo yum install sysstat -y # 或 sudo dnf install sysstat -y # 对于 Ubuntu/Debian sudo apt-get update sudo apt-get install sysstat -y4. 第一项检查系统负载与进程 (top/uptime)登录服务器后第一个命令通常是看整体负载。操作与解读查看负载平均值uptime输出示例12:05:03 up 30 days, 20:15, 2 users, load average: 0.08, 0.03, 0.01load average: 0.08, 0.03, 0.01是关键分别代表过去1分钟、5分钟、15分钟的系统平均负载。如何解读对于单核CPU负载1.00表示刚好满负荷。通常如果15分钟负载持续高于CPU核心数就需要警惕。例如4核CPU负载长期高于4说明系统过载。动态查看资源与进程top进入交互式界面。重点关注以下几行第一行同uptime看负载。第二、三行%Cpu(s)看CPU使用率。特别关注%us用户空间、%sy系统内核、%id空闲和%waI/O等待。如果%wa很高说明磁盘I/O可能是瓶颈。第四、五行KiB Mem/KiB Swap看物理内存和交换分区使用情况下一节细讲。进程列表默认按CPU使用率排序。可以按M键改为按内存排序按P键切回CPU排序。寻找长期占用资源异常高的进程。更友好的进程查看器htop如果系统安装了htopyum/apt install htop它比top更直观支持颜色、鼠标操作和树状视图强烈推荐使用。异常排查思路负载高但CPU使用率不高很可能卡在I/O%wa高或锁等待上。结合下一节的iostat和后续的进程状态判断。发现僵尸进程Z状态少量僵尸进程通常无害父进程结束时会清理。如果大量出现需要找到其父进程IDPPID检查对应程序是否有bug。某个进程CPU/内存异常高记录下PID和命令名使用ps aux | grep PID或cat /proc/PID/status查看详细信息判断是否为正常业务进程。5. 第二项检查内存与交换空间 (free)内存不足会直接导致服务卡顿、OOMOut-Of-Memory进程被杀死。操作与解读free -h输出示例total used free shared buff/cache available Mem: 7.6G 3.2G 1.1G 345M 3.3G 3.7G Swap: 2.0G 0B 2.0G-h参数让数据以人类易读的单位G, M显示。关键看available这个值表示系统可供新应用程序使用的内存量它比free更准确因为buff/cache部分在需要时可以被回收。经验值如果available内存长期低于总内存的10%就需要关注可能需要考虑优化应用或扩容内存。Swap使用查看Swap行的used。如果Swap被频繁使用used值持续增长说明物理内存严重不足系统性能会因磁盘换入换出而急剧下降。Swap used 0 是一个明确的警告信号。深入分析内存使用 如果free显示内存紧张可以用top或htop排序找出内存消耗大的进程。还可以使用# 查看内存占用最高的10个进程 ps aux --sort-%mem | head -116. 第三项检查磁盘空间与I/O (df,du,iostat)磁盘满是一个“低级”但后果严重的问题会导致服务无法写入日志、数据库崩溃、系统无法登录等。1. 检查磁盘空间使用率df -h输出示例Filesystem Size Used Avail Use% Mounted on /dev/vda1 50G 45G 2.0G 96% / /dev/vdb1 200G 50G 140G 26% /data重点关注Use%列通常报警阈值设置在80%或90%。像根目录/使用率达到96%就是非常紧急的状态必须立即清理。同时关注Inode使用率文件数量爆满也会导致“磁盘空间不足”的假象。df -i2. 定位大文件或大目录 如果某个分区快满了需要找到“元凶”。# 查看当前目录下各子目录的大小 du -sh * # 或者查找指定目录下最大的10个文件或目录 du -a /path/to/dir | sort -n -r | head -n 103. 检查磁盘I/O性能 系统卡顿但CPU和内存都不高很可能是磁盘I/O瓶颈。# 查看磁盘整体统计信息安装sysstat后 iostat -dx 1 5-d显示设备统计。-x显示扩展统计。1 5表示每秒刷新一次共输出5次。关键指标%util设备利用率。接近100%表示设备接近满负荷。await平均I/O等待时间毫秒。值越大说明I/O响应越慢。svctm平均服务时间毫秒。通常应小于await。结合top中的%wa一起看如果%wa和%util都高基本确定是磁盘I/O问题。7. 第四项检查关键服务状态 (systemctl)确保核心业务服务在运行是巡检的根本目的。操作与解读# 查看服务的状态以nginx为例 systemctl status nginx输出信息中重点关注Active:一行。active (running)是理想状态。如果是inactive (dead)或failed说明服务挂了。Loaded:一行。显示单元文件是否正确加载。下方的日志片段通常会显示最近的服务日志可能包含错误信息。常用服务管理命令# 查看所有失败的服务 systemctl --failed # 查看某个服务的详细日志journalctl需要sudo sudo journalctl -u nginx -n 50 --no-pager # 查看nginx服务最后50行日志 sudo journalctl -u nginx --since 2023-10-01 --until 2023-10-02 # 查看时间范围日志 # 重启服务 sudo systemctl restart nginx # 设置开机自启 sudo systemctl enable nginx巡检清单你应该有一份自己负责的服务列表例如nginx,mysql,redis,docker,crond,sshd等。巡检时逐个检查。8. 第五项检查安全与登录日志 (last,who, 日志分析)安全无小事检查异常登录是防范于未然。1. 查看近期成功登录记录last -n 20这个命令读取/var/log/wtmp文件显示最近的登录记录。关注陌生的用户名、IP地址和时间。2. 查看当前登录用户who或ww命令信息更丰富包括用户正在执行的命令。检查是否有非授权的当前登录。3. 检查失败登录尝试重点 暴力破解攻击会留下大量失败记录。# 对于使用 password 认证的 SSH查看失败日志CentOS/RHEL sudo grep Failed password /var/log/secure | tail -20 # 或查看所有认证日志 sudo tail -50 /var/log/secure # 对于 Ubuntu/Debian日志通常在 /var/log/auth.log sudo grep Failed password /var/log/auth.log | tail -20输出会显示尝试登录的IP、用户名和时间。如果发现某个IP在短时间内有大量失败尝试很可能正在被暴力破解。4. 检查空密码或可疑授权# 检查是否有空密码账户 sudo awk -F: ($2 ) {print $1} /etc/shadow # 检查sudoers列表 sudo cat /etc/sudoers | grep -v ^# | grep -v ^$自动化安全巡检思路对于这项检查更佳实践是配置fail2ban等工具自动封禁恶意IP并定期将日志汇总到SIEM安全信息与事件管理系统进行分析。9. 资源占用与性能观察整合将前几项的观察点整合起来形成性能瓶颈分析的思路CPU瓶颈top中%Cpu(s)的%us或%sy持续高于80%且负载load average持续高于CPU核心数。使用top或htop排序找出具体进程。内存瓶颈free -h显示available内存极低且Swap的used值在增长。使用top按内存排序找出进程。I/O瓶颈top中%Cpu(s)的%wa高同时iostat中磁盘的%util高、await高。可能是磁盘硬件慢或某个进程在进行大量磁盘读写用iotop命令查看。网络瓶颈本文未详述但可用sar -n DEV 1或iftop命令查看网络接口流量和连接数。10. 常见问题与排查方法问题现象可能原因排查方式解决方案SSH登录缓慢DNS解析问题、认证日志过大、GSSAPI认证ssh -vvv查看详细日志检查/etc/ssh/sshd_config中UseDNS设置检查/var/log/secure或/var/log/auth.log大小禁用UseDNS清理或轮转日志禁用GSSAPI认证df显示磁盘满但du找不到大文件文件已被删除但进程仍持有句柄空间未释放lsof | grep deleted查找被删除但仍被进程占用的文件重启持有该文件的进程或清空该进程的输出如日志服务systemctl status显示failed启动脚本错误、依赖服务未启动、端口被占用、权限问题sudo journalctl -u 服务名 -xe查看详细错误日志根据日志修正配置、解决依赖、更换端口或修改权限负载很高但CPU和I/O使用率都不高可能存在大量线程处于不可中断睡眠态D状态通常由I/O引起top查看%waps aux | grep “D”查看D状态进程使用iostat和iotop进一步分析优化导致高I/O的进程或查询考虑升级磁盘如HDD换SSD内存available持续减少但无进程明显占用可能是内核或驱动内存泄漏检查slabtop观察内核内存使用查看/proc/meminfo中的SUnreclaim项重启服务器可临时解决更新内核或相关驱动版本查找并修复泄漏源发现大量来自同一IP的失败登录遭受SSH暴力破解攻击sudo grep “Failed password” /var/log/secure | awk ‘{print $11}’ | sort | uniq -c | sort -nr统计IP使用fail2ban自动封禁修改SSH端口禁用密码登录改用密钥11. 最佳实践与使用建议制作巡检脚本将上述关键命令写入一个Shell脚本如server_check.sh一键执行并输出格式化报告。这是从手动到自动的第一步。#!/bin/bash echo “ $(date) 系统巡检 ” echo “1. 负载与运行时间” uptime echo “” echo “2. 内存使用” free -h echo “” echo “3. 磁盘空间” df -h echo “” # ... 后续检查项设定巡检基线在业务平稳期运行巡检脚本记录CPU负载、内存可用量、磁盘使用率等指标的“正常范围”。当指标持续偏离基线时即使未触发报警也应引起注意。日志集中管理将多台服务器的关键日志如/var/log/messages,/var/log/secure通过rsyslog或Fluentd收集到中央日志服务器如ELK Stack便于统一分析和关联排查。与监控系统互补手工巡检是“点”监控系统是“面”。应将巡检脚本发现的关键指标如特定进程是否存在集成到Zabbix或Prometheus的自定义监控项中实现自动告警。文档化与交接将巡检步骤、常见问题排查清单、服务重启顺序、关键配置文件路径等形成文档。这是团队知识沉淀和运维交接的核心。这套“老师傅先看5项”的巡检方法其价值在于提供了一个清晰、可执行的切入点。它不能解决所有问题但能帮你快速排除80%的基础性故障。真正的运维深度在于基于这些基础指标结合业务逻辑进一步分析链路追踪、应用性能监控和数据库慢查询。建议从固化这5项检查开始逐步构建起属于你自己的、体系化的服务器运维监控能力。
