这次我们来看一个 Linux 服务器日常巡检的实战话题。对于运维工程师来说服务器巡检是保障业务稳定性的基础工作但巡检项目繁多新手往往不知从何下手。这篇文章不空谈理论直接聚焦于老师傅们在实际工作中会优先、固定检查的 5 个核心项。无论你是管理单台服务器还是小型集群掌握这 5 项检查就能快速抓住系统健康度的关键脉搏。本文将带你逐一拆解这 5 项核心巡检内容包括具体的检查命令、关键指标解读、异常判断标准以及简单的自动化脚本思路。目标是让你看完就能上手快速建立一套高效、可靠的服务器健康检查流程告别巡检时的盲目和遗漏。1. 核心巡检项速览在深入细节之前我们先通过一个表格快速了解这 5 项核心巡检内容及其重要性。这相当于老师傅的“检查清单”每次上机先过一遍心里就有底了。巡检项核心检查点常用命令/文件关键意义1. 系统负载与CPU1分钟/5分钟/15分钟平均负载CPU使用率与等待I/O时间僵尸进程。uptime,top,htop,vmstat 1 5判断系统当前及近期繁忙程度识别CPU瓶颈或I/O瓶颈。2. 内存使用总内存、已用内存、空闲内存、缓存/缓冲区Swap使用情况。free -h,top判断内存是否充足是否存在内存泄漏风险Swap是否被频繁使用。3. 磁盘空间与I/O各分区使用率Inode使用率磁盘I/O等待时间与利用率。df -h,df -i,iostat -x 1 3预防因磁盘满导致的业务中断识别磁盘性能瓶颈。4. 网络连接与端口网络连接状态ESTABLISHED, TIME_WAIT等监听端口与服务网络流量。ss -tunlp或netstat -tunlp,iftop/nethogs确认关键服务端口正常监听排查异常连接了解网络带宽占用。5. 关键服务与日志系统核心服务如sshd, crond状态系统日志/var/log/messages, dmesg最近错误。systemctl status service,journalctl,tail -f /var/log/messages确保基础运维服务正常运行及时发现硬件或应用层错误告警。这五项覆盖了从硬件资源CPU、内存、磁盘、网络到软件服务进程、端口、日志的完整链路是快速诊断服务器是否“健康”的黄金标准。2. 适用场景与使用边界这套巡检方法主要适用于以下场景日常健康检查每日或每周对服务器进行例行检查防患于未然。故障初步定位当收到业务报警或用户反馈缓慢时快速定位可能的问题方向是CPU、内存、磁盘还是网络问题。新服务器上线验收验证新部署的服务器资源分配是否合理基础服务是否正常。中小规模服务器集群管理即使管理多台服务器这套方法也能作为每台机器的基础检查模板。使用边界与注意事项深度监控的补充本文介绍的属于“手工”或“脚本化”的基础巡检它不能替代专业的监控系统如Zabbix, Prometheus。对于大规模、高可用的生产环境必须建立完善的自动化监控告警体系。安全合规执行巡检需要相应的系统权限。请确保你的操作符合公司的安全规范避免在巡检过程中执行高危命令。数据敏感性巡检命令可能输出系统配置、网络连接等敏感信息。请妥善保管巡检结果避免泄露。结合业务最关键的检查项往往与具体业务相关如数据库连接数、JVM堆内存、业务进程状态。本文的5项是通用基础你需要在此基础上叠加业务特有的检查点。3. 环境准备与前置条件进行巡检前你需要确保具备以下条件操作系统适用于绝大多数 Linux 发行版如 CentOS/RHEL 7, Ubuntu 18.04, Debian 等。命令可能因发行版略有差异如服务管理工具systemctlvsservice。访问权限你需要拥有目标服务器的登录权限通常是root用户或具有sudo权限的普通用户。对于批量巡检建议配置好 SSH 密钥免密登录。工具命令大部分命令系统已内置。如需更直观的工具可自行安装htop(替代top):yum install htop -y或apt install htop -yiftop(查看带宽):yum install iftop -y或apt install iftop -ynethogs(按进程查看带宽):yum install nethogs -y或apt install nethogs -ysysstat(包含iostat,mpstat等):yum install sysstat -y或apt install sysstat -y检查时机避免在业务高峰时段执行可能占用资源的检查如iostat持续监控基础状态查看影响极小。4. 第一项系统负载与CPU检查这是判断系统繁忙程度的首要指标。4.1 检查平均负载 (uptime)$ uptime 16:30:45 up 30 days, 2:15, 3 users, load average: 0.05, 0.10, 0.15关键看load average后的三个数值分别代表过去 1分钟、5分钟、15分钟的系统平均负载。如何解读对于单核CPU负载1.00表示刚好满负荷。理想情况下三个值应接近且长期低于CPU核心数。例如4核CPU负载长期在3.5以下可以接受。异常判断如果1分钟值远高于5分钟和15分钟值说明系统刚刚经历或正在经历一个压力尖峰。如果三个值持续高于CPU核心数 * 0.7就需要警惕并深入分析。如果负载很高但top看到CPU空闲%id很高很可能遇到了I/O瓶颈等待磁盘I/O的进程多。4.2 检查CPU使用详情 (top/htop)运行top命令然后按1可以展开显示所有CPU核心的详情。$ top -bn1 | head -20 # 非交互式获取一次快照或者使用htop更直观。重点关注以下几行%Cpu(s):行us(user): 用户空间进程占用CPU百分比。高通常表示应用繁忙。sy(system): 内核空间进程占用CPU百分比。过高可能表示系统调用频繁或内核有问题。id(idle): CPU空闲百分比。我们希望它高。wa(iowait):CPU等待I/O的时间百分比。这是关键指标如果这个值持续很高例如5%说明磁盘I/O可能成为瓶颈系统在等待磁盘读写。st(steal): 在虚拟化环境中被宿主机“偷走”的CPU时间。过高说明宿主机资源紧张。进程列表查看哪些进程占用了最高的CPU%CPU列。僵尸进程 (Zombies)在top输出的任务汇总行查看是否有僵尸进程。少量僵尸进程可能无害但大量出现需要排查父进程问题。4.3 使用 vmstat 查看整体状态$ vmstat 1 5 # 每秒采样一次共5次 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 501234 102384 1502340 0 0 5 12 30 45 5 2 92 1 0r(run): 运行队列中的进程数。长期大于CPU核心数说明CPU饱和。b(blocked): 等待I/O的进程数。如果持续大于0同样指示I/O瓶颈。wa(cpu iowait): 同top中的wa。巡检动作记录负载、wa值、是否有异常高CPU进程和僵尸进程。5. 第二项内存使用检查内存不足会直接导致应用崩溃或系统开始使用缓慢的Swap。5.1 检查内存总量与使用情况 (free)$ free -h total used free shared buff/cache available Mem: 7.6G 2.1G 500M 123M 5.0G 5.1G Swap: 2.0G 0B 2.0G关键解读重点看available列传统看法误区不要只看free列因为它包含了缓存cache和缓冲区buffer这部分内存在应用需要时可以被快速释放。正确指标available表示系统可供新应用程序使用的内存估计值。这是判断内存是否充足的最重要指标。如果available内存长期低于总内存的20%就需要关注。Swap使用 (si,so)在vmstat或sar -W命令中关注si(swap in) 和so(swap out)。如果它们持续大于0说明物理内存不足系统正在使用Swap性能会严重下降。free中看到 Swapused不为0且持续增长是严重警告。5.2 检查内存占用进程 (top)在top命令中按ShiftM可以按内存使用率排序进程列表查看是哪个进程消耗内存最多。巡检动作记录总内存、可用内存(available)、Swap使用量并观察是否有内存持续增长的进程潜在内存泄漏。6. 第三项磁盘空间与I/O检查磁盘满和磁盘慢是导致业务故障的常见原因。6.1 检查磁盘空间使用率 (df)$ df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/vda1 ext4 50G 35G 13G 73% / /dev/vdb1 xfs 100G 80G 20G 80% /data关键点使用率阈值通常设置告警阈值为80%-85%。超过此阈值需要清理日志或扩容。重点关注目录/,/var,/home,/data业务数据目录等。Inode 使用率磁盘空间没满但无法创建新文件可能是Inode用尽了。$ df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vda1 3276800 123456 3153344 4% /如果IUse%接近100%即使有空间也无法创建新文件常见于存在大量小文件的场景。6.2 检查磁盘I/O性能 (iostat)# 安装 sysstat 包后使用 $ iostat -x 1 3 Linux 3.10.0-1160.el7.x86_64 (localhost) 03/15/2024 _x86_64_ (2 CPU) Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util vda 0.12 1.25 5.12 30.15 0.00 0.07 0.00 5.26 0.25 1.12 0.00 42.67 24.12 0.20 0.03核心指标%util设备利用率。表示设备有I/O请求的时间百分比。如果持续接近100%说明磁盘I/O饱和成为瓶颈。await平均每次I/O请求的等待时间毫秒。包括队列时间和服务时间。值越高说明I/O越慢。svctm平均每次I/O请求的服务时间毫秒。理论上应小于await。r/s,w/s每秒读写请求数。rkB/s,wkB/s每秒读写数据量KB。巡检动作记录各分区使用率特别是根目录和业务目录观察iostat中的%util和await是否在正常范围通常await不应持续高于几十毫秒。7. 第四项网络连接与端口检查网络问题是业务不可访问的常见原因。7.1 检查网络连接状态 (ss/netstat)推荐使用更快的ss命令替代传统的netstat。# 查看所有TCP/UDP监听端口及对应进程 $ ss -tunlp Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port tcp LISTEN 0 128 *:22 *:* users:((sshd,pid1234,fd3)) tcp LISTEN 0 100 127.0.0.1:25 *:* users:((master,pid5678,fd13)) tcp ESTAB 0 0 10.0.0.1:22 10.0.0.100:54321 users:((sshd,pid9012,fd3))关键检查关键服务端口是否在监听如 SSH(22), Web(80/443), 数据库(3306, 5432)等。确保它们处于LISTEN状态。异常连接数TIME_WAIT连接过多可能影响新连接建立通常与网络服务配置有关。CLOSE_WAIT连接过多表示本地端口已关闭但对方还未关闭可能是应用程序未正确关闭连接存在泄漏风险。大量ESTABLISHED连接到非常用IP或端口需警惕是否被入侵或存在异常外联。查看特定端口连接数$ ss -ant | grep :80 | wc -l # 统计80端口的TCP连接数7.2 检查网络带宽 (iftop/nethogs)iftop查看整体网卡流量按主机对排序。$ sudo iftop -i eth0 # 指定网卡观察哪些IP地址占用了主要的进出带宽。nethogs按进程查看网络带宽占用。$ sudo nethogs eth0直接定位到是哪个进程在大量收发数据。巡检动作确认关键端口监听正常检查是否存在异常的大量TIME_WAIT/CLOSE_WAIT连接了解当前网络流量概况。8. 第五项关键服务与日志检查系统层面的资源正常但业务仍可能因服务异常或底层错误而失效。8.1 检查系统关键服务状态使用systemctl检查保障服务器基础运维和业务运行的核心服务。# 检查服务状态 $ systemctl status sshd crond network rsyslog # 一次检查多个服务 # 或逐个检查 $ systemctl status sshd ● sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2024-03-12 10:00:00 CST; 1 weeks 0 days ago Docs: man:sshd(8) man:sshd_config(5) Main PID: 1234 (sshd) Tasks: 1 Memory: 5.3M CGroup: /system.slice/sshd.service └─1234 /usr/sbin/sshd -D重点关注Active行必须是active (running)。如果是inactive (dead)或failed需要立即处理。8.2 检查系统日志最近错误日志是发现潜在问题的宝库。查看系统日志尾部$ tail -50 /var/log/messages # CentOS/RHEL $ tail -50 /var/log/syslog # Ubuntu/Debian快速浏览最近是否有error,warning,fail等关键词的报错信息。使用 journalctl 查看系统日志Systemd系统$ journalctl -xe --since 1 hour ago | grep -E -i (error|warn|fail) | head -20查看过去一小时内包含错误、警告、失败关键词的日志。检查内核日志$ dmesg -T | tail -30查看最近的内核消息常用于发现硬件错误如磁盘坏道I/O error、驱动问题等。巡检动作确保sshd, crond等基础服务运行正常快速扫描系统日志和内核日志捕获最近的异常记录。9. 巡检自动化脚本示例手动执行上述命令效率低容易遗漏。我们可以编写一个简单的 Shell 脚本将关键信息汇总输出。#!/bin/bash # filename: server_health_check.sh # 基础服务器健康检查脚本 echo 服务器健康检查报告 echo 检查时间: $(date) echo 主机名: $(hostname) echo 运行时间: $(uptime) echo echo 1. 系统负载与CPU echo ---------------------------------------- uptime echo echo CPU核心数: $(nproc) echo Top 5 CPU进程: ps aux --sort-%cpu | head -6 echo echo vmstat 快照: vmstat 1 3 echo echo 2. 内存使用 echo ---------------------------------------- free -h echo echo Top 5 内存进程: ps aux --sort-%mem | head -6 echo echo 3. 磁盘空间 echo ---------------------------------------- df -hT echo echo Inode使用情况: df -i echo echo 4. 网络连接 echo ---------------------------------------- echo 监听端口: ss -tunlp | head -20 echo echo TCP连接状态统计: ss -ant | awk NR1 {S[$1]} END {for(a in S) print a, S[a]} echo echo 5. 关键服务状态 echo ---------------------------------------- for service in sshd crond rsyslog; do systemctl is-active --quiet $service echo $service: Running || echo $service: ***NOT RUNNING*** done echo echo 6. 最近系统错误日志 (最后10行含error/warn) echo ---------------------------------------- journalctl -xe --since 1 hour ago | grep -E -i (error|warn) | tail -10 echo echo 检查结束 使用方法将脚本保存到服务器例如/opt/scripts/server_health_check.sh。赋予执行权限chmod x /opt/scripts/server_health_check.sh。执行脚本/opt/scripts/server_health_check.sh health_report_$(date %Y%m%d).log 21可以将输出重定向到日志文件。可以通过crontab定时任务定期执行并将报告发送到邮箱或存储到特定目录。脚本增强方向添加阈值判断如磁盘使用率85%则报警。集成邮件发送功能如mailx。适配多台服务器通过for循环或pssh工具批量执行。10. 常见问题与排查方法在巡检过程中你可能会遇到以下典型问题这里提供排查思路。问题现象可能原因排查命令/步骤解决方案建议负载高但CPU空闲(id高)I/O 瓶颈wa高进程在等待磁盘。vmstat 1,iostat -x 1,iotop1. 使用iotop定位高IO进程。2. 检查磁盘使用率(df -h)和IO性能(iostat)。3. 优化应用读写或考虑升级磁盘如SSD。available内存极低Swap使用高物理内存不足系统频繁使用Swap。free -h,top按内存排序1. 使用top或ps找出内存消耗最大的进程。2. 评估是否为内存泄漏进程内存持续增长不释放。3. 考虑增加物理内存或优化应用内存配置。磁盘使用率快速达到100%日志文件暴增或大文件未及时清理。du -sh /* | sort -hr | head -101. 使用du命令逐层定位占用最大的目录。2. 检查/var/log/,/tmp/等目录。3. 设置日志轮转logrotate清理临时文件。关键服务端口未监听服务未启动或配置了错误监听地址/端口。ss -tunlp | grep :端口号,systemctl status 服务名1. 检查服务状态并尝试启动。2. 检查服务配置文件如/etc/ssh/sshd_config。3. 检查防火墙是否放行了该端口。大量TIME_WAIT连接短连接频繁建立和关闭常见于Web服务器。ss -ant | grep TIME-WAIT | wc -l1. 属于正常现象但过多可能影响性能。2. 可考虑优化内核TCP参数如net.ipv4.tcp_tw_reuse,tcp_tw_recycle需谨慎。3. 优化应用程序连接池。大量CLOSE_WAIT连接应用程序未正确关闭Socket连接。ss -ant | grep CLOSE-WAIT1.这是程序bug的迹象。2. 根据ss命令输出的进程PID定位到具体应用程序。3. 检查应用代码的连接关闭逻辑或重启应用临时恢复。系统日志中出现I/O error磁盘可能出现坏道或硬件故障。dmesg | grep -i error,smartctl -a /dev/sda1. 立即备份数据2. 使用smartctl需安装smartmontools检查磁盘SMART健康状态。3. 联系硬件供应商或准备更换磁盘。11. 最佳实践与使用建议将日常巡检从手动操作转化为高效、可靠的例行工作需要遵循一些最佳实践建立标准化流程为团队制定统一的巡检清单本文的5项可作为核心确保每个人检查的项目和判断标准一致。脚本化与自动化像第9节那样将固定检查命令编写成脚本。通过crontab定时执行并将输出结果归档或发送到团队邮箱/群机器人。设定明确阈值为关键指标设定告警阈值如CPU负载核心数*2内存可用20%磁盘使用率85%并在脚本中实现判断逻辑触发时发送明确告警。历史数据对比记录每次巡检的关键数据如可用内存、磁盘空间。观察其变化趋势可以在资源耗尽前提前预警例如磁盘每周增长5%推算何时会满。结合业务监控系统层面健康不代表业务健康。务必结合业务自身的监控指标如应用响应时间、数据库连接数、业务队列长度等进行综合判断。安全与权限管理巡检脚本应使用具有必要权限的专用账号执行避免使用root。妥善保管脚本和日志防止敏感信息泄露。定期回顾与更新业务和系统架构会变巡检项也应定期评审和更新确保检查项始终覆盖当前最重要的风险点。12. 总结与下一步服务器日常巡检是运维工作的基本功其价值在于“主动发现”而非“被动救火”。本文拆解的5项核心检查——系统负载、内存、磁盘、网络、服务与日志——为你提供了一个清晰、可立即执行的起点。最值得你马上行动的是在你负责的服务器上手动运行一遍这5项的所有检查命令熟悉正常状态下的输出是什么样的。然后将第9节的脚本部署到一台测试机上运行根据输出调整阈值形成适合你环境的巡检基线。最容易踩的坑是只关注单一指标。例如看到CPU负载高就以为是计算瓶颈但很可能根源是磁盘I/O等待wa高。因此必须关联着看高负载时配合看vmstat的wa和iostat的%util内存不足时用top排序找出“真凶”。下一步你可以沿着两个方向深化横向扩展将脚本改造为支持多台服务器批量巡检并集成到你的运维平台或通过Ansible等工具下发。纵向深入针对每一项深入研究其调优方法。例如如何优化Linux内核参数减少TIME_WAIT如何配置logrotate更有效地管理日志如何使用pidstat、perf等工具进行更细致的性能剖析。把这套方法固化为习惯你就能像老师傅一样在几分钟内对一台陌生服务器的健康状况做出快速、准确的初步判断为后续的深度排查和问题解决赢得宝贵时间。建议收藏本文并动手创建你自己的巡检脚本库。
