一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
容器·快照
use-cases / heartbeat-for-silent-jobs / hero
CRON · NOTIFICATIONS · SILENCE-ALARM
为沉默的任务装上心跳
大多数监控盯着发生过的事。你需要的是一个盯着没发生的事的东西。两条 cron —— 一条跳动，一条聆听跳动的缺席 —— 还有一条在沙滩上也能找到你的呼叫。
ops · heartbeats
https://ops.containers.hoody.com/heartbeatslive
受监控任务 · 最近 24 次跳动
6 / 6- backup-prod-db2h 06m ago@daily · 02:00
- rotate-api-keys6m ago0 4 * * 0 · weekly
- cleanup-stale-snapshots3m ago0 * * * * · hourly
- export-stripe-ledger11h 04m ago@daily · 03:30
- renew-letsencrypt1h 12m ago0 1 * * * · daily
- vacuum-postgres2m ago*/15 * * * *
沉默观察者
# 缺失跳动时呼叫*/15 * * * *curl /silence-check
通道
- push · ios
- sms · twilio
- email · ops@
正常 延迟 缺失窗口:24 次跳动
两条 cron · 零新服务 · 什么都没发生时,告警来找你
use-cases / heartbeat-for-silent-jobs / mechanism
两条 cron。一条说我还活着。另一条聆听沉默。
你已有的任务继续干自己的活。完成后,它额外加一条 curl:向通知端点 POST 一行心跳。第二条 cron 按自己的节奏运行,检查沉默 —— 如果没有新心跳,它就呼叫你的手机。任务的成功是无声的。它的缺席是响亮的。
worker.cron · 任务
POST · heartbeatschedule0 2 * * *
# After the nightly export finishes,# the job pings its own heartbeat.0 2 * * * /usr/local/bin/export.sh \ && curl -fsS -X POST \ https://notify.containers.hoody.com/heartbeats/backup-prod-db
缺席就是信号
watcher.cron · 聆听者
GET · silence-checkschedule*/15 * * * *
# Every 15 minutes, ask: was there a beat?# If silent for >1h, the API pages all channels.*/15 * * * * curl -fsS \ https://notify.containers.hoody.com/silence-check?\ job=backup-prod-db&max_age=1h
两次 POST 到 /users/root/entries,带 5 字段的表达式。第一条在每个定时任务后运行,发送它的心跳。第二条按自己的节奏运行,询问通知端点最后一次跳动是否仍然新鲜,不是就触发呼叫。无队列、无代理、无守护进程 —— 只有两行原本就必须存在的 crontab。
use-cases / heartbeat-for-silent-jobs / powers
为什么盯着缺席不一样
大多数监控工具盯着成功路径:有事发生时告警。这种形态在没有事发生时告警 —— 而那正是沉默的任务每次都会输掉的场景。
FAILURE MODES
捕获沉默的崩溃
如果 worker 进程根本没启动 —— 机器重启、脚本被删、配额过期 —— 没有任何东西可以记录,也没有任何东西可以告警。观察者 cron 仍然照常运行,并发现心跳行已经过期。捕获沉默崩溃的东西,正是不依赖那个沉默对象的东西。
ZERO SURFACE
没有新服务需要照看
监控只是一行额外的 crontab,而不是一个 Healthchecks.io 账号或 CloudWatch 告警。它和工作绑定在同一个容器里,如果你需要,可以用 `expires_at` 一起过期,并从你栈里其他部分已在使用的同一个通知 API 读取。
REACHES YOU
在重要的时候够响
通知端点把呼叫扇出到推送、短信和邮件 —— 那些你已经信赖的通道。你不盯面板。面板自己盯自己,只在沉默拖得过久时,在巴厘岛的沙滩上找到你。
use-cases / heartbeat-for-silent-jobs / capacity
真实的 cron,真实的通知
机制就是普通的 Hoody Cron 加 Hoody Notifications。数字来自有据可查的 API 表面,而不是 demo 运行时。
- ALL CRON SYNTAX@daily
标准的 5 字段表达式加宏 —— `@hourly`、`@daily`、`@weekly`、`@monthly`、`@yearly`。观察者和 worker 可以有完全不同的节奏。
- AUTO-EXPIRYexpires_at
受管理的条目支持 `expires_at`,所以一个临时心跳(比如一周的迁移窗口)能自己清理。观察者随工作一同消失。
- ISOLATIONper-user
每个容器都有自己的 crontab。一个租户的心跳无法静音另一个租户的观察者,禁用一个任务只是一次 PATCH `enabled: false`。
限制以 Hoody Cron API 为准:5 字段表达式加 `@hourly`/`@daily`/`@weekly`/`@monthly`/`@yearly` 宏,受管理条目可选 `expires_at`,按用户隔离的 crontab,通过 PATCH 启用/禁用。
use-cases / heartbeat-for-silent-jobs / punchline
沉默,如今是一种告警。
BEFORE · WATCHING THE LOGopen dashboard · search for last export · sigh · forget你只在周一才注意到任务没跑
AFTER · WATCHING THE QUIET*/15 * * * * curl /silence-check?job=backup-prod-db沉默还很小的时候,呼叫已经找到你
use-cases / heartbeat-for-silent-jobs / replaces
这取代了什么
你想要带呼叫的 cron 监控时常会去够的工具。每一个都是单独的账号、单独的账单、单独的 API。两行 crontab 加上通知端点就能完成同样的事。
- custom orchestrators为两行 crontab 而搭一整套编排服务
- Healthchecks.io光为了接收一个 HTTP 心跳而开的 SaaS 账号
- Cronitor按监控数计费,只为做一件你的容器自己就能做的事
- Dead Man's Snitch完全相同的模式,被卖成订阅
- AWS CloudWatch alarms for cron为一行过期的记录搭 Lambda + 告警 + IAM 策略
- custom heartbeat collection scripts搭一个微服务来记录一个 cron 自己就能 POST 的值
use-cases / heartbeat-for-silent-jobs / cta
别再盯着成功路径。盯着成功的缺席 —— 沉默的失败只活在那里。
use-cases / heartbeat-for-silent-jobs / related
阅读其他内容
