← 返回 BeeX 文档中心

BeeX 告警中心方案

统一接收 CloudMonitor、Uptime Kuma、业务服务和 AI Ops Worker 告警;入库、去重、分级、统计后按规则转发飞书。

Owner: ai-ops-worker 状态: 已接入代码 更新: 2026-07-22 范围: ID test / ID prod / MY later

1. 目标

方案
告警入口统一进入 ai-ops-worker Alert Ingest API。
事实源以 BeeX 告警中心数据库为准。
通知按等级、冷却、静默规则转发飞书。
后台admin.beexofficial.com 提供告警列表、详情、认领、关闭、静默和统计。
当前已实现:ai-ops-worker 告警表、接入 API、去重、飞书转发记录;管理后台服务代理 API;管理后台前端“告警中心”页面。

2. 总体架构

flowchart LR CM["阿里云 CloudMonitor
ECS / RDS / Redis"] --> ING["ai-ops-worker
Alert Ingest API"] UK["Uptime Kuma
公网可用性 / SSL"] --> ING BS["BeeX 业务服务
订单 / WhatsApp / Xendit / Push"] --> ING AW["AI Ops Worker 自检
Git / 任务 / 反馈分析"] --> ING ING --> NORM["标准化
source / level / target / fingerprint"] NORM --> DB[("ai_ops_worker
alerts / events / notifications")] DB --> RULE["路由规则
P0/P1/P2 / 静默 / 去重"] RULE --> FS["飞书告警群"] DB --> ADMIN["admin.beexofficial.com
告警中心页面"]
扩展短信、电话、邮件时,只新增通知 channel。

3. 监控范围

层级监控项告警来源典型等级
机器层ECS 状态、Agent 心跳、CPU、内存、磁盘、Load、带宽、端口CloudMonitorP0 / P1
云资源层RDS CPU、连接数、存储、慢 SQL;Redis 内存、连接、延迟、淘汰 keyCloudMonitorP0 / P1
公网层API、Admin API、H5、官网、SSO、Webhook、证书过期Uptime KumaP0 / P2
业务层TikTok/Shopee/Lazada 订单同步、WhatsApp、Xendit、Push、佣金释放业务服务P1 / P2
AI 运维层Git webhook、i18n 写回 Git、反馈日志分析、AI Worker 自检ai-ops-workerP1 / P2
PRD 文档站不纳入持续监控。

4. 告警统一模型

所有来源转换为同一 Alert 模型。

字段说明示例
source告警来源CLOUD_MONITOR / UPTIME / BUSINESS / AI_WORKER
env环境id-test / id / my-test
countryCode国家ID / MY
level等级P0 / P1 / P2
status处理状态OPEN / ACKED / RESOLVED / MUTED
targetType对象类型ECS / RDS / REDIS / API / JOB
targetName对象名称api-id-test / tiktok-order-sync
title告警标题API Health Down
message告警正文连续 2 次健康检查失败
fingerprint去重指纹UPTIME:id-test:API:api-id-test:DOWN
firstSeenAt首次发生时间2026-07-22 16:00:00
lastSeenAt最近发生时间2026-07-22 16:05:00
repeatCount重复次数5
rawPayload原始请求CloudMonitor/Uptime 原始 JSON

5. 告警接入接口

第一版按来源拆接收接口,内部统一映射为 Alert。

POST /api/v1/alerts/ingest/cloud-monitor
POST /api/v1/alerts/ingest/uptime
POST /api/v1/alerts/ingest/business
POST /api/v1/alerts/ingest/ai-ops
POST /api/v1/alerts/ingest/manual

业务服务上报样例

{
  "source": "BUSINESS",
  "env": "id-test",
  "countryCode": "ID",
  "level": "P1",
  "targetType": "JOB",
  "targetName": "tiktok-order-sync",
  "title": "TikTok 订单同步延迟",
  "message": "最近一次成功同步已经超过 2 小时",
  "metricName": "last_success_age_minutes",
  "metricValue": 128,
  "threshold": 120,
  "occurredAt": "2026-07-22T08:00:00Z"
}

响应样例

{
  "success": true,
  "data": {
    "alert": {
      "alertId": "alr_mx123",
      "status": "OPEN",
      "repeatCount": 3
    },
    "accepted": true
  }
}

管理后台代理接口

GET  /api/v1/admin/alerts
GET  /api/v1/admin/alerts/summary
GET  /api/v1/admin/alerts/{alertId}
POST /api/v1/admin/alerts/{alertId}/ack
POST /api/v1/admin/alerts/{alertId}/resolve
POST /api/v1/admin/alerts/{alertId}/mute

6. 去重、静默与升级

sequenceDiagram participant Source as 告警来源 participant Worker as ai-ops-worker participant DB as Alert DB participant Feishu as 飞书 Source->>Worker: POST /alerts/ingest Worker->>Worker: 标准化 + 生成 fingerprint Worker->>DB: 查询 OPEN 且 fingerprint 相同告警 alt 已存在 Worker->>DB: repeatCount+1 / lastSeenAt=now else 不存在 Worker->>DB: 创建新告警 OPEN end Worker->>Worker: 判断等级、冷却、静默、升级规则 alt 需要通知 Worker->>Feishu: 发送飞书消息 Worker->>DB: 记录 notification else 不需要通知 Worker->>DB: 只记录事件 end
规则建议
P0立即通知。连续重复时 10 分钟内最多提醒一次,恢复时必须通知。
P1立即通知。30 分钟内同 fingerprint 只提醒一次。
P2只入库,默认不实时飞书;每天或每 4 小时汇总。
静默支持按环境、source、targetName、fingerprint 静默,必须记录操作人和到期时间。
升级同一 P1 告警持续超过 30 分钟未恢复,升级为 P0 或再次提醒。

7. 飞书转发

飞书消息由告警中心发出。

BeeX 告警 [P0]
环境: id-test
来源: UPTIME
对象: API / api-id-test
状态: OPEN
标题: API Health Down
消息: https://api-id-test.beexofficial.com/actuator/health 连续 2 次失败
首次发生: 2026-07-22 16:00:00
最近发生: 2026-07-22 16:02:00
重复次数: 2
后台查看: https://admin.beexofficial.com/alerts.html
飞书通知字段:环境、来源、对象、状态、重复次数、后台链接。

8. 管理后台页面

后台新增“告警中心”,调用 ai-ops-worker Alert API。

列表页
当前告警
筛选环境、等级、来源、对象、状态;默认只看 OPEN / ACKED。
事件链路
按告警 ID 查询
第一版先在列表展示核心信息;后台 API 已提供详情接口,后续页面可展开原始 payload、重复事件和通知记录。
操作
认领 / 关闭 / 静默
所有操作都记录操作人、时间、原因,不能静默无审计。
统计
趋势与稳定性
按天统计 P0/P1 数量、平均恢复时间、重复最多的告警对象。

后台接口

GET  /api/v1/alerts?env=id-test&status=OPEN&level=P0
GET  /api/v1/alerts/{alertId}
POST /api/v1/alerts/{alertId}/ack
POST /api/v1/alerts/{alertId}/resolve
POST /api/v1/alerts/{alertId}/mute
GET  /api/v1/alerts/stats/summary

9. CloudMonitor 接入方式

阿里云云监控报警回调地址:

https://ai-ops.beexofficial.com/api/v1/alerts/ingest/cloud-monitor
资源告警项建议阈值
ECS实例状态异常1 次 P0
ECSAgent 心跳丢失1 分钟 P0,3 分钟升级
ECSCPU>70% 3 分钟 P1,>85% 3 分钟 P0
ECS内存>75% 3 分钟 P1,>90% 3 分钟 P0
ECS磁盘>70% P1,>85% P0
RDSCPU / 连接数 / 存储 / 慢 SQL70% P1,85% P0;慢 SQL 按 5 分钟窗口统计
Redis内存 / 连接数 / 延迟 / evicted keysevicted keys > 0 即 P1,持续增长升级
机器卡死判断:Agent 心跳丢失、ECS 状态异常、公网 health 失败,任一触发即上报。

10. Uptime Kuma 接入方式

Uptime Kuma 通知 Webhook:

https://ai-ops.beexofficial.com/api/v1/alerts/ingest/uptime
保留监控说明等级
API Health主业务 API `/actuator/health`P0
Admin API Health管理后台 API `/actuator/health`P1/P0
H5 Home用户 H5 入口P1
H5 Package Latest离线包 latest 接口P1
Runtime ConfigApp 运行时配置P1
Official Site官网P2
SSL Cert Expiry证书临期21 天 P2,7 天 P1,3 天 P0

11. 业务服务接入方式

业务服务 OpsMonitorService 调用 Alert Ingest API。

业务项触发条件等级
TikTok 订单同步最近成功时间超过 2 小时;连续失败 3 次P1
Shopee 订单同步最近成功时间超过 2 小时;conversion report 异常P1
Lazada 订单同步接入后同样按最近成功时间和失败次数判断P1
WhatsApp 入站长期无 inbound 且有登录码创建;webhook 验签失败突增P1/P2
WhatsApp 出站1 小时失败数超过阈值P1
Xendit webhookpending 积压、失败数高、长时间无成功回调P1/P0
佣金释放到期未释放记录超过阈值P1
Push队列积压、lease 过期、失败数高P1/P2

12. 数据库设计

告警中心使用 ai-ops-worker 独立数据库。

CREATE TABLE alert_records (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  alert_id VARCHAR(64) NOT NULL UNIQUE,
  source VARCHAR(32) NOT NULL,
  env VARCHAR(32) NOT NULL,
  country_code VARCHAR(8),
  level VARCHAR(8) NOT NULL,
  status VARCHAR(16) NOT NULL,
  target_type VARCHAR(32) NOT NULL,
  target_name VARCHAR(128) NOT NULL,
  title VARCHAR(255) NOT NULL,
  message TEXT,
  fingerprint VARCHAR(255) NOT NULL,
  first_seen_at DATETIME NOT NULL,
  last_seen_at DATETIME NOT NULL,
  repeat_count INT NOT NULL DEFAULT 1,
  acked_by VARCHAR(128),
  acked_at DATETIME,
  resolved_by VARCHAR(128),
  resolved_at DATETIME,
  muted_until DATETIME,
  raw_payload JSON,
  created_at DATETIME NOT NULL,
  updated_at DATETIME NOT NULL,
  KEY idx_status_level (status, level),
  KEY idx_fingerprint_status (fingerprint, status),
  KEY idx_env_source (env, source),
  KEY idx_last_seen (last_seen_at)
);

CREATE TABLE alert_events (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  alert_id VARCHAR(64) NOT NULL,
  event_type VARCHAR(32) NOT NULL,
  message TEXT,
  operator VARCHAR(128),
  raw_payload JSON,
  created_at DATETIME NOT NULL,
  KEY idx_alert_id (alert_id)
);

CREATE TABLE alert_notifications (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  alert_id VARCHAR(64) NOT NULL,
  channel VARCHAR(32) NOT NULL,
  recipient VARCHAR(255),
  status VARCHAR(32) NOT NULL,
  error_message TEXT,
  sent_at DATETIME,
  created_at DATETIME NOT NULL,
  KEY idx_alert_id (alert_id)
);

13. 安全与权限

对象要求
Ingest API必须有签名或固定 token,不允许公网裸奔。CloudMonitor、Uptime、业务服务分别使用不同 token。
后台查询走管理后台 SSO;普通运营只能看,运维角色才能关闭/静默。
原始 payload默认后台可见,但敏感字段要脱敏,例如 token、secret、手机号。
静默操作必须填写原因和到期时间,不允许永久静默。
审计认领、关闭、静默、恢复、手工重发飞书都写 `alert_events`。

14. 落地步骤

阶段要做什么验收标准
第 1 步ai-ops-worker 增加 alert 表、ingest API、去重逻辑手工 curl 能创建告警、重复告警只更新 repeatCount
第 2 步增加飞书转发路由P0/P1 能发飞书,P2 只入库
第 3 步管理后台增加告警中心页面能筛选、查看详情、认领、关闭、静默
第 4 步Uptime Kuma webhook 改到告警中心模拟 down/up 能在后台看到,并收到飞书
第 5 步CloudMonitor webhook 改到告警中心ECS/RDS/Redis 测试告警能入库
第 6 步业务服务 OpsMonitorService 改为上报告警中心订单同步延迟、WhatsApp 失败、Xendit 积压能统一展示
第 7 步增加统计面板和日报可以看到每日 P0/P1 数量、MTTR、重复最多对象
先完成第 1~3 步;CloudMonitor 和 Uptime 先并行试跑,再切断直发飞书。