Linux Shell自动化巡检脚本的核心目标是用最小资源开销稳定采集关键系统状态并明确提示异常，聚焦资源水位、服务状态、基础健康、安全基线四类高频问题域，采用分层输出与健壮性设计，支持定时巡检和上线前快检。
Linux Shell 自动化巡检脚本的核心目标是：用最小的资源开销，稳定、可重复地采集关键系统状态，并对异常给出明确提示。不追求功能大而全，而要聚焦“该看的不漏、异常的能报、误报的尽量少”。
明确巡检范围与判定标准
盲目检查所有指标反而降低有效性。应优先覆盖以下四类高频问题域：
- 资源水位：CPU 使用率（>90% 持续5分钟）、内存剩余95%、inode 使用率>95%
- 服务状态：关键进程是否存在（如 nginx、sshd）、端口是否监听（如 :22、:80）、systemd 服务是否 active（非 inactive 或 failed）
-
基础健康：系统日志中近1小时是否有 “OOM killed”、“kernel panic”、“disk error” 等关键词；NTP 是否同步（
timedatectl status | grep "synchronized: yes"） -
安全基线：是否存在空密码用户（
awk -F: '$2=="" {print $1}' /etc/shadow）、root 登录是否仅限密钥（检查/etc/ssh/sshd_config中PermitRootLogin和PasswordAuthentication）
设计分层输出机制
一次巡检结果需适配不同使用场景，建议按三级输出：
- 终端直显：只显示 FAIL 或 WARN 条目，每行含模块名+简要原因（如 [DISK] /dev/sda1 usage 97% > 95%），便于人工快速扫读
-
日志文件：完整记录所有检查项原始命令输出+时间戳，路径统一为
/var/log/check_$(date +\%Y\%m\%d).log，保留最近7天 -
状态标记：脚本末尾写入
/tmp/.last_check_status，内容为 SUCCESS / WARNING / FAILED，供其他脚本或监控系统轮询读取
增强健壮性与可维护性
生产环境脚本必须避免“一错全崩”，关键处理方式包括：
- 每个检查块用子 shell 封装（
(...)），防止变量污染或 cd 失败影响后续逻辑 - 关键命令加超时控制，如
timeout 5 ss -tln | grep ':22' > /dev/null，防端口检测卡死 - 路径和阈值全部提取为变量，顶部集中定义（如
ROOT_WARN=95、LOG_DIR="/var/log"），不硬编码 - 支持传参模式：
./check.sh --dry-run只打印将执行的命令；--module disk,mem指定模块运行，方便调试
集成到日常运维节奏
脚本价值在于被持续使用，推荐两个轻量落地方式：
-
定时巡检：通过 cron 每日凌晨2点执行，结果邮件发送给值班人（用
mail -s "Server Check $(hostname)" admin@example.com ） -
上线前快检：加入部署流程最后一步，返回非0则中断发布（
./check.sh --module disk,service || { echo "Pre-deploy check failed"; exit 1; }）
不复杂但容易忽略的是：每次修改后在测试机上用 bash -n 检查语法，再用 set -u -e 运行一次模拟失败场景（如临时停掉 sshd 观察是否准确报 WARN）。稳定源于细节验证，而非一次性写完。
