linux定时巡检自动化核心是构建“采集—判断—告警—归档”闭环，聚焦cpu负载、内存真实占用率、关键挂载点磁盘空间、核心服务状态及近两小时系统异常五类业务敏感指标，通过分层脚本结构、cron可靠调度与html/json双格式输出，实现可查、可溯、可决策的轻量稳定巡检。
Linux 环境下实现定时巡检自动化，核心不是堆功能，而是让关键指标“看得见、判得准、告得及时、查得回来”。业务保障不靠人盯，而靠稳定执行的闭环机制——从采集到归档，每一步都应轻量、可验证、不干扰生产。
聚焦真正影响业务的巡检项
避免“为巡而巡”，优先覆盖中断即影响服务的维度：
-
CPU 负载：用
uptime取 5 分钟均值，阈值设为1.5 × CPU 核心数；超限需关注是否由某进程持续占用 -
内存真实占用率：基于
/proc/meminfo中的MemAvailable计算，>90% 触发提醒，排除缓存干扰 -
关键挂载点磁盘空间：重点检查
/、/var（日志）、/home（用户数据），df -hP输出中 >95% 标红 -
核心服务存活状态：如
sshd、nginx、mysql，用systemctl is-active --quiet 服务名判断，失败即告警 -
近两小时系统级异常：
journalctl -S "2 hours ago" | grep -i "fail\|error\|oom\|killed"，抓 OOM、进程被杀、认证失败等硬故障信号
脚本结构要便于维护和定位
一个能长期跑下去的巡检脚本，必须分清“配置”“检查”“执行”三层：
- 配置区集中管理：所有阈值、邮件地址、日志路径、保留天数统一写在开头，改一处全生效
-
每个检查封装成函数：如
check_disk()、check_service()，返回 0（正常）或 1（异常），方便单独调试 - 主流程只做调度与汇总：调用各函数，记录时间戳，生成带颜色标识的 HTML 报告（绿色/黄色/红色），同时保存原始命令输出到独立日志供回溯
用 cron 做调度，但不止于“定时执行”
crontab 是基石，但需补足可靠性细节：
- 推荐每日固定时间执行一次深度巡检，例如：
0 6 * * * /opt/scripts/inspect.sh >> /var/log/inspect/cron.log 2>&1 - 脚本末尾加判断逻辑：仅当检测到异常时才发邮件，并附上简明摘要（主机名、异常项、当前值）
- 防重复告警：用
touch /tmp/last_alert_$(date +\%Y\%m\%d)标记当日首次告警，避免同一问题刷屏 - 日志保留策略明确：自动清理
/var/log/inspect/下 30 天前的报告，防止磁盘被日志占满
结果要能直接用于沟通和决策
巡检价值最终体现在“能否快速响应”，而非“有没有执行”：
- 每次生成的 HTML 报告放在
/var/www/html/inspect/，Nginx 配置为只读浏览，运维、开发、测试都能随时打开查看 - 报告含概览卡片（CPU/内存/磁盘状态一目了然）、章节导航、异常项高亮，不依赖额外平台
- 历史报告按日期归档，支持按时间回溯对比，比如发现某次更新后磁盘增长加速，可快速锁定根因
- 若需对接监控体系，脚本可额外输出 JSON 格式，供 Prometheus 或自建平台消费
