[Feature] 告警 Webhook 外发：打通响应策略配置与真实推送

[databufflabs]

背景 / 问题

DataBuff 告警链路（规则评估 → 事件 → 告警 → 响应分发）已跑通，但外部通知能力不完整：

• 文档（docs/使用手册/告警.md）写明：Webhook、邮件等外部通知尚未支持
• Roadmap 中「告警更强 → 通知集成」仍为规划项
• 前端已有响应策略里的 Webhook 配置 UI（URL、Method、Headers），但后端未真正执行
• 存在两套 Webhook 路径，均未与 UI 完整打通

现状梳理：

能力	现状
全局 Webhook	NotifyChannelService + /api/v1/alarm/notify/config，POST 固定 JSON，无前端管理页
响应策略 Webhook	AlarmResponseExecutor 读取 respActions，但字段与 UI 不一致
UI 保存格式	{ way: "webhook", config: { webhookUrl, webhookMethod, webhookHeader } }
后端期望格式	{ type: "webhook", url: "..." }
测试推送	POST /notify/testCustomWebhook 开源版返回 stub，无法验证配置
通知记录	/notify/records 为空，告警详情「响应」Tab 无数据

期望方案

1. 打通响应策略 Webhook（P0）

• 修复 UI ↔ 后端 schema 映射，使响应策略中配置的 Webhook 在告警触发时真实外发
• 支持 UI 已提供的：HTTP Method（GET/POST/PUT）、自定义 Headers
• 支持 respConditions（首次通知 / 重复通知 / 恢复通知）的条件判断

2. 完善 Webhook Payload（P0）

当前 payload 仅 4 个字段：

{"alarmId":"...","service":"...","status":"...","message":"..."}

建议扩展为结构化告警事件，至少包含：

• alarmId, service, status, level, message
• ruleName, ruleId, eventId
• triggerTime, resolveTime（如有）
• eventType（trigger / recover）
• labels / tags（如有）

并提供 payload 版本字段（如 schemaVersion: "1.0"），便于下游兼容。

3. 全局 Webhook 配置 UI（P1）

• 为 /api/v1/alarm/notify/config 提供系统管理入口（或复用 /sysManage/notice）
• 支持启用/禁用、URL 配置、测试推送

4. Webhook 测试与通知记录（P1）

• 实现 testCustomWebhook，返回真实 HTTP 结果（状态码、响应摘要）
• 持久化通知记录：时间、目标 URL、HTTP 状态、告警 ID、重试次数
• 告警详情「响应」Tab 可查看外发历史

5. 可靠性（P2，可分期）

• 失败重试（指数退避，可配置次数）
• 可选签名（HMAC-SHA256 / Bearer Token）
• 超时与并发控制

不在本期范围

• 邮件、短信、钉钉、企业微信等 IM 通道（可另开 Issue）
• 告警收敛策略完整实现

验收标准

• 在响应策略中配置 Webhook 后，告警触发时目标 URL 收到 POST/GET/PUT 请求
• 自定义 Headers 生效
• Payload 包含上述扩展字段
• UI「测试 Webhook」可验证连通性
• 告警中心可查看该次外发记录
• 单元测试覆盖 schema 映射与 dispatch 逻辑

相关代码

• ai-apm-web/.../monitor/NotifyChannelService.java
• ai-apm-web/.../monitor/pipeline/AlarmResponseExecutor.java
• ai-apm-frontend/.../alarm/responseSetting/notice-receiver-config.vue
• ai-apm-web/.../portal/NotifyPortalController.java（stub 需替换）