背景
系统已建成多层防护机制:熔断器、上游健康检查、密钥/上游花费配额、每日预算。但它们的状态变化目前全部是无声的——熔断打开、上游被标记 unhealthy、配额烧到上限,只有打开面板才能看到。对个人部署、无人值守的使用场景,这是系统性盲区:所有存量防护能力的产出都没有出口。
服务层现状:仅有 login-rate-limiter 等防护组件,无任何 notifier/alerting 模块。
方案:Webhook 通知通道
先做最通用的一种通道——HTTP webhook(Telegram Bot、邮件网关、Server 酱、飞书/钉钉机器人均可由用户自行转接),暂不内置具体 IM 集成。
触发事件(首批)
| 事件 |
来源 |
| 熔断器 OPEN / 恢复 CLOSED |
circuit-breaker.ts 状态迁移 |
| 上游被标记 unhealthy / 恢复 healthy |
health-checker.ts |
| 密钥或上游花费配额到达阈值(80% / 100%) |
api-key-quota-tracker.ts / upstream-quota-tracker.ts |
| 单日总花费超过预算阈值 |
billing 快照聚合 |
设计要点
- 配置为全局单例设置(可参考 traffic-recording settings 的单例模式):webhook URL、启用的事件类型、阈值参数。
- 事件负载为结构化 JSON(事件类型、时间、主体 ID/名称、详情),供用户端模板化转发。
- 发送失败不影响主链路:异步投递、有限重试、失败仅记日志。
- 去抖/合并:同一主体同一事件在冷却窗口内不重复发(如熔断快速开合震荡时)。
- 管理 API + 设置页 UI(双语文案),含“发送测试通知”按钮。
安全注意
- webhook URL 需过 SSRF 校验(复用
upstream-ssrf-validator.ts 的口径)。
- 通知负载不携带密钥明文等敏感信息。
后续可扩展(本期不做)
- 定时日报/周报:background-sync 已有调度器,可加定时任务把 stats 聚合成摘要推送。
- 内置具体 IM 通道(Telegram/邮件 SMTP 等)。
- 用量突增异常检测告警。
背景
系统已建成多层防护机制:熔断器、上游健康检查、密钥/上游花费配额、每日预算。但它们的状态变化目前全部是无声的——熔断打开、上游被标记 unhealthy、配额烧到上限,只有打开面板才能看到。对个人部署、无人值守的使用场景,这是系统性盲区:所有存量防护能力的产出都没有出口。
服务层现状:仅有
login-rate-limiter等防护组件,无任何 notifier/alerting 模块。方案:Webhook 通知通道
先做最通用的一种通道——HTTP webhook(Telegram Bot、邮件网关、Server 酱、飞书/钉钉机器人均可由用户自行转接),暂不内置具体 IM 集成。
触发事件(首批)
circuit-breaker.ts状态迁移health-checker.tsapi-key-quota-tracker.ts/upstream-quota-tracker.ts设计要点
安全注意
upstream-ssrf-validator.ts的口径)。后续可扩展(本期不做)