Skip to content

feat(notifications): Webhook 事件通知——给熔断/配额/健康检查装上出口 #235

Description

@g1331

背景

系统已建成多层防护机制:熔断器、上游健康检查、密钥/上游花费配额、每日预算。但它们的状态变化目前全部是无声的——熔断打开、上游被标记 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 等)。
  • 用量突增异常检测告警。

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature新功能请求

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions