脚本挂机任务在虚拟专用服务器上跑，不监控等于裸奔，核心思路是三层监控：存活检测、资源预警、业务结果校验，搭配一套告警通知，宕机半小时内你就能知道。
很多朋友把脚本扔到VPS上就不管了，觉得服务器不死脚本就一直跑，进程假死、内存泄漏、API接口被限流、磁盘写满，随便一个都能让挂机任务悄悄停摆，今天这篇就聊聊VPS上监控脚本挂机任务的完整思路，从指标到工具，从配置到告警,一次性说清楚。
挂机脚本在VPS上最常见的死法
脚本挂机任务莫名其妙中断，多数情况下不是服务器宕机,而是下面这几类问题。
进程还在，但已经不干活了，比如Python脚本里的某个线程卡在等待响应上，没有超时机制，看起来进程活着，CPU占用率极低,实际业务早就停转了。
内存被吃完，系统开始杀进程，Linux系统在物理内存耗尽时会触发OOM Killer，优先杀掉占用内存大的进程，如果你的脚本有内存泄漏，通常会在运行几天后突然消失，查看dmesg或/var/log/messages能看到Out of memory的痕迹。
磁盘满了，日志写不进去，脚本一直往日志文件里追加内容，几个月不清理，磁盘塞满，脚本尝试写日志或写数据库时直接抛出异常,然后退出。
依赖的外部接口出问题，比如你挂的是抢票脚本，目标网站的接口变更了或者风控升级了，脚本在某个环节反复报错,重试次数用尽后退出。
脚本挂机服务器监控方案：核心指标抓这几个就够了
监控不是越多越好，对挂机任务来说，抓核心指标最有效，监控系统本身也会消耗资源，VPS配置本来就不高,堆一堆采集器得不偿失。
进程级监控：确认脚本还活着
最简单的方案是systemd服务托管脚本，服务挂了自动拉起,同时监控服务状态。
配置一个systemd服务，把脚本交给系统托管，只要进程异常退出，systemd会自动重启脚本，同时我们对服务状态做监控,就能第一时间发现问题。
资源监控：CPU、内存、磁盘、网络
- CPU使用率：持续跑满说明脚本还在算东西，长时间接近0可能说明卡死或已经退出,但需要结合业务判断。
- 内存占用率：关注脚本进程的内存增长趋势，如果每天涨一些，几周后接近临界点,就得准备重启策略。
- 磁盘使用率：检查日志分区剩余空间，建议高于80%就预警，90%会严重影响写入性能。
- 网络连接数：脚本做请求类任务时特别重要,异常飙升可能说明被扫描或脚本逻辑出错。
业务结果校验：确认脚本在真正干活
这一层是多数人忽略的，但恰恰最关键，监控CPU和内存只能说明进程活着,不能说明任务在推进。
举个例子，你的脚本每天要提交10个订单，如果今天只提交了2个就卡住了，CPU还在跑，内存也正常，到底怎么发现？答案是业务日志埋点加结果校验。
脚本每个关键步骤结束后写一条结构化日志，监控系统定期检查日志里最近一次成功标记的时间，如果超过了预期间隔，比如10分钟没有新的成功日志,就触发告警。
VPS监控脚本怎么配：开箱即用的组合方案
这里推荐两套方案，一套面向喜欢折腾的,一套面向追求省事的。
NodePing + 宝塔面板（适合新手）
宝塔面板自带监控模块，能看到CPU、内存、磁盘、带宽的实时曲线和历史记录,而且有免费的告警通知功能。
具体操作路径：宝塔面板 → 监控 → 设置告警阈值，比如CPU超过90%持续5分钟就推送通知。
同时给脚本写一个心跳接口，或者监控日志文件更新时间的shell脚本，用宝塔的计划任务功能每5分钟跑一次,发现异常就调用告警接口。
Prometheus + Alertmanager（适合跑多个任务的老手）
这套组合功能最强，Prometheus负责采集指标，Alertmanager负责告警路由，配合Grafana出图表,直观程度很高。
采集端用node_exporter获取系统指标，脚本自己暴露一个Prometheus格式的指标端点，比如last_success_timestamp,Prometheus每30秒抓一次。
告警规则示例如下：
groups: - name: script_monitoring rules: - alert: ScriptHeartbeatLost expr: time() - script_last_success_timestamp > 300 for: 2m annotations: summary: "脚本心跳丢失，超过5分钟没有成功执行记录"
这个规则的意思是脚本最近一次成功时间戳距当前时间超过5分钟就告警，连续2分钟满足条件才触发,避免偶发抖动误报。
挂机服务器告警通知怎么设置：把消息推到手机上
监控数据有了，告警规则配了，如果通知发不出来，前面全部白做,目前比较实用的通知渠道有三种。
钉钉/企业微信机器人
创建群机器人后拿到Webhook地址，Alertmanager的webhook_config直接指向它即可，配置好后，告警消息会直接推送到群里,手机端实时收到。
Telegram Bot
Telegram的消息接口对开发者比较友好，Bot API是公开的，注册一个Bot把Token配进Alertmanager，再配合Telegram的通知渠道,一条告警消息从触发到推送到手机通常只需要几秒。
短信/电话
短信服务需要付费，比如简米云短信、酷番云短信，一毛钱一条，电话告警比较昂贵，通常只用来处理最严重的场景,比如服务器宕机或者磁盘接近满容时。
个人建议：常规脚本异常推钉钉或Telegram,服务器宕机推送才考虑短信。
挂机VPS监控的常见坑：白监控一场的几类情况
监控搭好了不代表万无一失，下面几个坑如果你踩中了,监控基本形同虚设。
告警阈值设得太宽，比如CPU监控阈值设为99%，实际上脚本卡死后CPU占用率降下来了，根本达不到触发条件，资源告警的阈值要参考脚本正常运行时的基线数据,上下浮动百分之十到二十比较合理。
监控进程本身挂了不知道，Prometheus进程如果挂了，告警规则就不会执行了，对监控系统本身也要做存活监控,可以用宝塔或者外部监控服务定时检查Prometheus端口的可达性。
只在服务器内监控，没考虑网络连通性，服务器内部一切正常，但VPS所在机房网络出问题了，外部根本访问不到你的服务，而你只监控了内部指标，自然发现不了，建议选一台别的机器或使用云厂商自带的拨测服务,定期探测你VPS上的对外端口。
通知渠道单一，告警发不出去，Webhook地址失效了、Telegram网络不通，告警就发不出来了，有条件就配置两个通道，钉钉发不出来时发Telegram,或者发邮件兜底。
多机挂机场景怎么做集中监控
有些朋友手上不止一台VPS，每个都登进去看效率太低，比较推荐的做法是把所有指标汇总到一个Grafana面板上，一台机器一个dashboard行,全部集中在一个团队视图里也可以。
Grafana支持多数据源，一台Prometheus就能采集多台node_exporter的指标，在告警规则里用instance标签区分不同机器即可，配合Grafana的标签模板,可以快速过滤出某一台具体机器的状态。
钉钉群里收到告警时，消息里会带着instance标签，你能直接看到是哪台VPS、跑到什么任务出了问题,省去逐台排查的时间。
Q&A：脚本挂机监控常见疑问
问：VPS监控脚本本身会消耗多少资源？
不算多，node_exporter本身内存占用一般在20-50MB之间，Prometheus的内存跟指标量和保留时间有关，如果只监控几台机器，512MB内存的VPS完全带得动这个监控组合，但如果你跑的是多个重型脚本，内存本来就紧张，监控进程可能会反过来挤压脚本资源，建议把监控部署在另一台轻量机器上,被监控的机器只跑采集端。
问：脚本日志一直增长怎么办？日志文件会不会把磁盘撑爆？
需要配置日志轮转，Linux自带的logrotate可以按大小或按时间切割日志，比如每天切割一次，保留最近7天的日志文件，超过7天自动删除，对挂机脚本来说，日志保留一周足够排查问题，更久之前的历史记录多数场景下没有多少价值，在/etc/logrotate.d/下新建一个配置文件，指定日志路径、切割周期和保留份数就行。
问：监控告警发现脚本挂了，最好的处理方式是自动重启还是人工介入？
分场景，如果任务是抢单、签到这类状态无关的重复动作，自动重启没问题，但如果是涉及金额交易、数据库写入的任务，自动重启可能引发重复提交，这类任务建议告警后人工确认状态再操作，在自动化脚本里加上一个互斥锁或者幂等机制，可以在一定程度上让自动重启更安全,但人工确认仍然更稳妥。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/657353.html
