【Unity】【游戏开发】unity中快速导入VRM模型并应用动画
2026/8/22 12:29:51
这次我们来看一个非常实际的 Linux 运维问题：服务器日常巡检。很多新手面对一台服务器，感觉千头万绪，不知从何下手。这篇文章不搞长篇大论，直接聚焦老师傅们上机后固定会先检查的 5 个核心项。无论你是管理单台服务器，还是维护一个小型集群，这套方法都能帮你快速建立巡检的“肌肉记忆”，在几分钟内对服务器健康状况有个基本判断。
这 5 项检查，覆盖了系统负载、资源瓶颈、服务状态、安全登录和存储空间，是排查绝大多数线上问题的起点。它们不依赖复杂的监控工具，仅用最基础的 Linux 命令即可完成，非常适合在 SSH 登录后第一时间执行。本文将逐一拆解每项检查的命令、关键指标解读以及异常排查思路，让你看完就能用。
1. 核心能力速览：五分钟快速巡检清单
在深入细节之前，我们先通过一个表格快速了解这 5 项核心巡检内容及其价值。这相当于一份“上机检查单”，帮你建立系统性思维。
| 检查项 | 核心命令/工具 | 关注关键指标 | 主要目的 |
|---|---|---|---|
| 1. 系统负载与进程 | top/htop/uptime | 负载平均值(1,5,15分钟)、CPU使用率、僵尸进程 | 判断系统当前繁忙程度，识别异常高负载进程。 |
| 2. 内存与交换空间 | free -h | 总内存、已用内存、可用内存、交换空间使用率 | 发现内存泄漏或内存不足导致的性能瓶颈。 |
| 3. 磁盘空间与I/O | df -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（空闲）和%wa（I/O等待）。如果%wa很高，说明磁盘I/O可能是瓶颈。 - 第四、五行：
KiB Mem/KiB Swap：看物理内存和交换分区使用情况（下一节细讲）。 - 进程列表：默认按CPU使用率排序。可以按
M键改为按内存排序，按P键切回CPU排序。寻找长期占用资源异常高的进程。
- 第一行：同
更友好的进程查看器：
htop如果系统安装了
htop（yum/apt install htop），它比top更直观，支持颜色、鼠标操作和树状视图，强烈推荐使用。
异常排查思路：
- 负载高但CPU使用率不高：很可能卡在I/O（
%wa高）或锁等待上。结合下一节的iostat和后续的进程状态判断。 - 发现僵尸进程（Z状态）：少量僵尸进程通常无害，父进程结束时会清理。如果大量出现，需要找到其父进程ID（PPID），检查对应程序是否有bug。
- 某个进程CPU/内存异常高：记录下PID和命令名，使用
ps aux | grep <PID>或cat /proc/<PID>/status查看详细信息，判断是否为正常业务进程。
5. 第二项检查：内存与交换空间 (free)
内存不足会直接导致服务卡顿、OOM（Out-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 -i
2. 定位大文件或大目录： 如果某个分区快满了，需要找到“元凶”。
# 查看当前目录下各子目录的大小 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查看%wa；ps 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项检查开始，逐步构建起属于你自己的、体系化的服务器运维监控能力。