监控工具自己挂了，谁来监控它？这是PulseWatch创始人最近在思考的问题。上一篇文章里，他发现了一个"监控bug"——配置为每15分钟运行的GitHub Actions工作流，有时会消失超过一小时。PulseWatch检测到了异常，发出MISSING警报，并在GitHub最终重新运行工作流后报告恢复。

烟雾报警器没坏，确实有烟。这对产品是有价值的验证，但也暴露了几个不那么舒服的问题：谁来看守PulseWatch这个看守者？调度器不可靠时，用户该如何配置宽限期？如果用户需要帮助，真的能联系到他吗？

打开网易新闻 查看精彩图片

过去两周，他没有开发什么新功能，而是在处理那些让监控产品不那么脆弱的不起眼的工作。

看守者有了自己的看守者

PulseWatch有一个独立的调度服务，检查每个监控器并判断其状态是正常、缺失、失败还是卡住。这种分离是产品运作的基础——被监控的脚本无法报告自己从未启动，所以必须有外部机制来发现它的缺席。

但架构中有一个尴尬的缺陷：如果PulseWatch的看守进程停止运行，没有人会收到警报——包括创始人自己。Web应用可能还在线，任务可能还在发送ping，运行历史可能还在数据库里累积。但负责评估这些运行并发送警报的进程可能已经死了。对监控产品来说，这是一个相当严重的盲区。

他现在用Healthchecks.io对看守进程进行了仪表化，这个服务运行在PulseWatch基础设施之外。每个看守周期都会发送信号，Healthchecks也知道看守进程应该多久运行一次，所以如果进程根本没有启动，它就能发出警报。

这个集成刻意设计为尽力而为且非阻塞的。如果Healthchecks不可用，绝不能阻止PulseWatch检查用户的监控器。监控监控器这件事，永远不应该破坏被监控的东西。

这样就形成了一个简单的链条：用户的任务→PulseWatch看守进程→外部看守者。没有什么是完美自监控的，但故障域现在被分开了。PulseWatch不再负责发现自己警报进程的死亡。

调度器事故变成了文档

GitHub Actions事件还表明，PulseWatch的配置需要更好的解释。一个监控器有三个重要的时间设置：间隔、宽限期和超时。这些听起来很直观，直到一个配置为15分钟间隔的调度器产生90分钟甚至更长的间隙。

15分钟的调度并不意味着15分钟的宽限期是安全的。GitHub明确记录了定时工作流在高负载期间可能被延迟，而且在足够高的负载下，一些排队任务可能被丢弃。因此，正确的宽限期取决于任务的关键程度和调度器的可靠性——这不是一个可以随意设置的默认值。