北京
监控工具最怕什么？不是被监控的对象出问题，而是监控工具自己先挂了。
PulseWatch的开发者最近就撞上了这个尴尬场景。上一篇文章里，他调查了一个"疑似bug"：一个配置为每15分钟运行的GitHub Actions工作流，有时会消失一个多小时。PulseWatch检测到了异常，发出MISSING警报，并在GitHub最终重新运行工作流后报告恢复。
烟雾报警器没坏，确实有烟。这对产品是次有效验证，但也暴露了几个不太舒服的问题：谁来监控PulseWatch这个监控工具？调度器不可靠时，用户该怎么配置宽限期？如果用户需要帮助，真能联系上开发者吗？
过去两周，他没在开发什么新功能，而是埋头处理那些让监控产品更稳固的"不性感"工作。
给监控工具配了个外部哨兵
PulseWatch有一个独立调度服务，负责检查每个监控项并判定其状态为OK、MISSING、FAILED或STUCK。这种分离是产品的基础逻辑——被监控的脚本无法报告"自己从未启动"，所以必须由外部进程来发现它的缺席。
但架构里有个尴尬的缺陷：如果PulseWatch的看门狗进程停止运行，没人会收到警报，包括开发者自己。Web应用可能还在线，任务可能还在发ping，运行历史可能还在数据库里累积，但那个负责评估运行状态、发送警报的进程可能已经死了。
对监控产品来说，这是个相当严重的盲区。
他的解决方案是：用Healthchecks.io（一个外部监控服务）来监控PulseWatch的看门狗。每个看门狗周期会向Healthchecks发送信号，Healthchecks知道看门狗应该以什么频率运行，如果进程完全没启动，它就能发出警报。
这个集成刻意设计为"尽力而为、非阻塞"——如果Healthchecks不可用，绝不能阻止PulseWatch检查用户的监控项。监控监控器的行为，永远不应该破坏被监控的对象。
这样就形成了一条简单链路：用户的任务 → PulseWatch看门狗 → 外部看门狗。没有什么是完美自监控的，但故障域被分开了，PulseWatch不再需要负责发现自身警报进程的死亡。
调度器事故变成了文档教材
GitHub Actions那次事故还让开发者意识到，PulseWatch的配置需要更好的解释。一个监控项有三个重要的时间设置，听起来很直观，直到一个配置为15分钟间隔的调度器产生了90分钟甚至更长的间隔。
15分钟的调度计划，并不意味着15分钟的宽限期就是安全的。GitHub明确文档说明，计划工作流在高负载期间可能被延迟，而且在足够高的负载下，部分排队任务可能被丢弃。
所以正确的宽限期取决于具体场景，而不是简单套用调度间隔。这个教训被写进了文档，成了配置说明的一部分。
监控工具的价值不在于功能多花哨，而在于它自己能不能稳定运行。PulseWatch这次补上的，恰恰是用户看不到、但关键时刻能救命的那层保障。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
