功能介绍
1. 事件（Event）
事件是告警中心的最小数据单元，代表从外部系统接入的原始告警或状态变更通知。平台通过标准化处理将异构数据转换为统一的事件模型，为后续聚合、分派和恢复判断奠定基础。
1.1 核心定位
事件层解决"数据如何进入平台"和"如何与恢复关联"的问题。它既是多源接入的统一入口，也是告警全生命周期追溯的数据源头。
1.2 核心能力
- 多源接入适配：支持 REST API、NATS 消息通道等多种接入方式，通过 Adapter 模式对接 Prometheus、Zabbix、云监控、Webhook 等异构数据源
- 字段标准化映射：通过
event_fields_mapping配置将不同来源的字段映射到标准事件模型，支持从labels元数据回退取值 - CMDB 信息丰富：可选开启 CMDB 信息自动丰富能力，根据
resource_type和resource_id/resource_name查询并补充实例信息到事件标签 - 恢复事件关联：通过
external_id唯一标识实现恢复事件与创建事件的智能关联，支持自动恢复判断 - 前置屏蔽过滤：事件入库后立即执行屏蔽策略检查，命中策略的事件标记为 已屏蔽（SHIELD） 状态，不进入后续告警链路
界面指引：
- 图表解读/配置逻辑：事件列表用于追溯原始数据，排查"为什么产生了这条告警"或"为什么告警没有恢复"。重点关注事件状态（是否被屏蔽）、动作类型（created/recovery/closed）和解析后的字段值。
2. 告警（Alert）
告警是原始 Event 经相关性规则聚合后形成的可处理单元。相比单条事件，告警更强调责任归属、上下文完整性与处置动作，是值班人员日常工作的核心入口。
2.1 核心定位
告警用于承接需要被人工或自动化流程处理的问题单元。它既保留原始事件的上下文信息（通过多对多关联），也提供统一的状态流转机制，帮助团队把"看到异常"升级为"开始处理问题"。
2.2 状态机模型
告警遵循严格的状态机定义，非法状态迁移将被拒绝：
| 状态 | 说明 | 进入方式 |
|---|---|---|
| unassigned | 未分派 | 告警创建后的初始状态 |
| pending | 待响应 | 自动分派或手动分派后 |
| processing | 处理中 | 责任人认领后 |
| resolved | 已处理 | 人工恢复操作 |
| closed | 已关闭 | 人工关闭操作 |
| auto_recovery | 自动恢复 | 恢复事件覆盖创建事件后自动触发 |
| auto_close | 自动关闭 | 满足策略关闭条件或兜底任务触发 |
2.3 核心能力
- 智能指纹聚合：基于
事件指纹实现精准去重，相同指纹的活跃告警只会更新而非重复创建 - 多维筛选与排序：支持按告警级别、状态、来源、时间范围、"我的告警"等维度筛选；列表按更新时间倒序排列
- 关联事件回溯：每条告警可查看其关联的所有事件，理解聚合过程与上下文变化
- 批量处置操作：支持批量分派、认领、关闭，提升高频操作效率
- 自动恢复判定：当告警关联的创建事件被更晚的恢复事件覆盖时，自动触发
auto_recovery状态流转 - 通知状态追踪：记录每条通知的发送结果（成功/失败/部分成功），便于排查通知链路问题
- 一键升级事故：高影响告警可一键升级为 Incident，进入更高等级的协同流程
界面指引：
- 图表解读/配置逻辑：告警列表强调"快速筛选 + 就地处理"。通过「级别、状态、归属」压缩问题集合后，可直接在列表执行认领、转派或关闭，减少页面切换。
3. 事故（Incident）
Incident 用于承接已经具备更高业务影响的问题。它不是对告警的简单重命名，而是将需要团队协同处置的异常纳入更高等级的管理对象。
3.1 核心定位
当一条或多条告警指向同一高影响问题（如核心业务中断、级联故障）时，将其升级为 Incident，以统一跟踪处置进展、组织处理人员并集中查看关联信息。
3.2 状态机模型
| 状态 | 说明 | 迁移操作 |
|---|---|---|
| pending | 待响应 | 创建后初始状态 |
| processing | 处理中 | 认领操作 |
| closed | 已关闭 | 关闭操作 |
| resolved | 已处理 | 恢复操作 |
事故支持重开（reopen）操作：已关闭的事故可重新进入处理中状态。
3.3 核心能力
- 多告警关联：一个事故可关联多条告警，统一查看相关异常的上下文与处理进展
- 协同信息集中：事故详情页聚合基础信息、关联告警列表、处理过程记录，支持多角色共享同一问题视图
- 甘特图时间线：可视化展示事故生命周期与各阶段耗时，辅助复盘分析
- 独立状态管理：事故具备独立于告警的状态流转，支持认领、关闭、重开等操作
界面指引：
- 图表解读/配置逻辑：事故页面适合处理中高影响的问题。相比告警列表，更强调协同视角，帮助用户从"单条异常处理"切换为"同一问题统一推进"。
4. 集成中心（Integration）
集成中心用于管理事件接入来源，是告警中心的入口层能力。平台通过告警源统一管理不同系统的接入方式、鉴权信息与使用状态。
4.1 核心定位
集成中心解决"事件从哪里来、如何安全地进入平台、如何验证接入是否成功"的问题。将接入配置、指南查看和事件核验集中在同一入口，便于平台管理员维护标准化接入体系。
4.2 支持的接入方式
| 接入方式 | 适用场景 | 鉴权方式 |
|---|---|---|
| REST API | 外部系统主动推送事件 | Header 或 Body 中的 SECRET 字段 |
| NATS | 消息队列异步消费 | NATS 连接配置 |
| Prometheus | Prometheus Alertmanager 集成 | Webhook 配置 |
| Zabbix | Zabbix 告警推送 | 自定义脚本或 Webhook |
| Webhook | 通用 Webhook 接入 | URL + Secret |
4.3 核心能力
- 源级鉴权管理：每个告警源具备独立的接入密钥，支持按来源管理安全边界
- 字段映射配置：通过
event_fields_mapping自定义上游字段到标准事件模型的映射关系 - 接入指南生成：自动生成包含接口地址、请求格式、鉴权参数的接入指南
- 最近事件查看：可在告警源详情中查看最近接收的事件，快速验证接入链路
- 生命周期管理：支持告警源的新增、编辑、停用与删除（软删除）
界面指引：
- 图表解读/配置逻辑：集成中心既是接入配置入口，也是故障排查入口。若接入后没有看到预期告警，应首先确认源配置、鉴权参数和事件接收情况。
5. 设置中心（Settings）
设置中心负责沉淀告警治理规则，让平台从"被动收消息"升级为"主动管理问题"。包括事件侧相关性规则、分派策略、屏蔽策略、系统设置和操作日志等核心能力。
5.1 相关性规则（Correlation Rules）
相关性规则定义 Event 如何聚合为 Alert，是告警中心降噪与提炼价值的核心引擎。
5.1.1 策略类型
| 策略类型 | 说明 | 适用场景 |
|---|---|---|
| 智能降噪（Smart Denoise） | 对匹配事件进行聚合降噪 | 常规监控告警收敛 |
| 缺失检测（Missing Detection） | 检测预期事件未按时到达 | 定时任务、心跳监控 |
| 即时告警（Instant） | 事件入库后立即一对一生成告警，不经聚合窗口 | 需要零延迟感知的关键单点异常 |
5.1.2 窗口类型
| 窗口类型 | 说明 | 适用场景 |
|---|---|---|
| 滑动窗口（Sliding） | 连续时间段，窗口间允许重叠 | 持续异常监测 |
| 固定窗口（Fixed） | 固定时间片，如每分钟/每小时 | 周期性统计 |
| 会话窗口（Session） | 基于事件间隔识别问题持续性 | 抖动过滤、超时检测 |
5.1.3 核心能力
- 灵活匹配规则：支持多组条件组合（外层 OR、内层 AND），可按来源、级别、资源、标签等维度过滤
- 多维分组聚合：通过
group_by定义聚合维度（如resource_id、service），相同维度的事件聚合为单条告警 - 指纹算法去重：基于 MD5 哈希计算事件指纹，确保同一问题只产生一条活跃告警
- 会话观察期：会话窗口策略支持观察期机制，观察期内恢复的事件不转为正式告警
- 自动关闭配置：支持为规则生成的告警设置自动关闭时间，控制长期悬挂问题
- 异步分派调度：新告警通过 Celery 异步任务执行自动分派，不阻塞聚合流程
界面指引：
5.2 告警分派（Assignment）
分派策略负责将符合条件的告警自动分配到责任人或责任团队，提升问题进入处理流程的效率。
5.2.1 匹配类型
| 匹配类型 | 说明 |
|---|---|
| 全部匹配（ALL） | 符合时间范围的未分派告警全部命中 |
| 条件过滤（FILTER） | 按告警字段与规则匹配，支持 eq、ne、contains、not_contains、re 等操作符 |
5.2.2 核心能力
- 灵活生效时间：支持单次、每日、每周、每月四种时间范围配置，适配不同值班排班
- 分级提醒机制：可根据告警级别配置不同的提醒频率（如致命级别每 30 分钟提醒一次，最多提醒 10 次）
- 通知渠道联动：分派成功后自动触发通知，将问题同步给责任人
- 兜底分派保障：未命中任何策略的告警进入兜底队列，按全局配置周期性通知管理员
- 操作日志记录：自动分派操作记录到操作日志，便于审计追溯
界面指引：
- 图表解读/配置逻辑：分派策略的核心是定义"什么类型的问题在什么时间自动交给谁"。合理配置可显著减少人工判断与转派开销，提升 MTTR。
5.3 屏蔽策略（Shield）
屏蔽策略用于过滤低价值、已知或维护窗口内不需要进入告警处置流程的事件。
5.3.1 核心能力
- 多维度条件匹配：支持按来源、资源、标题、内容、级别等字段配置匹配条件
- 灵活时间控制：支持单次、每日、每周、每月等时间范围配置，适用于维护窗口或周期性操作场景
- 前置降噪：命中屏蔽策略的事件在入库后即标记为
SHIELD状态，不进入后续聚合与分派链路 - 可见性保留：被屏蔽的事件仍在事件列表中可查，便于追溯与审计
界面指引：
- 图表解读/配置逻辑：屏蔽策略适合治理"明知无须处理"的事件，如计划内维护、重复性低价值通知。建议谨慎使用，避免过度屏蔽。
5.4 缺失检测策略（Missing Detection）
缺失检测是一种特殊的策略类型，用于检测预期应该到达但未到达的事件，适用于定时任务、心跳监控等场景。
5.4.1 核心能力
- Cron 表达式配置：通过 Cron 定义预期事件到达的时间规律
- 激活模式选择：支持"首条心跳激活"（收到第一条事件后开始监控）或"立即激活"
- 宽限期设置：支持配置宽限期（grace period），在预期时间后延迟一段时间再触发告警
- 自动恢复：当缺失告警产生后，若后续收到符合规则的事件，自动恢复该告警
- 运行时状态追踪：记录最后心跳时间、当前监控状态（waiting/monitoring/alerting）
注意： 缺失检测策略依赖持续的定时任务调度检查，请确保平台 Celery Worker 正常运行。
5.5 告警丰富（Enrichment）
告警丰富通过可管理的声明式规则，在告警生成时自动从外部数据源（当前支持 CMDB）按作用范围匹配并补充上下文字段，解决"告警有了，但不知道影响谁、归谁负责、在哪个机房"的信息缺失问题。
5.5.1 工作原理
每条丰富规则包含以下核心配置项：
| 配置项 | 说明 |
|---|---|
| 作用范围（匹配条件） | OR-of-AND 条件组合，支持等于、不等于、包含、不包含、正则等操作符，不填条件则匹配全部告警 |
| 数据源绑定（入参映射） | 定义从告警字段到数据源查询参数的映射（如用告警的「资源 ID」字段去 CMDB 查同名实例） |
| 输出投影（出参映射） | 声明从数据源结果中取哪些字段、以什么别名写入告警；不配置则将全部结果字段写入 |
| 命名空间 | 为规则指定一个标识名（如 cmdb），丰富结果将按命名空间分区写入告警的扩展信息，不同规则之间的结果互不覆盖 |
| 启用/禁用 | 规则级开关，可单独控制某条规则是否生效，无需删除规则即可暂停其丰富行为 |
5.5.2 多结果处理策略
当一次查询命中多条数据源记录时，可按规则配置以下策略之一：
| 策略 | 说明 |
|---|---|
| 取首条（first） | 默认策略，取排序第一条记录的字段，适合 ID 唯一查找 |
| 合并（merge） | 将多条记录的字段依次合并（后者覆盖前者同名字段） |
| 列表（list） | 将多条记录的同名字段收集为列表，适合一对多关系 |
5.5.3 向告警传播
丰富在事件（Event）接入时执行，结果随事件归并到对应告警（Alert）。同一告警下的多条事件，按命名空间各取首条非空丰富数据，确保后续事件的丰富结果不会覆盖已有上下文。
5.5.4 丰富规则管理
- 可视化增删改：通过设置中心界面创建、编辑、启用/禁用丰富规则，所有变更记录到操作日志
- 内置预设规则：平台提供开箱即用的内置规则（名称以"内置-"开头），可在全局配置中开启丰富功能开关后即刻生效
- 采纳度量统计：设置中心提供丰富规则采纳度量，包括规则总数、启用比例、已丰富告警数量与比例，便于评估配置效果
- 取代全局丰富开关：本功能以精细化规则引擎替代了旧版仅有"开/关"两档的全局告警丰富开关，用户可按告警类型分别配置丰富逻辑，兼顾灵活性与性能
界面指引：
- 图表解读/配置逻辑：丰富规则的核心价值是让值班人员打开告警时，不需要再去 CMDB 或其他系统手动查询"这台主机属于哪个业务、负责人是谁"——这些上下文已自动附加在告警详情中，直接支撑分派与处置决策。
5.6 告警升级（Escalation）
告警升级在分派策略内新增"升级链"能力：告警分派后若在配置的等待时长内未被认领，平台将自动切换或扩展在岗人员集合并重新通知，确保高影响问题不因无人响应而悬挂。
5.6.1 工作原理
升级链以 JSON 结构存储在分派规则内，由独立的 AlertEscalationTask 每分钟扫描推进，与级内提醒任务解耦。每次升级后，提醒计数自动归零、预算按新在岗集合重置，两个时钟共享同一通知发送出口。
5.6.2 升级模式
| 模式 | 说明 |
|---|---|
| 累加（append） | 下一层的处理人叠加到上一层，认领资格不断扩大 |
| 替换（replace） | 下一层的处理人完全替换上一层，通知对象切换为新团队 |
5.6.3 升级链配置
每条升级链由若干层级组成，每层需配置：
| 配置项 | 说明 |
|---|---|
| 处理人（personnel） | 本层在岗的责任人列表（必填，至少一人） |
| 等待时长（wait_minutes） | 在本层等待多少分钟未认领后触发升级（必须 > 0） |
| 本层通知渠道（notify_channels） | 可选，不配置则沿用分派规则的默认渠道 |
第 0 层为初始责任人，后续每层为升级目标。Layer 0 处理人在分派时即并入告警的认领候选集合。
5.6.4 升级终止条件
以下任一操作发生时，升级任务立即停止：
- 认领（Acknowledge）：告警被认领，问题已有人处理
- 解决（Resolve）：告警被标记为已处理
- 关闭（Close）：告警关闭
改派（Reassign） 不停止升级，而是将升级计时重置到第 0 层，从新责任人重新开始倒计时。
注意： 升级任务依赖 Celery Beat 每分钟调度的
check_and_send_escalations任务，请确保平台定时任务正常运行。
5.7 全局配置与操作日志
5.7.1 全局配置
系统级配置项用于控制告警中心的全局行为，包括：
- 兜底分派通知配置
- 告警丰富功能开关
- 自动关闭策略参数
5.7.2 操作日志
操作日志记录关键变更与处置动作，是平台治理和审计的重要组成部分：
- 日志类型：事件、告警、事故、系统
- 操作类型：新增、修改、删除、执行
- 记录内容：操作人、操作对象、变更前后值、操作时间
界面指引：
- 图表解读/配置逻辑：全局配置体现平台处理策略的一致性，操作日志体现治理动作的透明度。两者结合，让告警中心从"能用"走向"可治理"。
