谁来看着看门狗?监控 SaaS 背后那些乏味的活
来源:dev.to — 2026-09-03
📋 概述
作者上一篇文章以「被查的监控 bug 其实不是 bug」收尾:一条配置成 15 分钟跑一次的 GitHub Actions 工作流有时会消失一个多小时,PulseWatch 察觉缺席并正确告警。这验证了产品有用,也暴露了几道更不舒服的题——谁来看 PulseWatch 的看门狗?用户该把 grace 设成多大?真出问题时找得到人吗?于是过去几周他没造花哨新功能,而是处理让监控产品更不脆弱的乏味活:用独立于本地的 Healthchecks.io 给看门狗再加一层外部看门狗;把调度器抖动教训写成文档,讲清 expected interval 与 grace 该怎么配;给「优先支持」补上真实邮箱并测通完整往返。
🔑 核心要点
- 若看门狗进程自己停掉,没人会收到告警——包括作者本人,这是监控产品的盲区
- 用 Healthchecks.io 做独立外部看门狗:start/success/failure 三信号加缺席检测
- 监控监控器绝不打断被监控对象,集成刻意做成 best-effort 且非阻塞
- 15 分钟的 cron 不代表 15 分钟 grace 就安全:调度器抖动可造成 90 分钟以上缺口
- 「优先支持」若无实际渠道就是空头承诺,现补上真实邮箱并测通发收往返
💡 金句
一台配置错误的监控工具,会完全按设计运转却依然毫无用处。
👍 0
👎 0
← 返回 dev.to 首页