规则类型
scheduled
周期性 SQL 评估。规则的查询按间隔运行,触发条件决定是否告警。
realtime
接入内谓词匹配。数据落地即评估,因此亚秒级触发 —— 比任何 scrape/eval 间隔方案都快。
anomaly
用 MAD(中位数绝对偏差)建立基线,外加 3σ 带。序列偏离学习到的基线时触发。
升级策略
升级策略是挂在规则上的多步计划,由alert_manager 角色驱动:
- 每次 tick 扫描未关闭的 incident。
- 若当前 step 尚未派发,则解析该 step 的 targets 与 on-call,通过对应渠道发送。
- 若在
ack_timeout前未收到确认,则前进到下一 step 再次派发。 - 重复直到 incident 被确认或解决,或所有 step 走完。
渠道
通知通过 Slack、webhook、email 发出,配 PagerDuty 风格的升级与模板变量。incident 携带step、acknowledged_at、resolved_at,对应 PagerDuty 的 incident 生命周期。
通过 API 管理告警
| 端点 | 用途 |
|---|---|
POST /api/v1/alerts/rules | 创建规则 |
GET / PATCH /api/v1/alerts/rules/{id} | 读取 / 更新规则 |
POST /api/v1/alerts/escalations | 创建升级策略 |
POST /api/v1/alerts/channels | 创建通知渠道 |
GET /api/v1/alerts/incidents | 列出 incident |
POST /api/v1/alerts/incidents/{id}/ack | 确认 incident |
POST /api/v1/alerts/incidents/{id}/resolve | 解决 incident |
告警逻辑已完成,需要生产环境的实战时长。若实时规则漏掉事件或升级行为异常,请带上规则定义提
issue。