Linux Shell监控告警脚本编写实践

在Linux环境下，一个真正能投入生产使用的监控告警脚本，其价值往往不在于语法多么精巧，而在于能否稳定地扛住四类现实干扰：日志轮转、进程重启、网络抖动以及权限变化。这才是脚本能否长期服役的关键。

怎么判断服务是否真的挂了，而不是暂时没响应

单纯依赖ps aux | grep nginx或者curl -I https://localhost:80这类简单检查，很容易掉进误报的陷阱。比如，主进程还在但工作进程已经崩溃，或者HTTP接口返回了502错误码却被脚本判定为“连通”。要避免这种情况，必须采用组合检查策略。

首先，检查进程是否真实存活：使用pgrep -f “nginx: master process”。这比通用的grep命令更精准，能有效避免匹配到日志文件或命令行参数中的相似字符串。

接着，确认服务端口是否在监听：执行ss -tln | grep “:80\b”。注意这里的\b单词边界符，它能防止误匹配到8080这类端口。

最后，进行轻量级的业务层探测：curl -s --connect-timeout 3 -m 5 https://127.0.0.1/health | grep “ok”。这里设置了连接和传输超时，并且验证了响应体内容，确保服务是真正“健康”的。

只有当进程、端口、业务响应这三者全部通过检查时，才能判定服务健康。其中任何一环失败，都应当触发后续的告警逻辑。

告警发出去就完事？得防重复轰炸和静默失效

监控脚本通常由crontab每分钟调度一次，但服务故障的恢复往往需要几十分钟。如果脚本每次检测到故障都发送告警，运维人员的收件箱很快就会被“轰炸”，最终可能导致重要告警被直接屏蔽。因此，实现状态记忆和冷却控制机制必不可少。

一个常见的做法是，利用临时文件记录上次告警的发送时间，例如/tmp/nginx_alert_last_sent。每次准备发送告警前，先读取这个文件中的时间戳，如果距离现在不足15分钟，就跳过本次发送，进入冷却期。

同样重要的还有恢复通知。当服务从故障状态恢复正常时，也应该及时告知：if [ “$last_state” = “down” ] && [ “$current_state” = “up” ]; then echo “Nginx recovered at $(date)” | mail -s “✅ Recovered” admin@example.com; fi。这能形成一个完整的“故障-恢复”闭环。

另外，不要想当然地依赖mail命令。许多最小化安装的Linux系统并没有安装mailx套件。更稳妥的做法是使用echo … | sendmail -t，或者直接通过curl -X POST调用企业微信、钉钉等平台的Webhook接口来发送告警。

脚本放哪儿、谁来跑、权限够不够

脚本编写完成，只是万&里长征第一步。部署时的路径、执行权限和环境配置，才是决定它能否长期稳定运行的幕后细节。其中，crontab的权限、PATH环境变量以及输出重定向，是最容易导致脚本静默失败的三个地方。

脚本的存放路径应该固定，例如/opt/monitor/check_nginx.sh。避免使用~/（家目录）或相对路径，防止因用户切换或当前目录变化导致脚本找不到。

在crontab中，务必显式声明PATH环境变量：PATH=/usr/local/bin:/usr/bin:/bin。否则，在cron的特殊环境下，很可能找不到pgrep、ss这些命令。

所有输出，包括标准输出和错误输出，都应该被重定向到日志文件：/opt/monitor/check_nginx.sh >> /var/log/monitor/nginx_check.log 2>&1。如果没有这行配置，脚本运行中的任何错误都将石沉大海，无从排查。

运行用户方面，建议使用root或专为监控创建的monitor系统用户。避免使用个人账号，一旦账号密码变更或家目录被清理，依赖它的定时任务就会随之停摆。

最后，还有一个极易被忽略的环节：信号处理和锁机制。如果脚本的两个实例同时运行，可能导致并发发送重复告警；如果脚本被强制终止时没有清理临时状态文件，下次启动就可能基于错误的历史状态做出误判。解决之道并不复杂，哪怕只是在脚本关键逻辑外包裹一层flock -n /tmp/check_nginx.lock -c “…”，也能有效防止并发问题，让脚本的可靠性提升一个档次。