背景与需求
假设有一个 Kubernetes 集群，机器数量比较多。单个节点异常时，只需要产生低级别告警，例如邮件提醒；但如果超过 50 台机器同时告警，就应该升级为高级别告警，例如电话或短信提醒。
这个场景的关键点是：告警级别不只由单条告警本身决定，还由同类活跃告警的数量决定。也就是说，我们需要把“单点告警”聚合成“集群级风险”。
本文用夜莺监控系统的 MySQL 数据源能力演示一种做法：通过 SQL 查询当前活跃告警数量，再把查询结果作为新的告警规则输入。
核心思路
夜莺已经有 alert_cur_event 数据库表，用来存储当前所有活跃、未恢复的告警事件。只要 SQL 能查出符合条件的活跃告警数量，就可以把这个数量交给告警规则做阈值判断。
常规告警规则通常针对 Prometheus 数据源写 PromQL 表达式；但夜莺也支持 MySQL 数据源，可以直接写 SQL。对于“统计当前活跃告警事件数量”这类需求，MySQL 数据源反而更直接。
本文示例的链路如下：
| 步骤 | 动作 | 目的 |
|---|---|---|
| 1 | 创建指向夜莺数据库的 MySQL 数据源 | 让告警规则能够查询当前告警表 |
| 2 | 使用 SQL 统计某类活跃告警数量 | 得到可用于阈值判断的数值 |
| 3 | 将 SQL 返回字段作为值字段 | 让夜莺按聚合数量触发告警 |
| 4 | 设置大于阈值的告警条件 | 实现集群级升级 |
实现步骤
1. 创建 MySQL 数据源
在数据源管理中创建一个 MySQL 数据源，填写连接和认证信息，让它指向夜莺所用的 MySQL。测试通过后保存。
生产环境建议单独分配一个低权限只读账号，只允许查询告警相关表。本文截图为了演示方便，直接使用了 root 账号，不建议照搬到生产环境。
2. 创建告警规则
关键配置如下：
- 数据源类型：选择
MySQL。 - 数据源筛选：选择刚才创建的夜莺 MySQL 数据源。
- 查询条件：填写 SQL，例如
select count(*) cnt from n9e_v6.alert_cur_event where rule_id=73;。 - 值字段：选择
cnt，也就是 SQL 返回的计数字段。 - 阈值判断：使用简单模式即可，选择大于（
>），填写需要升级的数量阈值。
这里的 rule_id=73 是测试用的某个告警规则 ID。实际使用时要根据自己的规则 ID、业务标签、集群标签或其他筛选条件调整 SQL。
我这里故意把阈值填写为 1，是为了快速触发测试。真实场景可以按“超过 50 台机器告警”等业务规则设置阈值。
3. 测试效果
正常产生了告警事件：
其中触发时的值为 3：实际就是 ID 为 73 的告警规则当前有 3 个活跃告警事件。
适用场景与边界
这种方案适合“当前活跃告警数量本身就是风险信号”的场景，例如：
- 同一 Kubernetes 集群内大量节点同时触发低级别告警。
- 同一个业务规则短时间内出现大量未恢复事件。
- 某类基础设施告警数量超过运维团队可人工处理的规模。
它不适合替代所有告警聚合逻辑。比如需要按时间窗口计算增长率、按多维标签做复杂去重、或跨多个告警系统统一收敛时，仍然应该结合专门的告警聚合、收敛和事件处理能力。
FAQ
Q1：为什么不用 PromQL 直接实现？
如果告警数量来自 Prometheus 指标，PromQL 是自然选择。本文场景要统计的是夜莺当前活跃告警表里的事件数量，MySQL 数据源可以直接查询 alert_cur_event，路径更短。
Q2：SQL 里只按 rule_id 过滤够不够？
演示场景够用。生产环境通常还要结合集群、业务、环境、告警级别等字段，避免不同对象的告警被混在一起统计。
Q3：为什么建议只读账号？ 告警规则只需要查询当前告警数量，不应该拥有写入或修改数据库的权限。低权限账号可以降低误操作和凭据泄露的影响范围。
小结
基于夜莺 MySQL 数据源统计 alert_cur_event，可以把“多个低级别活跃告警”升级成“集群级高级别告警”。这个方案的核心不是 SQL 复杂度，而是把当前活跃告警事件数量变成可告警的数值，并在规则里明确阈值、筛选范围和权限边界。
