控制台 · 告警
告警的界面都在设置 → 告警配置下：一个概览仪表盘 + 七个管理子页，外加按来源分的三个事件视图。这页按"看告警 → 配规则 → 通渠道"的顺序讲清楚各自的位置与用法；告警的数据模型（dc3_entity_alarm、来源/类型两个维度、确认语义）见告警与通知。
你在这里：数据在进库、设备状态正常，现在要把"出问题找人"这条链路配起来。通知链路的表结构与 API 见告警页；此处只讲界面。
概览仪表盘
告警配置 → 概览是值班第一屏，组件包括：
- 未确认时长分布（aging）——未确认告警按 <1h / 1–4h / 4–24h / >24h 分桶，一眼看出有没有陈年未处理；
- MTTA / MTTR——平均确认时长与平均恢复时长，衡量响应质量；
- 告警类型占比、事件趋势图、活跃热力图；
- 告警风暴源 / 振荡源 / 同源关联——定位"哪台设备在刷屏"与"哪些告警是同一根因"；
- 每个来源区块都有**"未确认"快捷入口**，一键跳到对应事件视图并带上
confirmFlag=0过滤。
三个事件视图：设备 / 驱动 / 位号
同一张 dc3_entity_alarm 表按来源切成三个视图（设备 / 驱动 / 位号），列与过滤一致：按类型、确认状态、时间窗筛选；行内确认（对应 POST /dashboard/alert/confirm）与查看详情。批量处理建议从概览的风暴源定位再进来确认。
告警规则
告警规则页维护 dc3_rule：什么条件触发告警（阈值/状态变化/事件匹配）、级别（LOW/MEDIUM/HIGH/CRITICAL）。规则保存后由数据中心的告警引擎在值链路上评估——改规则不需要重启任何服务，下一批值进来即生效。
通知链路：策略 → 模板 → 渠道 → 绑定
通知怎么"送达到人"由四页共同决定，配置顺序：
| 子页 | 管什么 | 对应表 |
|---|---|---|
| 通知策略 | 谁的告警、什么级别、多久发一次（防轰炸） | dc3_notify |
| 消息模板 | 通知文案长什么样（变量替换） | 模板字段 |
| 通知渠道 | 通过什么发（邮件 / 短信 / Webhook）及各自的连接参数 | dc3_notify_channel |
| 渠道绑定 | 哪条策略走哪个渠道 | dc3_notify_channel_bind |
链路数据流：告警产生 → 命中策略 → 渲染模板 → 投递任务进 dc3.q.notify.task（TTL 24 小时）→ 渠道发送 → 发送历史留痕。
运行状态与历史
- 告警运行状态：每条规则的当前状态机（
dc3_rule_state）——规则是否命中中、上次触发时间； - 告警历史：全部告警的归档查询，含确认记录；对应
dc3_notify_history的送达审计另在通知侧查询。
界面动作与 API 的对应
| 界面动作 | API（经网关，data 中心） | 语义 |
|---|---|---|
| 事件视图查询 | POST …/dashboard/alert/page | 按 source/类型/确认态分页 |
| 确认 / 取消确认 | POST …/dashboard/alert/confirm?source=&id= | 行级确认（返回 true=确实更新） |
| 概览统计 | GET …/dashboard/alert/stats / …/alert/latest | 汇总卡片数据源 |