在服务器运维的日常工作中你是否曾面对几十甚至上百台服务器感到无从下手是否担心某个深夜因为一个未被察觉的磁盘满或内存泄漏导致服务中断服务器巡检这个看似基础却至关重要的环节往往是区分新手运维和资深“老师傅”的关键。很多运维同学知道要巡检但巡检什么、怎么高效地检、检出了问题如何快速定位却缺乏一套系统的方法。本文将为你拆解一套经过实战检验的服务器日常巡检核心框架。我们不追求大而全的检查清单而是聚焦于那些真正能提前发现隐患、保障服务稳定的“黄金五项”。无论你是管理单台测试机还是维护一个庞大的服务器集群掌握这五项核心检查都能让你对服务器健康状况了如指掌将问题扼杀在摇篮之中。1. 巡检的核心价值与“黄金五项”概述在深入命令之前我们首先要明确服务器巡检不是为了应付任务而是为了主动发现风险、保障业务连续性、积累系统基线数据。一次有效的巡检应该能回答以下几个问题系统资源是否充足且使用合理关键服务是否在正常运行系统是否存在安全或性能隐患历史运行趋势是否健康基于这些目标并结合大量线上故障的复盘经验我们提炼出运维“老师傅”们必定优先关注的五项核心检查它们构成了服务器健康度的第一道防线系统负载与CPU使用率反映系统整体繁忙程度和计算资源压力。内存使用与交换空间揭示内存是否充足是否存在泄漏或过度使用交换区导致性能骤降。磁盘空间与Inode使用率预防因日志暴涨、临时文件堆积导致的“磁盘写满”经典故障。关键进程与服务状态确保业务核心进程存活监听端口正常。系统日志与安全审计从系统日志中捕捉错误、警告信息并检查异常登录记录。接下来我们将逐一深入这五项检查不仅告诉你“看什么”更详细解释“为什么看”以及“怎么看懂数据背后的故事”。2. 环境与工具准备在进行巡检前确保你有一个可用的Linux服务器环境并拥有适当的权限通常需要root或具有sudo权限的账户。本文演示基于CentOS 7 / Rocky Linux 8或Ubuntu 20.04/22.04等主流发行版大部分命令具有通用性。基础工具这些工具通常系统自带无需额外安装。ssh用于远程连接服务器。top/htop实时进程查看器。free/vmstat内存查看工具。df/du磁盘空间查看工具。ps/systemctl进程与服务管理工具。journalctl/tail日志查看工具。netstat/ss网络连接与端口查看工具。last/who用户登录信息查看工具。可选效率工具对于需要管理多台服务器的场景可以考虑Shell脚本将检查命令自动化。Ansible实现批量服务器的并行巡检与结果收集。Prometheus Grafana搭建长期监控与可视化告警平台这是巡检的自动化与可视化进阶。我们首先从单机手动检查开始这是理解原理的基础。3. 第一项系统负载与CPU使用率——系统繁忙度的“体温计”系统负载Load Average和CPU使用率是判断服务器当前压力最直观的指标。很多人只看CPU使用率其实负载平均值更能反映系统的“拥堵”情况。3.1 核心概念与命令负载平均值Load Averageuptime或top命令输出中load average: 0.01, 0.05, 0.15这样的数字。它表示系统在最近1分钟、5分钟、15分钟内的平均活跃进程数处于可运行状态或不可中断睡眠状态的进程。对于单核CPU负载为1.0表示CPU刚好满负荷对于4核CPU负载为4.0表示所有核心满负荷。CPU使用率top命令中%Cpu(s)行重点关注us用户空间程序占用CPU百分比。sy内核空间占用CPU百分比。id空闲CPU百分比。wa等待I/O如磁盘读写的CPU百分比。高wa通常意味着磁盘可能存在瓶颈。常用命令# 查看负载平均值和系统运行时间 uptime # 动态查看进程和CPU、内存使用情况按q退出 top # 更友好、彩色的top替代品可能需要安装yum install htop / apt install htop htop # 查看每个CPU核心的详细使用情况 mpstat -P ALL 1 # 每秒刷新一次显示所有CPU核心状态3.2 实战解读与阈值判断运行top命令后我们看第一部分top - 14:30:00 up 30 days, 3:15, 1 user, load average: 1.25, 0.80, 0.50 Tasks: 125 total, 1 running, 124 sleeping, 0 stopped, 0 zombie %Cpu(s): 5.6 us, 2.1 sy, 0.0 ni, 92.0 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st解读与行动指南负载load average: 1.25, 0.80, 0.50这是一台4核CPU的服务器。1分钟负载是1.25小于CPU核数4说明当前压力不大。关键看趋势如果1分钟值远高于5分钟和15分钟值例如3.50, 1.20, 0.80说明系统压力正在快速上升需要立即关注。如果15分钟值持续高于CPU核数例如5.10, 5.05, 5.00说明系统长期过载必须扩容或优化。CPU使用率92.0 id空闲率高达92%CPU非常空闲。警报场景如果id低于20%并且us或sy很高说明计算资源紧张。如果wa超过5%甚至更高强烈提示磁盘I/O可能存在瓶颈需要结合下一节的磁盘检查。老师傅技巧单独的高CPU使用率不一定有问题可能是正常业务处理。需要结合负载看高负载 高CPU使用率 真繁忙高负载 低CPU使用率 可能卡在I/O或锁等待。4. 第二项内存使用与交换空间——性能的“隐形杀手”内存不足会触发系统使用交换分区Swap而Swap的读写速度远低于物理内存一旦频繁使用系统性能会断崖式下跌。4.1 核心概念与命令物理内存服务器的实际RAM。缓冲Buffer与缓存Cachefree命令中buff/cache。这是Linux内核为了提高磁盘I/O性能而占用的内存。这部分内存在应用程序需要时可以被快速回收因此通常不被视为“已用”内存。这是新手最容易误解的地方。交换空间Swap当物理内存不足时将不活跃的内存页写入磁盘交换区。Swap使用是内存不足的最后防线但也是性能的坟墓。常用命令# 查看内存和Swap使用情况传统显示易误解 free -m # 推荐以更易懂的方式查看内存CentOS 7 / Ubuntu 16.04 free -h # 查看更详细的内存统计信息 cat /proc/meminfo # 查看虚拟内存统计包括Swap in/outsi/so这是关键 vmstat 1 5 # 每秒采样一次共5次4.2 实战解读与阈值判断运行free -htotal used free shared buff/cache available Mem: 7.6G 2.1G 3.2G 345M 2.3G 4.9G Swap: 2.0G 0B 2.0G解读与行动指南关键看available4.9G表示系统估算的、可供启动新应用程序而无需交换的内存大小。这是判断内存是否充足的黄金指标。如果available长期低于总内存的20%本例中低于1.5G就需要警惕。不要被used吓到used(2.1G) 包含了buff/cache(2.3G)。实际上应用程序直接使用的内存可能很少。真正已用的、难以回收的内存 ≈used - buff/cache。Swap是终极警报本例中Swap使用为0B这是健康的。一旦Swap下的used开始增长尤其是配合vmstat看到si(swap in) 和so(swap out) 持续大于0说明系统已经在频繁使用交换区必须立即处理。处理方式首先用top或ps找出内存消耗最大的进程考虑重启或优化其次考虑扩容物理内存。老师傅技巧使用vmstat 1观察si和so列。如果它们持续为0说明内存充足。任何非零的持续活动都值得深入调查。对于Java应用还要关注top中进程的RES(常驻内存) 和%MEM。5. 第三项磁盘空间与Inode使用率——最经典的“服务中断”诱因“No space left on device” 是运维最常见的报错之一。但除了空间Inode用尽同样会导致无法创建文件且更容易被忽视。5.1 核心概念与命令磁盘空间文件实际占用的存储块。Inode索引节点存储文件的元信息权限、所有者、时间戳、数据块位置等。每个文件或目录都消耗一个Inode。磁盘空间有剩余但Inode用尽也无法创建新文件。常用命令# 查看磁盘空间使用情况人类可读格式 df -h # 查看Inode使用情况 df -i # 查看指定目录下各子目录/文件的大小 du -sh /var/log/* # 查看/var/log下各个项的大小 du -sh /home/* 2/dev/null | sort -hr | head -10 # 找出/home下最大的10个目录 # 查找大文件例如大于100M find / -type f -size 100M 2/dev/null | head -205.2 实战解读与阈值判断运行df -h和df -i# df -h 输出 Filesystem Size Used Avail Use% Mounted on /dev/vda1 50G 35G 12G 75% / /dev/vdb1 200G 50G 141G 26% /data # df -i 输出 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vda1 3.2M 450K 2.8M 14% / /dev/vdb1 12M 105K 12M 1% /data解读与行动指南空间使用率根分区/使用了75%。建议设置告警阈值为80%紧急阈值为90%。超过80%就需要清理超过90%有服务中断风险。Inode使用率根分区/的Inode使用了14%很健康。Inode告警阈值建议为85%。如果IUse%接近100%即使df -h显示还有空间也会无法创建文件。定位罪魁祸首如果/空间告急通常检查/var/log/日志、/tmp/临时文件、/var/cache/缓存。使用du和find命令定位具体的大文件或目录。常见清理操作谨慎# 清理旧的日志文件示例保留最近7天 find /var/log -name *.log -type f -mtime 7 -delete # 清理yum/dnf缓存 yum clean all # CentOS/RHEL dnf clean all # Fedora/Rocky Linux 8 apt-get clean # Debian/Ubuntu # 清理Docker无用资源 docker system prune -f老师傅技巧对于/var/log目录强烈建议配置日志轮转logrotate而不是手动删除。对于生产环境将日志、数据等频繁写入的目录挂载到独立的大容量分区如示例中的/data是避免根分区被撑爆的最佳实践。6. 第四项关键进程与服务状态——业务的“心跳”资源正常但业务进程挂了一切归零。检查关键进程和服务是巡检的重中之重。6.1 核心概念与命令进程系统中正在运行的程序实例。服务由系统服务管理器如systemd管理的常驻后台进程。端口网络服务的访问入口。常用命令# 1. 检查特定进程是否存在 ps aux | grep -v grep | grep -E (nginx|mysql|java) # 查找nginx, mysql或java进程 # 2. 使用systemctl检查服务状态现代Linux发行版通用 systemctl status nginx.service # 查看nginx服务的详细状态 systemctl is-active nginx.service # 仅返回状态active/inactive systemctl is-enabled nginx.service # 检查是否开机自启 # 3. 检查服务监听的端口 ss -tlnp | grep :80 # 查看谁在监听80端口 netstat -tlnp | grep :3306 # 查看谁在监听3306端口MySQL # 4. 检查进程数量是否异常例如检查Java进程数 ps -ef | grep -c [j]ava # 统计Java进程数[j]是grep技巧避免统计到grep自身6.2 实战解读与行动指南场景一检查Nginx Web服务systemctl status nginx期望输出Active: active (running) since ...。这表示服务正在运行。异常情况Active: inactive (dead)服务未运行。使用systemctl start nginx启动并systemctl enable nginx设置开机自启。Active: failed服务启动失败。使用journalctl -u nginx -xe查看详细的失败日志。场景二检查MySQL是否监听端口ss -tlnp | grep :3306期望输出LISTEN 0 128 *:3306 *:* users:((mysqld,pid1234,fd21))。这表示3306端口已被mysqld进程监听。无输出表示MySQL未监听端口服务可能未启动或配置错误。场景三检查进程资源占用是否异常结合top或ps aux查看关键进程的%CPU、%MEM、PID。如果某个业务进程CPU或内存占用异常高例如持续99%可能发生了死循环或内存泄漏。老师傅技巧不要只检查进程是否存在还要检查其子进程或线程数是否爆炸。例如一个PHP-FPM进程池如果子进程数异常增长可能配置有误或存在请求堆积。使用pstree -p PID或ps -Lf PID查看。7. 第五项系统日志与安全审计——发现问题的“显微镜”日志是系统运行的“黑匣子”很多潜在问题和安全事件都会在这里留下痕迹。日常巡检必须快速浏览关键日志。7.1 核心日志文件与命令系统核心日志/var/log/messages(CentOS/RHEL) 或/var/log/syslog(Ubuntu/Debian)。记录内核和系统级通用消息。认证与安全日志/var/log/secure(CentOS/RHEL) 或/var/log/auth.log(Ubuntu/Debian)。记录登录、认证相关事件是排查暴力破解的关键。服务特定日志如/var/log/nginx/access.log/var/log/mysql/error.log等。系统日志统一查看工具journalctl(systemd系统)。常用命令# 1. 查看最近系统日志中的错误或警告tail grep是黄金组合 tail -100 /var/log/messages | grep -E -i (error|warn|fail|critical) tail -50 /var/log/secure | grep -i failed # 查看失败的登录尝试 # 2. 使用journalctl查看指定时间、服务、优先级的日志 journalctl --since 1 hour ago -p err # 查看过去1小时的所有错误日志 journalctl -u nginx.service --since today # 查看今天nginx服务的所有日志 # 3. 检查最近成功登录的用户 last -n 10 # 查看最近10次登录记录 who # 查看当前登录的用户 # 4. 检查异常登录尝试统计失败登录 grep Failed password /var/log/secure | awk {print $11} | sort | uniq -c | sort -nr | head -10 # 这条命令会统计来自哪些IP的失败登录尝试最多7.2 实战解读与行动指南巡检动作快速错误筛查每天巡检时运行tail -100 /var/log/messages | grep -E -i \(error|warn)\。如果输出为空或只有几条无关紧要的警告则通常正常。如果出现大量重复错误就需要根据错误信息深入排查。关注安全日志重点查看/var/log/secure中是否有大量的Failed password for root from ...。这是服务器被暴力破解的明显迹象。如果发现应立即用last命令确认是否有异常IP成功登录。考虑修改SSH端口、禁用root密码登录、配置防火墙如fail2ban封禁攻击IP。检查服务日志根据服务器上运行的服务查看其对应的错误日志。例如MySQL的error.log里可能有慢查询警告Nginx的error.log里可能有连接数达到限制的报错。老师傅技巧将重要的日志监控自动化。例如使用logwatch工具每天发送日志摘要邮件或使用Prometheus的node_exporter收集日志错误计数作为监控指标。对于安全日志配置实时告警当同一IP在短时间内失败登录次数超过阈值时立即通知。8. 自动化巡检脚本实战手动执行上述命令对于少量服务器可行但对于成规模的服务器集群必须借助自动化。这里提供一个基础的Shell脚本示例它将五项检查的结果输出到一个清晰的报告中。脚本文件server_daily_check.sh#!/bin/bash # 服务器日常巡检脚本 # 作者运维老司机 # 功能检查系统负载、内存、磁盘、进程、日志关键信息 REPORT_FILE/tmp/server_health_report_$(date %Y%m%d_%H%M%S).txt echo 服务器日常巡检报告 $REPORT_FILE echo 检查时间$(date) $REPORT_FILE echo 主机名$(hostname) $REPORT_FILE echo IP地址$(hostname -I | awk {print $1}) $REPORT_FILE echo $REPORT_FILE echo -e \n[1] 系统负载与CPU信息 $REPORT_FILE echo ---------------------------------------- $REPORT_FILE uptime $REPORT_FILE echo $REPORT_FILE echo CPU核心数$(grep -c processor /proc/cpuinfo) $REPORT_FILE top -bn1 | grep %Cpu(s) $REPORT_FILE echo -e \n[2] 内存与Swap使用情况 $REPORT_FILE echo ---------------------------------------- $REPORT_FILE free -h $REPORT_FILE echo $REPORT_FILE echo Swap使用详情 $REPORT_FILE vmstat 1 3 | tail -n 1 | awk {printf \si: %s so: %s\\n\, $7, $8} $REPORT_FILE echo -e \n[3] 磁盘空间与Inode使用情况 $REPORT_FILE echo ---------------------------------------- $REPORT_FILE echo 磁盘空间 $REPORT_FILE df -h | grep -v tmpfs $REPORT_FILE echo $REPORT_FILE echo Inode使用 $REPORT_FILE df -i | grep -v tmpfs $REPORT_FILE echo -e \n[4] 关键进程与服务状态 $REPORT_FILE echo ---------------------------------------- $REPORT_FILE # 检查常见服务请根据实际情况修改 SERVICES(nginx mysql docker sshd) for svc in ${SERVICES[]}; do if systemctl is-active --quiet $svc 2/dev/null; then status✅ 运行中 else status❌ 未运行 fi echo $svc: $status $REPORT_FILE done echo $REPORT_FILE echo 监听端口检查80, 443, 3306, 22 $REPORT_FILE for port in 80 443 3306 22; do if ss -tln | grep -q :$port ; then echo 端口 $port: ✅ 已被监听 $REPORT_FILE else echo 端口 $port: ⚠️ 未监听 $REPORT_FILE fi done echo -e \n[5] 系统日志关键错误最近20条 $REPORT_FILE echo ---------------------------------------- $REPORT_FILE LOG_FILE/var/log/messages if [ -f $LOG_FILE ]; then grep -E -i (error|warn|fail|critical) $LOG_FILE | tail -20 $REPORT_FILE 2/dev/null || echo 未找到相关错误信息。 $REPORT_FILE else echo 日志文件 $LOG_FILE 不存在尝试查看journalctl。 $REPORT_FILE journalctl --since 1 hour ago -p err 2/dev/null | tail -10 $REPORT_FILE || echo 无法获取日志。 $REPORT_FILE fi echo -e \n[6] 最近登录记录最近5次 $REPORT_FILE echo ---------------------------------------- $REPORT_FILE last -n 5 $REPORT_FILE 2/dev/null echo -e \n 巡检结束 $REPORT_FILE echo 巡检报告已生成$REPORT_FILE cat $REPORT_FILE使用与定制将脚本保存到服务器例如/usr/local/bin/server_daily_check.sh。赋予执行权限chmod x /usr/local/bin/server_daily_check.sh。直接运行sudo /usr/local/bin/server_daily_check.sh。报告会输出到屏幕并保存到/tmp目录下的一个文件。关键定制点修改SERVICES数组加入你需要检查的服务名。修改for port in 80 443 3306 22中的端口列表改为你业务实际使用的端口。可以将此脚本加入crontab实现定时巡检并发送邮件。对于多台服务器可以使用Ansible批量执行此脚本并收集所有报告。9. 常见问题与排查思路在巡检过程中你可能会遇到一些典型问题。下表汇总了常见现象、可能原因和排查方向问题现象可能原因排查思路与解决方案负载高但CPU空闲id高I/O等待wa高、大量进程处于不可中断睡眠D状态1. 使用iostat -x 1查看磁盘利用率 (%util) 和响应时间 (await)。2. 使用top查看wa值和D状态进程。3. 检查是否磁盘故障、RAID重建、或某个进程正在疯狂写日志/数据。内存available极低Swap使用增长物理内存不足应用程序存在内存泄漏1. 使用top或ps aux --sort-%mem找出内存消耗最大的进程。2. 对Java应用使用jstat -gc pid观察GC情况。3. 考虑重启问题进程优化应用代码或扩容内存。磁盘空间使用率快速增长日志未轮转、大文件未清理、程序异常写数据1. 使用du和find定位增长最快的目录或文件。2. 检查相关服务的日志配置如logrotate。3. 检查是否有爬虫、备份脚本在异常生成数据。服务进程突然消失进程崩溃、被OOM Killer杀死、系统资源耗尽1. 检查系统日志/var/log/messages或journalctl中是否有Out of memory或进程崩溃的堆栈信息。2. 检查 dmesgSSH登录缓慢或失败DNS解析问题、sshd配置问题、防火墙限制、认证日志过多1. 在服务端和客户端使用ssh -vvv查看详细连接过程。2. 检查/etc/ssh/sshd_config配置。3. 检查/var/log/secure是否有大量失败尝试导致sshd处理缓慢。df -h和du -sh统计不一致文件已被删除但进程仍持有句柄空间未释放1. 使用lsof | grep deleted查找已被删除但仍被进程打开的大文件。2. 重启持有该文件句柄的进程以释放空间。10. 最佳实践与工程建议将日常巡检从被动变为主动从手动变为自动是运维成熟度的重要标志。以下是一些提升巡检效率和效果的最佳实践建立基线关注变化在系统健康时记录各项指标的“正常”范围如CPU平均负载、内存可用量、磁盘使用率。巡检时关注的是偏离基线的变化趋势而不仅仅是绝对值。自动化与定时化使用cron定时执行巡检脚本并将报告发送到邮箱或协同办公工具如钉钉、企业微信机器人。使用配置管理工具如Ansible编写巡检剧本实现批量服务器的并行检查与结果汇总。监控告警前置对于核心指标如磁盘使用率85%、内存可用10%、服务端口down不应依赖每日巡检才发现。必须搭建监控系统如Zabbix, Prometheus Alertmanager设置实时告警做到分钟级发现。巡检清单制度化为不同角色系统运维、应用运维、DBA制定侧重点不同的巡检清单。并将巡检结果记录到工单或Wiki中形成历史档案便于追溯和复盘。安全巡检不可忽视除了性能每周应进行一次专项安全巡检包括检查系统漏洞yum check-update、检查非常用端口开放情况netstat -tlnp、分析入侵检测日志、核查用户和权限变更。容量规划日常巡检的数据是容量规划的最佳输入。定期分析磁盘增长趋势、内存使用趋势预测资源何时会耗尽提前发起扩容流程。服务器日常巡检是运维工作的基石它考验的不是对复杂命令的掌握而是对系统运行状态的整体把握能力和风险预见性。从今天起不要再漫无目的地敲命令抓住负载、内存、磁盘、进程、日志这五项核心建立你自己的巡检流程和自动化脚本。当你能够通过十分钟的检查对服务器的健康状况了然于胸并能从细微的数据波动中预判潜在风险时你就真正拥有了一个“老师傅”的洞察力。记住最好的运维是让问题不发生而有效的巡检正是通往这一目标的第一步。 服务器日常巡检实战指南：黄金五项与自动化脚本
在服务器运维的日常工作中你是否曾面对几十甚至上百台服务器感到无从下手是否担心某个深夜因为一个未被察觉的磁盘满或内存泄漏导致服务中断服务器巡检这个看似基础却至关重要的环节往往是区分新手运维和资深“老师傅”的关键。很多运维同学知道要巡检但巡检什么、怎么高效地检、检出了问题如何快速定位却缺乏一套系统的方法。本文将为你拆解一套经过实战检验的服务器日常巡检核心框架。我们不追求大而全的检查清单而是聚焦于那些真正能提前发现隐患、保障服务稳定的“黄金五项”。无论你是管理单台测试机还是维护一个庞大的服务器集群掌握这五项核心检查都能让你对服务器健康状况了如指掌将问题扼杀在摇篮之中。1. 巡检的核心价值与“黄金五项”概述在深入命令之前我们首先要明确服务器巡检不是为了应付任务而是为了主动发现风险、保障业务连续性、积累系统基线数据。一次有效的巡检应该能回答以下几个问题系统资源是否充足且使用合理关键服务是否在正常运行系统是否存在安全或性能隐患历史运行趋势是否健康基于这些目标并结合大量线上故障的复盘经验我们提炼出运维“老师傅”们必定优先关注的五项核心检查它们构成了服务器健康度的第一道防线系统负载与CPU使用率反映系统整体繁忙程度和计算资源压力。内存使用与交换空间揭示内存是否充足是否存在泄漏或过度使用交换区导致性能骤降。磁盘空间与Inode使用率预防因日志暴涨、临时文件堆积导致的“磁盘写满”经典故障。关键进程与服务状态确保业务核心进程存活监听端口正常。系统日志与安全审计从系统日志中捕捉错误、警告信息并检查异常登录记录。接下来我们将逐一深入这五项检查不仅告诉你“看什么”更详细解释“为什么看”以及“怎么看懂数据背后的故事”。2. 环境与工具准备在进行巡检前确保你有一个可用的Linux服务器环境并拥有适当的权限通常需要root或具有sudo权限的账户。本文演示基于CentOS 7 / Rocky Linux 8或Ubuntu 20.04/22.04等主流发行版大部分命令具有通用性。基础工具这些工具通常系统自带无需额外安装。ssh用于远程连接服务器。top/htop实时进程查看器。free/vmstat内存查看工具。df/du磁盘空间查看工具。ps/systemctl进程与服务管理工具。journalctl/tail日志查看工具。netstat/ss网络连接与端口查看工具。last/who用户登录信息查看工具。可选效率工具对于需要管理多台服务器的场景可以考虑Shell脚本将检查命令自动化。Ansible实现批量服务器的并行巡检与结果收集。Prometheus Grafana搭建长期监控与可视化告警平台这是巡检的自动化与可视化进阶。我们首先从单机手动检查开始这是理解原理的基础。3. 第一项系统负载与CPU使用率——系统繁忙度的“体温计”系统负载Load Average和CPU使用率是判断服务器当前压力最直观的指标。很多人只看CPU使用率其实负载平均值更能反映系统的“拥堵”情况。3.1 核心概念与命令负载平均值Load Averageuptime或top命令输出中load average: 0.01, 0.05, 0.15这样的数字。它表示系统在最近1分钟、5分钟、15分钟内的平均活跃进程数处于可运行状态或不可中断睡眠状态的进程。对于单核CPU负载为1.0表示CPU刚好满负荷对于4核CPU负载为4.0表示所有核心满负荷。CPU使用率top命令中%Cpu(s)行重点关注us用户空间程序占用CPU百分比。sy内核空间占用CPU百分比。id空闲CPU百分比。wa等待I/O如磁盘读写的CPU百分比。高wa通常意味着磁盘可能存在瓶颈。常用命令# 查看负载平均值和系统运行时间 uptime # 动态查看进程和CPU、内存使用情况按q退出 top # 更友好、彩色的top替代品可能需要安装yum install htop / apt install htop htop # 查看每个CPU核心的详细使用情况 mpstat -P ALL 1 # 每秒刷新一次显示所有CPU核心状态3.2 实战解读与阈值判断运行top命令后我们看第一部分top - 14:30:00 up 30 days, 3:15, 1 user, load average: 1.25, 0.80, 0.50 Tasks: 125 total, 1 running, 124 sleeping, 0 stopped, 0 zombie %Cpu(s): 5.6 us, 2.1 sy, 0.0 ni, 92.0 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st解读与行动指南负载load average: 1.25, 0.80, 0.50这是一台4核CPU的服务器。1分钟负载是1.25小于CPU核数4说明当前压力不大。关键看趋势如果1分钟值远高于5分钟和15分钟值例如3.50, 1.20, 0.80说明系统压力正在快速上升需要立即关注。如果15分钟值持续高于CPU核数例如5.10, 5.05, 5.00说明系统长期过载必须扩容或优化。CPU使用率92.0 id空闲率高达92%CPU非常空闲。警报场景如果id低于20%并且us或sy很高说明计算资源紧张。如果wa超过5%甚至更高强烈提示磁盘I/O可能存在瓶颈需要结合下一节的磁盘检查。老师傅技巧单独的高CPU使用率不一定有问题可能是正常业务处理。需要结合负载看高负载 高CPU使用率 真繁忙高负载 低CPU使用率 可能卡在I/O或锁等待。4. 第二项内存使用与交换空间——性能的“隐形杀手”内存不足会触发系统使用交换分区Swap而Swap的读写速度远低于物理内存一旦频繁使用系统性能会断崖式下跌。4.1 核心概念与命令物理内存服务器的实际RAM。缓冲Buffer与缓存Cachefree命令中buff/cache。这是Linux内核为了提高磁盘I/O性能而占用的内存。这部分内存在应用程序需要时可以被快速回收因此通常不被视为“已用”内存。这是新手最容易误解的地方。交换空间Swap当物理内存不足时将不活跃的内存页写入磁盘交换区。Swap使用是内存不足的最后防线但也是性能的坟墓。常用命令# 查看内存和Swap使用情况传统显示易误解 free -m # 推荐以更易懂的方式查看内存CentOS 7 / Ubuntu 16.04 free -h # 查看更详细的内存统计信息 cat /proc/meminfo # 查看虚拟内存统计包括Swap in/outsi/so这是关键 vmstat 1 5 # 每秒采样一次共5次4.2 实战解读与阈值判断运行free -htotal used free shared buff/cache available Mem: 7.6G 2.1G 3.2G 345M 2.3G 4.9G Swap: 2.0G 0B 2.0G解读与行动指南关键看available4.9G表示系统估算的、可供启动新应用程序而无需交换的内存大小。这是判断内存是否充足的黄金指标。如果available长期低于总内存的20%本例中低于1.5G就需要警惕。不要被used吓到used(2.1G) 包含了buff/cache(2.3G)。实际上应用程序直接使用的内存可能很少。真正已用的、难以回收的内存 ≈used - buff/cache。Swap是终极警报本例中Swap使用为0B这是健康的。一旦Swap下的used开始增长尤其是配合vmstat看到si(swap in) 和so(swap out) 持续大于0说明系统已经在频繁使用交换区必须立即处理。处理方式首先用top或ps找出内存消耗最大的进程考虑重启或优化其次考虑扩容物理内存。老师傅技巧使用vmstat 1观察si和so列。如果它们持续为0说明内存充足。任何非零的持续活动都值得深入调查。对于Java应用还要关注top中进程的RES(常驻内存) 和%MEM。5. 第三项磁盘空间与Inode使用率——最经典的“服务中断”诱因“No space left on device” 是运维最常见的报错之一。但除了空间Inode用尽同样会导致无法创建文件且更容易被忽视。5.1 核心概念与命令磁盘空间文件实际占用的存储块。Inode索引节点存储文件的元信息权限、所有者、时间戳、数据块位置等。每个文件或目录都消耗一个Inode。磁盘空间有剩余但Inode用尽也无法创建新文件。常用命令# 查看磁盘空间使用情况人类可读格式 df -h # 查看Inode使用情况 df -i # 查看指定目录下各子目录/文件的大小 du -sh /var/log/* # 查看/var/log下各个项的大小 du -sh /home/* 2/dev/null | sort -hr | head -10 # 找出/home下最大的10个目录 # 查找大文件例如大于100M find / -type f -size 100M 2/dev/null | head -205.2 实战解读与阈值判断运行df -h和df -i# df -h 输出 Filesystem Size Used Avail Use% Mounted on /dev/vda1 50G 35G 12G 75% / /dev/vdb1 200G 50G 141G 26% /data # df -i 输出 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vda1 3.2M 450K 2.8M 14% / /dev/vdb1 12M 105K 12M 1% /data解读与行动指南空间使用率根分区/使用了75%。建议设置告警阈值为80%紧急阈值为90%。超过80%就需要清理超过90%有服务中断风险。Inode使用率根分区/的Inode使用了14%很健康。Inode告警阈值建议为85%。如果IUse%接近100%即使df -h显示还有空间也会无法创建文件。定位罪魁祸首如果/空间告急通常检查/var/log/日志、/tmp/临时文件、/var/cache/缓存。使用du和find命令定位具体的大文件或目录。常见清理操作谨慎# 清理旧的日志文件示例保留最近7天 find /var/log -name *.log -type f -mtime 7 -delete # 清理yum/dnf缓存 yum clean all # CentOS/RHEL dnf clean all # Fedora/Rocky Linux 8 apt-get clean # Debian/Ubuntu # 清理Docker无用资源 docker system prune -f老师傅技巧对于/var/log目录强烈建议配置日志轮转logrotate而不是手动删除。对于生产环境将日志、数据等频繁写入的目录挂载到独立的大容量分区如示例中的/data是避免根分区被撑爆的最佳实践。6. 第四项关键进程与服务状态——业务的“心跳”资源正常但业务进程挂了一切归零。检查关键进程和服务是巡检的重中之重。6.1 核心概念与命令进程系统中正在运行的程序实例。服务由系统服务管理器如systemd管理的常驻后台进程。端口网络服务的访问入口。常用命令# 1. 检查特定进程是否存在 ps aux | grep -v grep | grep -E (nginx|mysql|java) # 查找nginx, mysql或java进程 # 2. 使用systemctl检查服务状态现代Linux发行版通用 systemctl status nginx.service # 查看nginx服务的详细状态 systemctl is-active nginx.service # 仅返回状态active/inactive systemctl is-enabled nginx.service # 检查是否开机自启 # 3. 检查服务监听的端口 ss -tlnp | grep :80 # 查看谁在监听80端口 netstat -tlnp | grep :3306 # 查看谁在监听3306端口MySQL # 4. 检查进程数量是否异常例如检查Java进程数 ps -ef | grep -c [j]ava # 统计Java进程数[j]是grep技巧避免统计到grep自身6.2 实战解读与行动指南场景一检查Nginx Web服务systemctl status nginx期望输出Active: active (running) since ...。这表示服务正在运行。异常情况Active: inactive (dead)服务未运行。使用systemctl start nginx启动并systemctl enable nginx设置开机自启。Active: failed服务启动失败。使用journalctl -u nginx -xe查看详细的失败日志。场景二检查MySQL是否监听端口ss -tlnp | grep :3306期望输出LISTEN 0 128 *:3306 *:* users:((mysqld,pid1234,fd21))。这表示3306端口已被mysqld进程监听。无输出表示MySQL未监听端口服务可能未启动或配置错误。场景三检查进程资源占用是否异常结合top或ps aux查看关键进程的%CPU、%MEM、PID。如果某个业务进程CPU或内存占用异常高例如持续99%可能发生了死循环或内存泄漏。老师傅技巧不要只检查进程是否存在还要检查其子进程或线程数是否爆炸。例如一个PHP-FPM进程池如果子进程数异常增长可能配置有误或存在请求堆积。使用pstree -p PID或ps -Lf PID查看。7. 第五项系统日志与安全审计——发现问题的“显微镜”日志是系统运行的“黑匣子”很多潜在问题和安全事件都会在这里留下痕迹。日常巡检必须快速浏览关键日志。7.1 核心日志文件与命令系统核心日志/var/log/messages(CentOS/RHEL) 或/var/log/syslog(Ubuntu/Debian)。记录内核和系统级通用消息。认证与安全日志/var/log/secure(CentOS/RHEL) 或/var/log/auth.log(Ubuntu/Debian)。记录登录、认证相关事件是排查暴力破解的关键。服务特定日志如/var/log/nginx/access.log/var/log/mysql/error.log等。系统日志统一查看工具journalctl(systemd系统)。常用命令# 1. 查看最近系统日志中的错误或警告tail grep是黄金组合 tail -100 /var/log/messages | grep -E -i (error|warn|fail|critical) tail -50 /var/log/secure | grep -i failed # 查看失败的登录尝试 # 2. 使用journalctl查看指定时间、服务、优先级的日志 journalctl --since 1 hour ago -p err # 查看过去1小时的所有错误日志 journalctl -u nginx.service --since today # 查看今天nginx服务的所有日志 # 3. 检查最近成功登录的用户 last -n 10 # 查看最近10次登录记录 who # 查看当前登录的用户 # 4. 检查异常登录尝试统计失败登录 grep Failed password /var/log/secure | awk {print $11} | sort | uniq -c | sort -nr | head -10 # 这条命令会统计来自哪些IP的失败登录尝试最多7.2 实战解读与行动指南巡检动作快速错误筛查每天巡检时运行tail -100 /var/log/messages | grep -E -i \(error|warn)\。如果输出为空或只有几条无关紧要的警告则通常正常。如果出现大量重复错误就需要根据错误信息深入排查。关注安全日志重点查看/var/log/secure中是否有大量的Failed password for root from ...。这是服务器被暴力破解的明显迹象。如果发现应立即用last命令确认是否有异常IP成功登录。考虑修改SSH端口、禁用root密码登录、配置防火墙如fail2ban封禁攻击IP。检查服务日志根据服务器上运行的服务查看其对应的错误日志。例如MySQL的error.log里可能有慢查询警告Nginx的error.log里可能有连接数达到限制的报错。老师傅技巧将重要的日志监控自动化。例如使用logwatch工具每天发送日志摘要邮件或使用Prometheus的node_exporter收集日志错误计数作为监控指标。对于安全日志配置实时告警当同一IP在短时间内失败登录次数超过阈值时立即通知。8. 自动化巡检脚本实战手动执行上述命令对于少量服务器可行但对于成规模的服务器集群必须借助自动化。这里提供一个基础的Shell脚本示例它将五项检查的结果输出到一个清晰的报告中。脚本文件server_daily_check.sh#!/bin/bash # 服务器日常巡检脚本 # 作者运维老司机 # 功能检查系统负载、内存、磁盘、进程、日志关键信息 REPORT_FILE/tmp/server_health_report_$(date %Y%m%d_%H%M%S).txt echo 服务器日常巡检报告 $REPORT_FILE echo 检查时间$(date) $REPORT_FILE echo 主机名$(hostname) $REPORT_FILE echo IP地址$(hostname -I | awk {print $1}) $REPORT_FILE echo $REPORT_FILE echo -e \n[1] 系统负载与CPU信息 $REPORT_FILE echo ---------------------------------------- $REPORT_FILE uptime $REPORT_FILE echo $REPORT_FILE echo CPU核心数$(grep -c processor /proc/cpuinfo) $REPORT_FILE top -bn1 | grep %Cpu(s) $REPORT_FILE echo -e \n[2] 内存与Swap使用情况 $REPORT_FILE echo ---------------------------------------- $REPORT_FILE free -h $REPORT_FILE echo $REPORT_FILE echo Swap使用详情 $REPORT_FILE vmstat 1 3 | tail -n 1 | awk {printf \si: %s so: %s\\n\, $7, $8} $REPORT_FILE echo -e \n[3] 磁盘空间与Inode使用情况 $REPORT_FILE echo ---------------------------------------- $REPORT_FILE echo 磁盘空间 $REPORT_FILE df -h | grep -v tmpfs $REPORT_FILE echo $REPORT_FILE echo Inode使用 $REPORT_FILE df -i | grep -v tmpfs $REPORT_FILE echo -e \n[4] 关键进程与服务状态 $REPORT_FILE echo ---------------------------------------- $REPORT_FILE # 检查常见服务请根据实际情况修改 SERVICES(nginx mysql docker sshd) for svc in ${SERVICES[]}; do if systemctl is-active --quiet $svc 2/dev/null; then status✅ 运行中 else status❌ 未运行 fi echo $svc: $status $REPORT_FILE done echo $REPORT_FILE echo 监听端口检查80, 443, 3306, 22 $REPORT_FILE for port in 80 443 3306 22; do if ss -tln | grep -q :$port ; then echo 端口 $port: ✅ 已被监听 $REPORT_FILE else echo 端口 $port: ⚠️ 未监听 $REPORT_FILE fi done echo -e \n[5] 系统日志关键错误最近20条 $REPORT_FILE echo ---------------------------------------- $REPORT_FILE LOG_FILE/var/log/messages if [ -f $LOG_FILE ]; then grep -E -i (error|warn|fail|critical) $LOG_FILE | tail -20 $REPORT_FILE 2/dev/null || echo 未找到相关错误信息。 $REPORT_FILE else echo 日志文件 $LOG_FILE 不存在尝试查看journalctl。 $REPORT_FILE journalctl --since 1 hour ago -p err 2/dev/null | tail -10 $REPORT_FILE || echo 无法获取日志。 $REPORT_FILE fi echo -e \n[6] 最近登录记录最近5次 $REPORT_FILE echo ---------------------------------------- $REPORT_FILE last -n 5 $REPORT_FILE 2/dev/null echo -e \n 巡检结束 $REPORT_FILE echo 巡检报告已生成$REPORT_FILE cat $REPORT_FILE使用与定制将脚本保存到服务器例如/usr/local/bin/server_daily_check.sh。赋予执行权限chmod x /usr/local/bin/server_daily_check.sh。直接运行sudo /usr/local/bin/server_daily_check.sh。报告会输出到屏幕并保存到/tmp目录下的一个文件。关键定制点修改SERVICES数组加入你需要检查的服务名。修改for port in 80 443 3306 22中的端口列表改为你业务实际使用的端口。可以将此脚本加入crontab实现定时巡检并发送邮件。对于多台服务器可以使用Ansible批量执行此脚本并收集所有报告。9. 常见问题与排查思路在巡检过程中你可能会遇到一些典型问题。下表汇总了常见现象、可能原因和排查方向问题现象可能原因排查思路与解决方案负载高但CPU空闲id高I/O等待wa高、大量进程处于不可中断睡眠D状态1. 使用iostat -x 1查看磁盘利用率 (%util) 和响应时间 (await)。2. 使用top查看wa值和D状态进程。3. 检查是否磁盘故障、RAID重建、或某个进程正在疯狂写日志/数据。内存available极低Swap使用增长物理内存不足应用程序存在内存泄漏1. 使用top或ps aux --sort-%mem找出内存消耗最大的进程。2. 对Java应用使用jstat -gc pid观察GC情况。3. 考虑重启问题进程优化应用代码或扩容内存。磁盘空间使用率快速增长日志未轮转、大文件未清理、程序异常写数据1. 使用du和find定位增长最快的目录或文件。2. 检查相关服务的日志配置如logrotate。3. 检查是否有爬虫、备份脚本在异常生成数据。服务进程突然消失进程崩溃、被OOM Killer杀死、系统资源耗尽1. 检查系统日志/var/log/messages或journalctl中是否有Out of memory或进程崩溃的堆栈信息。2. 检查 dmesgSSH登录缓慢或失败DNS解析问题、sshd配置问题、防火墙限制、认证日志过多1. 在服务端和客户端使用ssh -vvv查看详细连接过程。2. 检查/etc/ssh/sshd_config配置。3. 检查/var/log/secure是否有大量失败尝试导致sshd处理缓慢。df -h和du -sh统计不一致文件已被删除但进程仍持有句柄空间未释放1. 使用lsof | grep deleted查找已被删除但仍被进程打开的大文件。2. 重启持有该文件句柄的进程以释放空间。10. 最佳实践与工程建议将日常巡检从被动变为主动从手动变为自动是运维成熟度的重要标志。以下是一些提升巡检效率和效果的最佳实践建立基线关注变化在系统健康时记录各项指标的“正常”范围如CPU平均负载、内存可用量、磁盘使用率。巡检时关注的是偏离基线的变化趋势而不仅仅是绝对值。自动化与定时化使用cron定时执行巡检脚本并将报告发送到邮箱或协同办公工具如钉钉、企业微信机器人。使用配置管理工具如Ansible编写巡检剧本实现批量服务器的并行检查与结果汇总。监控告警前置对于核心指标如磁盘使用率85%、内存可用10%、服务端口down不应依赖每日巡检才发现。必须搭建监控系统如Zabbix, Prometheus Alertmanager设置实时告警做到分钟级发现。巡检清单制度化为不同角色系统运维、应用运维、DBA制定侧重点不同的巡检清单。并将巡检结果记录到工单或Wiki中形成历史档案便于追溯和复盘。安全巡检不可忽视除了性能每周应进行一次专项安全巡检包括检查系统漏洞yum check-update、检查非常用端口开放情况netstat -tlnp、分析入侵检测日志、核查用户和权限变更。容量规划日常巡检的数据是容量规划的最佳输入。定期分析磁盘增长趋势、内存使用趋势预测资源何时会耗尽提前发起扩容流程。服务器日常巡检是运维工作的基石它考验的不是对复杂命令的掌握而是对系统运行状态的整体把握能力和风险预见性。从今天起不要再漫无目的地敲命令抓住负载、内存、磁盘、进程、日志这五项核心建立你自己的巡检流程和自动化脚本。当你能够通过十分钟的检查对服务器的健康状况了然于胸并能从细微的数据波动中预判潜在风险时你就真正拥有了一个“老师傅”的洞察力。记住最好的运维是让问题不发生而有效的巡检正是通往这一目标的第一步。