告警中心功能介绍文档
|
1
|
产品介绍-v6.13,告警中心

一、产品概述

告警中心承接来自监控、日志、CI/CD、云厂商及第三方工具的多源事件，把它们标准化、聚合降噪成可处理的告警，并贯穿”分派 → 处置 → 恢复 → 事故协同”的完整生命周期。它把告警治理串成一条线：接事件 → 收敛降噪 → 分派处置 → 恢复闭环 → 事故协同。

主要功能入口：

  • 集成（Integration）：管理告警源与查看原始事件。
  • 告警（Alarms）：处理告警（分派 / 认领 / 转派 / 关闭 / 升级事故）。
  • 事故（Incidents）：多告警关联的跨团队协同处置。
  • 配置（Settings）：相关性规则（降噪 / 缺失检测）、告警丰富规则、告警处理规则、告警分派、屏蔽策略、系统设置、操作日志。

边界说明： 告警中心只做事件收敛与处置；指标采集、日志采集分别由 监控系统、日志系统 负责；通知渠道由 系统管理 维护；站内通知可在 控制台 的通知中心查看。

二、核心概念与术语

概念 说明
Event / Alert / Incident 三层模型：原始事件 → 聚合后的可处理告警 → 升级形成的事故
告警源 一个外部事件来源的接入配置，带独立鉴权密钥（SECRET）
字段映射 把上游字段映射到平台标准事件字段（event_fields_mapping）
相关性规则 统一的告警策略入口，分智能降噪与缺失检测两类
匹配规则 定义”哪些事件进入本策略”，结构为外层 OR、内层 AND
聚合维度（group_by） 决定”按什么把事件归并成一条告警”（如 service、resource_name）
检测窗口 / 自愈观察时间 收集事件归并的时间窗 / 先观察、抖动恢复则不正式告警
告警状态机 unassigned → pending → processing → resolved / closed，另有 auto_recovery / auto_close；unassigned / pending / processing 均为活跃态，进入活跃态就会触发自动分派和通知
告警丰富规则 在告警上声明式补齐”上下文信息”，如把告警关联的 CMDB 实例、负责人、所属业务系统填到告警字段上，便于快速判断影响范围
组织（团队） 数据与权限的归属单元。事件、告警、事故均按组织裁剪可见范围。由 系统管理 维护
事故协作群 为事故创建即时沟通群，并维护成员和消息；依赖 系统管理 中已启用且测试通过的企业微信即时消息能力

常见技术名词速查（在后文看到不懂的词，回这里查）：

名词 通俗解释
SECRET 告警源的接入密钥，上游推事件时放在请求头 SECRET 里鉴权
external_id 事件的”身份证”。恢复事件必须与创建事件用同一个 external_id，才能自动恢复对应告警
action 事件动作：created（产生）/ recovery（恢复）/ closed（关闭）
REST / NATS 两种事件接入通道：HTTP 推送 / 经 NATS 消息总线推送
专属 webhook 某告警源独立的接入地址 /api/source/{source_id}/webhook/（Prometheus、Zabbix 等用）
指纹（fingerprint） 按聚合维度算出的归并键，相同指纹的事件收敛为一条告警
Cron 表达式 定义”预期事件应何时到达”的时间规律（缺失检测用），如 0 2 * * *

原理提示： 告警中心不主动采集，而是等上游把事件推过来。因此接入任何来源前，需先在「集成」建好告警源并拿到 SECRET；恢复闭环依赖创建/恢复事件用同一个 external_id；要发通知还需 系统管理 配好通知渠道。

三、支持的告警源与接入方式

平台内置 8 类告警源类型（其中 6 个内置 source_id 可直接选用，其余两类需经授权或由上游按通用通道推送），也支持自建。两条接入通道：① 通用接收地址 POST /alerts/api/receiver_data（请求体带 source_id）；② 告警源专属 webhook /alerts/api/source/{source_id}/webhook。两者统一用请求头 SECRET 鉴权。

告警源 source_id 接入通道 上游需准备
RESTful restful 通用接收地址 按事件格式推送
NATS nats NATS 网关 发布到平台 NATS 通道
Prometheus prometheus 专属 webhook Alertmanager 配 webhook，send_resolved=true
Zabbix zabbix 专属 webhook Webhook Media Type 脚本，ProblemId 作恢复主键
K8s k8s 通用接收地址 部署 kubernetes-event-exporter
SNMP Trap snmp_trap 专属 webhook 独立 SNMP Trap bridge 转发
云监控 cloud 自建 cloud 通用接收地址 把云厂商告警（阿里云、腾讯云、华为云等）按事件格式转发到平台；当前作为独立 source 类型
日志 log 自建 log 通用接收地址 由 日志系统 把命中策略的日志告警转发到平台；当前作为独立 source 类型

真实接入地址、密钥与可复制示例以产品「集成 → 告警源」详情页（集成引导）为准。各源详细接入步骤另见《告警源接入配置指引》。

四、通用流程

  1. 配告警源： 集成 → 告警源 → 新建，选接入类型、配字段映射，拿到 SECRET。
  2. 上游推事件： 上游按 REST / NATS / 专属 webhook 推送事件（带 SECRET）。
  3. 配相关性规则： 配置 → 相关性规则，选智能降噪（收敛重复）或缺失检测（该来没来也报警）。
  4. 验证： 集成 → 事件 看事件入站；告警 看是否生成告警、聚合是否符合预期。
  5. 配分派： 配置 → 告警分派，让告警自动分派给指定用户或组织并通知。
  6. （按需）升级事故： 告警 → 选告警 → 升级为事故，进入跨团队协同。

跨时区通知： 6.11 起，告警通知中的时间会按接收人的个人时区格式化。跨地区值班团队应在 系统管理 核对个人时区；同一告警发给不同地区人员时，显示时间可能不同，但指向同一事件时刻。

事故协作： 若已开通企业微信集成，可在事故中创建或关联协作群。创建前先确认系统管理中的企业微信即时消息能力已启用、参与者已同步为企业内部成员。群创建、加人或发消息失败时，优先检查集成连接、企业可信网络和成员映射，不要反复创建重复群。

关联对象删除： 6.11 起，删除已关联的监控实例时会同步关闭相关活跃告警。删除前仍应先核对影响范围；告警关闭不等于历史记录被删除。

关于恢复闭环（务必记住）： 恢复事件的 external_id 必须与创建事件完全一致，action 为 recovery，且恢复时间晚于创建时间，才能触发自动恢复。Prometheus 需保持 alertname+instance 稳定并开 send_resolved；Zabbix 需保持 ProblemId 一致。

关于匹配规则： 结构是”外层 OR、内层 AND”——同一组内条件全满足才命中该组，任意一组命中即进入策略。

五、新手第一课：5 分钟产生并恢复第一条告警

第一次使用，建议用内置 RESTful 告警源推一条事件，走通”事件入站 → 生成告警 → 自动恢复”。

第 0 步：确认权限与告警源。 你有告警中心操作权限；进入 集成 → 告警源，确认有可用的 restful 源，进详情复制其 SECRET。

第 1 步：推一条创建事件。 用 cURL（把域名与 SECRET 换成你的）：

curl -X POST 'https://<域名>/api/proxy/alerts/api/receiver_data/' \
  -H 'Content-Type: application/json' -H 'SECRET: <你的SECRET>' \
  -d '{"source_id":"restful","events":[{"title":"主机内存过高","action":"created","external_id":"demo-001","level":"1","start_time":"1742812800","resource_id":"host-1","resource_name":"10.0.0.1","resource_type":"host"}]}'

第 2 步：看事件入站。 进入 集成 → 事件，确认刚推的事件已进来、字段解析正确。

第 3 步：看告警生成。 进入 告警，确认生成了对应告警（标题 / 级别 / 来源符合预期）。

第 4 步：推恢复事件，看自动恢复。 再推一条 action:"recovery"、external_id 相同（demo-001）、时间更晚的事件；回到告警列表，该告警应变为”自动恢复”。

若没结果，按顺序排查： ① SECRET 是否正确（否则 403）；② title 是否缺失（缺失会被丢弃）；③ 恢复没生效——检查 external_id 是否与创建事件一致、action 是否为 recovery、恢复时间是否更晚；④ 事件进来却没告警——可能命中了屏蔽策略。

下一步： 想把重复事件收敛成一条，去 配置 → 相关性规则 配智能降噪；想让告警自动找人，去 配置 → 告警分派。

六、产品介绍

一、产品简介

WeOpsX 告警中心是面向轻量级运维场景打造的统一事件收敛与智能处置平台。它承接来自监控系统、日志平台、CI/CD 流水线、云厂商及第三方工具的多源事件输入，通过智能聚合引擎将分散、重复、上下文不足的原始事件转化为可分派、可协同、可审计的标准化告警与事故对象。

与传统”只发通知”的告警工具不同，WeOpsX 告警中心聚焦于告警从产生到关闭的完整生命周期管理。平台内置智能降噪引擎，基于多维度和多种时间窗口策略，将海量重复事件聚合成高价值的可处理单元；围绕分派、认领、转派、关闭、自动恢复、自动关闭构建标准化处置路径，确保每一条告警都能进入责任闭环；当问题升级为业务影响级故障时，支持一键升级为 事故 进行跨团队协同处置。

无论是值班运维人员的日常告警处理、团队负责人的治理策略优化，还是平台管理员的接入标准化建设，WeOpsX 告警中心都提供了专业、轻量且可持续演进的解决方案。

界面指引：

告警列表

  • 图表解读/配置逻辑：告警中心不仅是消息列表，更是统一的处置工作台。通过「级别、状态、来源、我的告警」等多维筛选，值班人员可快速定位关键问题；列表直接支持「认领、转派、关闭、升级事故」等操作，实现”发现问题 → 明确责任 → 持续跟进”的闭环处理。

二、核心优势

2.1 多源事件统一接入与标准化

平台提供 REST API 与 NATS 消息通道 双接入能力，通过可扩展的告警源适配器架构对接Prometheus、Zabbix、云监控、Webhook 等异构数据源。内置字段映射机制支持将不同来源的数据标准化为统一的事件模型，同时提供 CMDB 信息自动丰富能力，为后续聚合、分派和恢复判断奠定数据基础。

2.2 智能聚合降噪引擎

基于 DuckDB 高性能分析引擎构建的聚合处理器，支持滑动窗口、固定窗口、会话窗口三种时间窗口策略，结合多维度聚合等配置，自动计算事件指纹实现精准去重。

2.3 从通知到处置的责任闭环

平台内置完整的告警状态机（unassigned → pending → processing → resolved/closed），支持手动分派、自动分派、认领、转派等多种责任流转方式。自动分派策略支持按告警字段匹配、生效时间控制（单次/每日/每周/每月），并与通知渠道联动，确保问题第一时间触达责任人。

2.4 自动恢复与兜底关闭机制

智能关联恢复事件与历史告警，当恢复事件覆盖创建事件时自动触发 自动恢复 状态流转。同时支持基于策略的自动关闭与定时兜底任务，有效清理长期悬挂的”僵尸告警”，保持告警池健康度。

2.5 会话窗口与观察期机制

针对抖动型异常场景，平台创新性地引入会话窗口（Session Window）与观察期（Observing）机制。告警首先进入观察期，如果在超时时间内未恢复才转为正式告警，有效过滤瞬时抖动，减少误报对值班人员的干扰。

2.6 缺失检测与心跳监控

除传统的”事件触发告警”模式外，平台支持缺失检测策略。通过 Cron 表达式配置预期心跳到达时间，当关键任务、定时作业未按时上报时自动触发告警，实现”该来的没来也知道”的守护能力。

2.7 从事故到复盘的全链路审计

告警操作、策略调整、系统设置变更全程记录操作日志；配合通知结果追踪、告警趋势统计，支持团队在事后回答”谁处理了什么问题””策略如何变更””为什么没有及时响应”等关键治理问题。

三、核心能力全景

3.1 统一的事件治理入口

WeOpsX 告警中心采用 Event → Alert → Incident 三层模型组织事件治理流程：

层级 定位 核心能力
Event 原始事件 多源接入、字段标准化、屏蔽过滤、恢复关联
Alert 可处理单元 智能聚合、状态流转、责任分派、自动恢复
Incident 事故协同 多告警关联、跨团队协作、升级管理

这种分层设计既避免了原始事件直接暴露带来的噪声问题，又为重大故障提供了清晰的升级路径。

3.2 高性能聚合引擎

聚合处理器（AggregationProcessor）是告警中心的核心大脑：

  • 策略驱动执行：支持智能降噪（Smart Denoise）与缺失检测（Missing Detection）两种策略类型
  • DuckDB 内存计算：事件批量加载至内存进行聚合分析，大幅提升处理性能
  • 并发安全保证：通过数据库行级锁与事件缓存机制，确保多进程场景下的聚合准确性

界面指引：

微信图片_20260326195309_16_154.png

3.3 智能分派与通知体系

  • 多级匹配策略：支持「全部匹配」与「条件过滤」两种模式，条件过滤支持多种操作符
  • 用户或组织接收：分派目标可选择具体用户，也可选择一个或多个组织；选择组织时可按需包含下级组织，适合按值班团队或业务组织统一接收
  • 灵活生效时间：支持单次、每日、每周、每月四种时间范围配置，适配不同值班排班
  • 分级提醒机制：可根据告警级别配置不同的提醒频率（如致命级别每 30 分钟提醒一次，最多提醒 10 次）
  • 兜底分派保障：未命中任何分派策略的告警进入兜底队列，按全局配置周期性通知管理员

界面指引：

告警分派

  • 图表解读/配置逻辑：分派策略的核心是定义”什么类型的问题在什么时间自动交给谁”。合理配置分派规则可显著减少人工判断与转派开销，提升 MTTR（平均修复时间）。

3.4 面向处理流程的告警工作台

  • 多维筛选：支持按级别、状态、来源、时间范围、”我的告警”等维度快速定位
  • 批量操作：支持批量分派、认领、关闭，提升高频操作效率
  • 上下文追溯：告警详情页可查看关联事件列表、操作记录、通知状态，辅助判断聚合效果与处置历史
  • 一键升级：高影响告警可一键升级为 Incident，进入更高等级的协同流程

3.5 灵活的屏蔽策略

  • 前置降噪：命中屏蔽策略的事件在入库后即标记为 SHIELD 状态，不进入后续告警链路
  • 全链路生效： 屏蔽不仅在事件入库后、聚合主路径上生效，也对”即时旁路”（事件触发即时通知 / 自动化动作）生效；命中屏蔽的事件不会触发任何下游通知或自动化动作
  • 多维度匹配：支持按来源、资源、标题、内容等字段配置匹配条件
  • 时间范围控制：支持维护窗口、周期性操作等场景的临时屏蔽

界面指引：

屏蔽策略

  • 图表解读/配置逻辑：屏蔽策略适合治理”明知无须处理”的事件，如计划内维护、重复性低价值通知。建议谨慎使用，避免过度屏蔽导致真正的问题被遗漏。

3.6 可观测的治理体系

  • 操作日志审计：告警处置、策略变更、系统设置调整全程留痕，支持按时间、类型、操作人筛选
  • 通知结果追踪：每条通知的发送结果与状态持久化存储，便于排查通知链路问题
  • 趋势统计分析：支持按分钟/小时/日/周/月多粒度统计告警趋势，辅助治理决策

四、典型应用场景

4.1 基础设施异常的统一收敛

在主机、数据库、中间件等基础设施监控场景中，同一资源异常往往触发多条指标告警（CPU、内存、磁盘、连接数等）。WeOpsX 告警中心通过配置资源维度（resource_id、resource_type）作为 group_by 字段，将同一对象的多个指标异常聚合成单条告警，帮助运维人员识别”同一个问题”的真实影响，避免被重复事件淹没。

4.2 抖动场景的观察期过滤

网络延迟、服务瞬时过载等场景下，异常可能快速出现又自动恢复。通过配置会话窗口（Session Window）与观察期机制，平台将短时间内恢复的事件拦截在观察期，只有持续超时未恢复的问题才转为正式告警，显著降低误报率。

4.3 关键任务的缺失守护

对于定时备份、数据同步、报表生成等关键批处理任务，传统监控只能在任务失败时告警。通过缺失检测策略，平台可配置 Cron 表达式预期任务上报时间，当”该来的没来”时自动触发告警，守护业务连续性。

4.4 流水线失败的持续跟踪

CI/CD 流水线构建失败、镜像推送异常等事件，往往在短时间内重复触发。通过时间窗口聚合，平台将同一流水线的多次失败收敛为单条告警，便于研发团队持续跟踪问题根因而非重复接收相似通知。

4.5 重大故障的事故化协同

当告警涉及业务中断、核心链路异常或需要多角色协同处置时，值班人员可将告警升级为 Incident。Incident 支持关联多条告警、记录协同处理过程、追踪事故状态，让重大问题从”个人处理”转向”团队响应”。

4.6 合规审计与治理优化

在重视运维合规与持续改进的团队中，平台提供的操作日志、通知状态与趋势统计能力，帮助管理者回答：
* 告警响应是否及时？（分派 → 认领时长统计）
* 策略配置是否合理？（屏蔽命中率、分派成功率）
* 团队 workload 分布如何？（人均告警处理量）

五、为什么选择 WeOpsX 告警中心

5.1 轻量而完整的设计理念

不同于需要大规模投入的重型告警平台，WeOpsX 告警中心以”轻量建设、完整闭环”为核心理念。它用相对轻量的资源投入，将事件接入、聚合降噪、责任分派、自动恢复、事故升级和审计留痕串成一条完整链路，让中小团队也能快速构建企业级的告警治理能力。

5.2 技术架构的先进性

  • DuckDB 内存分析引擎：聚合性能较传统数据库方案提升数倍
  • 异步任务解耦：告警分派、通知发送采用 Celery 异步化，不阻塞主流程
  • 并发安全设计：行级锁、指纹缓存、批量操作等机制确保高并发场景下的数据一致性
  • 可扩展适配器架构：新增告警源只需实现标准 Adapter 接口，无需改动核心代码

5.3 从”能告警”到”治好告警”

WeOpsX 告警中心不仅关注”能不能发出一条消息”，更关注告警治理体系的持续优化：
* 通过聚合降噪减少噪声，提升信噪比
* 通过自动分派缩短响应时间，提升 MTTR
* 通过自动恢复与兜底关闭保持告警池健康
* 通过审计日志支撑复盘与改进

对于希望在成本、效率与治理能力之间取得平衡的企业，WeOpsX 告警中心不是又一个”通知推送工具”，而是一套能够持续提升运维响应质量的完整解决方案。

七、功能介绍

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） 检测预期事件未按时到达 定时任务、心跳监控
5.1.2 窗口类型
窗口类型 说明 适用场景
滑动窗口（Sliding） 连续时间段，窗口间允许重叠 持续异常监测
固定窗口（Fixed） 固定时间片，如每分钟/每小时 周期性统计
会话窗口（Session） 基于事件间隔识别问题持续性 抖动过滤、超时检测
5.1.3 核心能力
  • 灵活匹配规则：支持多组条件组合（外层 OR、内层 AND），可按来源、级别、资源、标签等维度过滤
  • 多维分组聚合：通过 group_by 定义聚合维度（如 resource_id、service），相同维度的事件聚合为单条告警
  • 指纹算法去重：基于 MD5 哈希计算事件指纹，确保同一问题只产生一条活跃告警
  • 会话观察期：会话窗口策略支持观察期机制，观察期内恢复的事件不转为正式告警
  • 自动关闭配置：支持为规则生成的告警设置自动关闭时间，控制长期悬挂问题
  • 异步分派调度：新告警通过 Celery 异步任务执行自动分派，不阻塞聚合流程

界面指引：

微信图片_20260326195309_16_154.png

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 Rule）

告警丰富规则用于在告警上声明式补齐上下文信息（如关联的 CMDB 实例、负责人、所属业务系统），让值班人员一眼看清”这是哪台机器、归谁管、影响哪个业务”，降低人工查证成本。

5.5.1 核心能力
  • 声明式 Lookup： 通过 provider_type / input_binding / output_projection / preset_key 四元组声明”用什么数据源、按哪些字段查、返回哪些字段、以哪个 preset 写入告警”
  • 接入入口： 路径 配置 → 告警丰富规则
  • 效果可观测： 系统提供 metrics 接口返回总规则数 / 启用占比 / 自建规则数 / 已丰富告警占比，便于治理评估
  • 与原有”CMDB 信息丰富”一致： 早期在事件层提供的 CMDB 关联能力，已统一收敛到告警丰富规则体系；如果你之前的自定义丰富逻辑不可见，迁移到此入口查看

注意：

启用告警丰富规则前，请确认 CMDB 等被查询系统已具备相应数据；查不到时会按”未丰富”处理，不会阻塞告警生成。

5.6 告警处理规则（Action Rule）

告警处理规则定义”告警在满足什么条件时，自动触发什么动作”，是告警从”通知到人”升级为”自动化处置”的关键能力。

5.6.1 核心能力
  • 动作类型： 当前已 GA 的动作为 job（调用 作业管理 的脚本 / Playbook）；ITSM、Webhook 在前端界面仍处于禁用态，正式开放以产品内配置项为准
  • 执行方式： 异步执行；执行结果经 HMAC-SHA256 签名 回调异步回写到告警
  • 执行记录： 在告警详情可查看每次触发的执行记录与回写状态，便于审计与排障

如何选型：

  • 想”告警触发后自动改 CMDB 字段 / 自动派单”等更复杂流程，建议通过 作业管理 的脚本 / Playbook 落地，并在处理规则里调用；如需条件分支或自然语言理解，建议通过智能运维助手的 ChatFlow 编排。

5.7 全局配置与操作日志

5.7.1 全局配置

系统级配置项用于控制告警中心的全局行为，包括：
* 兜底分派通知配置
* 告警丰富功能开关
* 自动关闭策略参数

5.7.2 操作日志

操作日志记录关键变更与处置动作，是平台治理和审计的重要组成部分：

  • 日志类型：事件、告警、事故、系统
  • 操作类型：新增、修改、删除、执行
  • 记录内容：操作人、操作对象、变更前后值、操作时间

界面指引：

全局配置

  • 图表解读/配置逻辑：全局配置体现平台处理策略的一致性，操作日志体现治理动作的透明度。两者结合，让告警中心从”能用”走向”可治理”。

八、操作指引（快速入门）

一、前置条件

在开始使用告警中心前，建议先确认以下准备项已经完成：

  • 已具备可访问 WeOpsX 平台的账号，并拥有告警中心相关模块的查看与配置权限。
  • 已创建可用的告警源（路径：告警中心 → 集成 → 告警源），并获取对应的接入密钥（SECRET）。
  • 已明确需要接入的事件字段。为保证聚合、分派和恢复判断的准确性，建议每条事件至少包含：
    • title：事件标题（必填，缺失会导致事件被丢弃）
    • action：事件动作（created/recovery/closed，强烈建议）
    • level：事件级别（建议）
    • start_time：事件开始时间（建议）
    • resource_id/resource_name：资源标识（建议）
    • resource_type：资源类型（建议）
  • 已明确本次希望验证的场景，例如基础设施异常聚合、流水线失败跟踪或定时任务缺失检测。

注意：
告警中心的效果高度依赖事件字段质量,若缺少资源标识，聚合维度将受限，可能产生大量重复告警。

二、第一步：配置告警源与字段映射

接入前置条件

  • 接入通道： RESTful / K8s 走通用接收地址；Prometheus / Zabbix / SNMP Trap 走专属 webhook；NATS 走消息通道。统一用请求头 SECRET 鉴权。
  • 告警源准备： 在「集成 → 告警源」建好源并取得 SECRET；建议每个上游实例用独立 source_id + 独立 SECRET。
  • 上游侧准备： 事件 title 必填、external_id 用于恢复闭环；Prometheus 需 send_resolved=true、Zabbix 需 ProblemId 一致。要发通知，先在 系统管理 配好通知渠道。真实地址 / 密钥 / 示例以告警源详情页为准。

路径：告警中心 → 集成 → 告警源 → 新建

2.1 创建告警源

  1. 填写告警源名称与描述
  2. 选择接入类型（RESTful、Prometheus、Zabbix 等）
  3. 配置字段映射（event_fields_mapping）：将上游系统字段映射到标准事件字段

默认字段映射示例：

{
  "title": "title",
  "description": "description",
  "level": "level",
  "start_time": "start_time",
  "end_time": "end_time",
  "external_id": "external_id",
  "item": "item",
  "resource_id": "resource_id",
  "resource_name": "resource_name",
  "resource_type": "resource_type",
  "service": "service",
  "location": "location"
}

2.2 获取接入密钥

创建完成后，进入告警源详情页，复制生成的 SECRET 密钥，用于后续事件推送的鉴权。

界面指引：

告警源

  • 图表解读/配置逻辑：告警源详情页展示接入指南、鉴权参数和最近事件。若接入后没有看到预期告警，应先在此确认事件是否已成功接收。

三、第二步：定义相关性规则

路径：告警中心 → 配置 → 相关性规则 → 新建

当前版本的相关性规则本质上是统一的告警策略配置入口，策略类型分为 智能降噪 与 缺失检测 两类。它决定事件进入平台后如何被筛选、聚合，以及在什么条件下生成告警。

3.1 先选择策略类型

策略类型 适用场景 当前核心配置
智能降噪 常规监控事件收敛、重复事件合并、抖动场景降噪 事件范围、聚合维度、检测窗口、自愈观察时间、自动关闭
缺失检测 定时任务、心跳上报、周期事件未按时到达 监听目标、Cron 检查周期、宽限期、激活方式、自动恢复、告警模板

建议按下面的原则选择：

  • 已有事件持续上送，但希望把重复异常收敛为一条告警：选择 智能降噪。
  • 预期应该定时收到某类事件，但“该来的没来”也要报警：选择 缺失检测。

无论选择哪种策略，匹配规则 都用于定义“哪些事件会进入当前策略”。其结构是“外层 OR、内层 AND”：

  • 同一组中的多个条件同时满足，才命中该组。
  • 任意一组命中，事件就会进入当前策略。

例如可以配置为：

  • 第一组：source_id = prometheus 且 resource_type = host
  • 第二组：service = core-api

这样最终匹配逻辑就是：(A 且 B) 或 C。

3.2 智能降噪如何配置

智能降噪用于把重复、相近或短时间内连续出现的事件聚合成更少、更可处理的告警。当前版本不再按“滑动窗口 / 固定窗口 / 会话窗口”分别配置，而是通过以下参数组合来完成降噪：

  1. 定义事件范围
    * 可选择对全部事件生效，或通过匹配规则只处理特定来源、级别、资源类型、服务等事件。
  2. 选择聚合策略
    * 页面提供“应用优先 / 基础设施优先 / 实例优先 / 自定义”几种方式，本质上都是预设不同的聚合维度顺序。
  3. 设置聚合维度
    * 当前主要围绕 service、location、resource_name、item 这些字段组合聚合。
    * 如果希望“同一服务下的同类异常尽量合并”，优先保留 service。
    * 如果希望“按实例拆分，不同实例各自产生告警”，优先保留 resource_name。
  4. 设置检测窗口
    * 系统会在配置的时间窗口内收集事件，再按聚合维度归并生成告警。
    * 窗口越短，告警生成越及时；窗口越长，聚合效果越强。
  5. 按需开启自愈观察时间
    * 开启后，系统会先将告警放入观察阶段；如果异常在观察时间内恢复，可减少短抖动造成的正式告警。
  6. 按需开启自动关闭
    * 对于无需长期保留的告警，可设置自动关闭分钟数，避免告警池长期堆积。

对于大多数首次接入场景，推荐先用下面这组思路验证：

  • 事件范围：先按告警源或服务做过滤，避免一开始把所有事件都纳入。
  • 聚合维度：优先从 service + resource_name 开始。
  • 检测窗口：先用 5 分钟左右的小窗口观察效果。
  • 观察时间：仅在明显存在抖动告警时再开启。

3.3 缺失检测如何配置

缺失检测不是看“事件来了没有多”，而是看“预期应该来的事件有没有按时到达”。当前实现已经切换为 Cron + 宽限期 的模式，旧版固定间隔配置已经废弃。

配置时建议按下面的顺序操作：

  1. 明确监听目标
    * 缺失检测必须配置匹配规则，不支持“全部事件”监听。
    * 通常按 service、source_id、resource_type、resource_id 等字段圈定心跳或任务事件。
  2. 设置检查周期
    * 当前仅支持 Cron 表达式。
    * 例如：0 2 * * * 表示每天凌晨 2 点检查一次。
  3. 设置宽限期
    * 当到达预期时间后，系统会再等待一段宽限时间；超过宽限期仍未收到事件，才触发缺失告警。
  4. 设置激活方式
    * 首条心跳激活：先收到第一条符合条件的事件，再进入监控状态，适合避免策略刚创建时立刻误报。
    * 立即激活：策略保存后立即开始监控，适合确定任务已在稳定运行的场景。
  5. 设置恢复方式与告警模板
    * 可开启自动恢复。缺失告警生成后，后续一旦再次收到符合条件的事件，系统会自动恢复该告警。
    * 告警模板中的标题、级别、描述为必填项，用于定义缺失告警最终展示内容。

需要注意的是，heartbeat_status、last_heartbeat_time、last_heartbeat_context 这类运行态字段由系统维护，不需要在配置阶段手工处理。

界面指引：

微信图片_20260326195309_16_154.png

  • 图表解读/配置逻辑：相关性规则页本质上是告警策略配置入口。保存后，规则会由后台周期聚合任务自动生效；如果聚合效果不符合预期，应优先回看匹配规则、聚合维度、检测窗口或 Cron 与宽限期配置是否合理。

四、第三步：推送事件到告警中心

4.1 创建事件推送示例

使用 REST API 推送创建事件：

curl -X POST 'https://<your-domain>/api/proxy/alerts/api/receiver_data/' \
  -H 'Content-Type: application/json' \
  -H 'SECRET: <your-secret-key>' \
  -d '{
    "source_id": "restful",
    "events": [
      {
        "title": "主机 10.10.24.62 内存使用率过高",
        "description": "主机 10.10.24.62 内存使用率持续超过阈值 90%",
        "action": "created",
        "external_id": "host-10.10.24.62-mem-usage",
        "level": "1",
        "start_time": "1742812800",
        "item": "mem_usage",
        "resource_id": "host-10.10.24.62",
        "resource_name": "10.10.24.62",
        "resource_type": "host",
        "service": "core-api",
        "labels": {
          "cluster": "prod-beijing",
          "team": "platform"
        }
      }
    ]
  }'

4.2 恢复事件推送示例

当问题恢复时，推送恢复事件以触发自动恢复：

curl -X POST 'https://<your-domain>/api/proxy/alerts/api/receiver_data/' \
  -H 'Content-Type: application/json' \
  -H 'SECRET: <your-secret-key>' \
  -d '{
    "source_id": "restful",
    "events": [
      {
        "title": "主机 10.10.24.62 内存使用率恢复正常",
        "description": "主机 10.10.24.62 内存使用率已降至阈值以下",
        "action": "recovery",
        "external_id": "host-10.10.24.62-mem-usage",
        "level": "1",
        "start_time": "1742816400",
        "item": "mem_usage",
        "resource_id": "host-10.10.24.62",
        "resource_name": "10.10.24.62",
        "resource_type": "host"
      }
    ]
  }'

关键要点：
* 恢复事件的 external_id 必须与创建事件保持一致
* action 字段必须为 recovery 或 closed
* 恢复时间（start_time）必须晚于创建事件时间，才能触发自动恢复

五、第四步：验证事件与告警

5.1 验证事件入站

路径：告警中心 → 集成 → 事件

完成推送后，先进入事件页面核验原始事件是否已成功进入平台：

  • 事件是否来自预期的告警源
  • level、resource_name 等字段是否正确解析
  • 时间戳是否合理（避免因时区问题导致时间异常）

5.2 验证告警生成

路径：告警中心 → 告警

当事件命中规则并满足窗口条件后，平台会生成对应告警：

  • 告警标题、级别、来源是否符合预期
  • 告警详情中是否能看到关联事件列表
  • 相同 group_by 维度的事件是否被正确聚合到同一告警
  • 会话窗口策略的告警是否正确进入”观察中”状态

界面指引：

告警列表

  • 图表解读/配置逻辑：告警详情页展示关联事件、操作记录、通知状态。若发现聚合效果不符合预期，应返回检查相关性规则的分组字段与窗口配置。

六、第五步：配置自动分派策略

路径：告警中心 → 配置 → 告警分派 → 新建

6.1 基础配置

  1. 分派名称与启用状态：设置策略名称，确保「启用」开关打开
  2. 生效时间：选择时间范围类型（单次/每日/每周/每月）
  3. 匹配类型：
    • 选择「全部匹配」：该时间段内所有未分派告警都会命中
    • 选择「条件过滤」：配置具体的匹配规则

6.2 条件过滤配置示例

[
  [
    {
      "key": "level",
      "operator": "eq",
      "value": "1"
    },
    {
      "key": "resource_type",
      "operator": "eq",
      "value": "host"
    }
  ],
  [
    {
      "key": "source_name",
      "operator": "contains",
      "value": "zabbix"
    }
  ]
]

上述规则表示：匹配（级别为致命 且 资源类型为主机）或（来源名称包含 zabbix）的告警。

6.3 分派人员与通知

  • 分派人员：选择责任人（支持多选）
  • 通知渠道：选择通知方式（企业微信、邮件等）
  • 提醒配置：设置未响应时的提醒频率（如致命级别每 30 分钟提醒一次）

配置完成后，新产生的告警将自动按策略分派，减少人工判断与转派开销。

界面指引：

告警分派

  • 图表解读/配置逻辑：分派策略按创建时间排序，优先级由前到后。建议将更精细的匹配规则放在前面，通用的兜底规则放在后面。

七、第六步：配置缺失检测策略（可选）

对于定时任务、心跳监控等场景，可配置缺失检测策略。

7.1 策略配置步骤

路径：告警中心 → 配置 → 相关性规则 → 新建

  1. 策略类型：选择”缺失检测”
  2. 匹配规则：配置预期到达的事件特征（如 service=daily-backup）
  3. Cron 表达式：定义预期到达的时间规律，如 0 2 * * *（每天凌晨 2 点）
  4. 激活模式：
    • 「首条心跳激活」：收到第一条匹配事件后开始监控
    • 「立即激活」：策略创建后立即开始监控
  5. 宽限期：设置在预期时间后延迟多久未收到事件才触发告警（分钟）
  6. 自动恢复：勾选后，缺失告警产生后若收到匹配事件，自动恢复

7.2 工作原理

  1. 策略进入监控状态后，平台按 Cron 表达式计算预期到达时间
  2. 若预期时间 + 宽限期后仍未收到匹配事件，触发缺失告警
  3. 缺失告警产生后，若后续收到符合规则的事件，自动恢复该告警

注意：
缺失检测依赖 Celery 定时任务调度，请确保平台定时任务正常运行。

八、第七步：将重大问题升级为事故

当某条告警已具备明显业务影响，或需要多个角色共同处理时，可将其升级为 Incident。

8.1 升级操作

路径：告警中心 → 告警 → 选择告警 → 升级为事故

  1. 在告警列表选择目标告警
  2. 点击「升级为事故」按钮
  3. 填写事故标题、级别、参与人员等信息
  4. 确认创建

8.2 事故处理

事故创建完成后，可前往事故页面查看：

  • 事故详情与状态跟踪
  • 关联告警列表与处理进展
  • 甘特图时间线展示事故生命周期
  • 支持事故的认领、关闭、重开等操作

界面指引：

事故列表

  • 图表解读/配置逻辑：事故页面用于统一跟踪已升级的问题。相比告警列表，更强调协同视角与跨团队沟通。

九、结果验证与闭环建议

完成以上步骤后，建议按以下方式验证接入是否形成完整闭环：

验证项 验证位置 预期结果
原始事件入站 事件页面 能看到推送的事件，字段解析正确
事件聚合效果 告警详情 → 关联事件 相同维度的事件聚合到同一告警
自动分派生效 告警详情 → 操作记录 能看到自动分派记录，责任人正确
通知触达 告警详情 → 通知状态 通知发送成功
自动恢复 告警状态 推送恢复事件后，告警变为”自动恢复”
升级事故 事故页面 能查看关联告警与处理进展

持续优化建议

  • 优化聚合规则：根据实际聚合效果调整 group_by 字段，避免过度聚合或聚合不足
  • 完善分派策略：为高频问题场景补充更精细的分派规则，减少兜底分派比例
  • 调整屏蔽策略：为维护窗口或已知低价值事件配置屏蔽策略，但避免过度屏蔽
  • 优化提醒频率：根据实际处置时长调整各等级的提醒频率与最大提醒次数
  • 定期复盘：结合操作日志与趋势统计，定期复盘告警治理效果
暂无评论

发送评论 编辑评论 


				

			

						

				

					

						

							

								
							

							
						

					

				

				

					

						

							

								
							

							
						

					

				

				

					

						

							

								
							

							
							
													

					

				

			

			
			

				

					
				

			

				

											

							
							
						

																				
					
									

			

			
			
		

	






上一篇
下一篇 

					
				

			

		

		
						
					
		
	







  

  
正在准备导出…