Linux 服务健康检查需三重校验：进程状态（systemctl）、端口监听（ss/netstat）、接口响应（curl）；监控 CPU 负载、内存 available、磁盘使用率及 inode、S.M.A.R.T. 状态；日志按时间范围扫描 error/fail/timeout；脚本化实现阈值判断与自动恢复。
Linux 服务健康检查不是只看“有没有在跑”，而是要确认它是否真正可用、响应及时、资源充足、日志干净。自动检测的关键在于“可量化、可触发、可恢复”——指标得有阈值，异常得能发现，问题得能自愈。
基础服务状态与 端口 连通性检查
最直接的判断方式是验证进程是否存在、端口是否监听、服务能否响应请求。
- 用 systemctl is-active servicename 判断服务当前状态（active/inactive/failed）
- 用 ss -tuln | grep : 端口号 或 netstat -tuln | grep : 端口号 确认端口是否被正确监听
- 对 Web 类服务，加一层 HTTP 探活：curl -s -o /dev/null -w “%{http_code}” http://localhost:8080/health，返回 200 才算真健康
- 避免仅依赖 ps 查进程名，因为僵尸进程或假 PID 可能干扰判断；建议结合 systemctl + 端口 + 接口三重校验
资源使用率与系统级指标监控
CPU、内存、磁盘、负载这些底层指标一旦越界，服务大概率会降级甚至崩溃。
- CPU 负载：用 uptime 或 cat /proc/loadavg 获取 1/5/15 分钟平均负载，对比 CPU 核心数（如 4 核服务器，load > 8 就需关注）
- 内存：free -m 看可用内存，重点留意 available 字段（非 free），swap 使用超过 10% 就该预警
- 磁盘：df -h | awk ‘$5 > 90 {print $1,$5}’ 找出使用率超 90% 的分区；同时用 df -i 检查 inode 是否耗尽（常见于日志暴增场景）
- 关键路径磁盘健康：运行 sudo smartctl -H /dev/sda 查 S.M.A.R.T. 状态，预防硬件级故障
日志异常模式自动识别
很多服务“活着”，但日志里已反复报错——这是最隐蔽的亚健康状态。
- 用 journalctl -u nginx –since “1 hour ago” | grep -i “error|fail|timeout” 快速扫描近期错误
- 对长期运行的服务，定期检查错误频率：journalctl -u mysql –since “24 hours ago” | grep “ERROR” | wc -l，单日超 50 条就触发告警
- 匹配典型失败线索，例如 SSH 暴力破解：grep “Failed password” /var/log/auth.log | tail -20；磁盘满提示：grep “No space left” /var/log/syslog
- 避免全量扫描大日志，用 –since 限定时间范围 + tail -n 1000 截取最新片段提升效率
自动化脚本 + 定时执行闭环设计
手动检查不可持续，必须靠脚本固化逻辑，并通过 cron 和恢复动作形成闭环。
- 写一个 shell 脚本，依次执行上述检查项，每项设明确阈值（如磁盘 >90%、HTTP 响应超时 >3s、连续 3 次 curl 失败）
- 检测失败时，不只发邮件，还要执行动作：比如 systemctl restart nginx、清理临时文件 rm -f /tmp/*.log、或压缩旧日志 logrotate -f /etc/logrotate.d/nginx
- 用 crontab -e 添加定时任务，例如每 5 分钟运行一次：*/5 * * * * /opt/scripts/health_check.sh >> /var/log/health.log 2>&1
- 脚本开头加 set -e，确保任一命令失败即终止，避免误判掩盖问题
