前端故障复盘的排查路径周日早上 8 点半手里的咖啡还没喝完用户群里就已经炸开了锅“服务怎么全 502 了”登跳板机一看数据库和 Node 应用全挂了。原因极其低级框架生成的 debug 调试日志一夜之间塞满了硬盘df -h现实根分区使用率 100%。由于没有配置基础巡检整整 4 个小时服务都处于瘫痪状态。很多独立开发者把大部分精力放在了写代码和看前端页面上完全把服务器运维抛在脑后。等事故真正爆发时往往只能手忙脚乱地清理垃圾文件。搭建一套无依赖、轻量级且自带自愈功能的自动化运维巡检脚本是让独立项目在没人盯着时也能稳定运转的基础。1. 磁盘被日志打满 100%服务静悄悄死掉的周日早晨在跳板机上运行诊断命令眼前的一幕让人哭笑不得Filesystem Size Used Avail Use% Mounted on /dev/vda1 40G 40G 0 100% / tmpfs 2.0G 4.0K 2.0G 1% /dev/shm进一步查明大文件分布发现一个app-debug.log居然啃掉了 28GB 空间# du -sh /var/log/* | sort -rh | head -n 5 28G /var/log/app/app-debug.log 850M /var/log/nginx/access.log 120M /var/log/journal没有任何防爆措施、没有任何自动清理逻辑、没有任何告警通知。独立开发者如果不做日常巡检就相当于把服务放在定时炸弹上跑。2. 轻量级无依赖巡检系统与多级告警架构对于独立项目来说引入一套复杂的 Prometheus Grafana 监控集群成本太高既耗费内存又增加运维负担。我们需要的是一个单 Bash 脚本 Cron 组合的极简巡检自愈系统。核心设计理念零外部依赖仅依赖 Linux 系统自带的 Bash、curl、awk、df。先自愈后告警遇到常见故障如日志塞满、进程崩溃脚本先尝试自动清理或重启实在解决不了再发消息轰炸开发者。静默原则一切正常时不发任何垃圾消息只在触发阈值时告警。3. 可落地的 Bash/Python 巡检脚本与异常自愈处理下面是一套经过线上实测的独立开发者通用日常巡检与自愈 Bash 脚本auto_inspect.sh#!/usr/bin/env bash # # 独立项目轻量级运维巡检与自愈脚本 # # 配置参数 DISK_THRESHOLD85 # 磁盘占用报警阈值 (%) MEM_THRESHOLD90 # 内存占用报警阈值 (%) CHECK_URLhttp://127.0.0.1:8080/health # 服务健康检查接口 WEBHOOK_URLhttps://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyYOUR_BOT_KEY # 1. 检查磁盘状态并执行自愈 check_disk() { USAGE$(df -h / | awk NR2 {print $5} | sed s/%//) if [ $USAGE -gt $DISK_THRESHOLD ]; then echo [WARNING] Disk usage high: ${USAGE}%. Initiating self-healing... # 自愈动作 1: 清理日志文件 find /var/log/app/ -name *.log -mtime 3 -exec rm -f {} \; journalctl --vacuum-size200M # 重新检测 NEW_USAGE$(df -h / | awk NR2 {print $5} | sed s/%//) send_alert ⚠️ 磁盘警告 磁盘占用已达 ${USAGE}% (已自动清理至 ${NEW_USAGE}%) fi } # 2. 检查应用进程与 HTTP 接口存活 check_service() { HTTP_CODE$(curl -s -o /dev/null -w %{http_code} --connect-timeout 5 $CHECK_URL) if [ $HTTP_CODE -ne 200 ]; then echo [CRITICAL] Service endpoint returned $HTTP_CODE. Restarting service... # 自愈动作 2: 自动重启主服务 systemctl restart my-backend-app sleep 3 RECHECK_CODE$(curl -s -o /dev/null -w %{http_code} --connect-timeout 5 $CHECK_URL) if [ $RECHECK_CODE -eq 200 ]; then send_alert ✅ 服务自愈成功 HTTP 接口异常 ($HTTP_CODE)已通过 systemctl 自动拉起服务。 else send_alert 紧急故障 服务已崩溃 (HTTP $HTTP_CODE)自动重启失败请立刻人工干预 fi fi } # 3. 发送 Webhook 告警消息 send_alert() { TITLE$1 MESSAGE$2 HOSTNAME$(hostname) PAYLOAD$(cat EOF { msgtype: markdown, markdown: { content: ### ${TITLE}\n **主机**: ${HOSTNAME}\n **时间**: $(date %Y-%m-%d %H:%M:%S)\n **详情**: ${MESSAGE} } } EOF ) curl -s -X POST -H Content-Type: application/json -d $PAYLOAD $WEBHOOK_URL /dev/null } # 执行巡检 check_disk check_service赋予脚本执行权限并挂载到系统 Cron 中chmod x /usr/local/bin/auto_inspect.sh4. 手动触发与自动化 Cron 测试配置完成后应手动触发各种极限边界条件测试自愈与告警链路是否顺畅。查看并编辑系统 Cron 定时任务# 编辑 Crontab配置每 10 分钟自动巡检一次 (crontab -l 2/dev/null; echo */10 * * * * /usr/local/bin/auto_inspect.sh /var/log/auto_inspect.log 21) | crontab -在跳板机上运行诊断命令模拟服务崩溃并观察自愈日志# 模拟手动杀掉后端应用进程 pkill -f my-backend-app # 手动触发巡检脚本 /usr/local/bin/auto_inspect.sh # 查看自愈日志输出 tail -n 20 /var/log/auto_inspect.log # 查看 Linux 系统定时任务执行记录 grep auto_inspect /var/log/cron测试验证表明脚本在服务被 Kill 掉后的 10 秒内检测到 HTTP 500 异常自动触发systemctl restart拉起进程并在微信 Hook 中推送了带自愈标记的通知整个过程完全不需要人为干预。5. 巡检自愈监控指标与常规规则集独立项目日常巡检的核心在于收敛指标防范最常见的系统崩溃点巡检维度监控阈值自动化自愈动作告警级别磁盘空间Used 85%清理 3 天前旧 Log 与 docker 镜像缓存P2 ( warning )服务存活HTTP ! 200或PID 消失systemctl restart尝试拉起 1 次P0 ( critical )内存水位Mem 90%sync echo 3 /proc/sys/vm/drop_cachesP2 ( warning )TCP 连接数TIME_WAIT 2000调整net.ipv4.tcp_tw_reuse 1参数P3 ( notice )SSL 证书剩余天数 7 天自动调用certbot renew刷新证书P1 ( error )运维不是搞花架子。用最简单的 Bash 脚本把常见的死机隐患掐灭在萌芽状态独立开发者才能从无休止的“灭火”中解脱出来。