联易融夜莺+FlashDuty 实践：Event Processor 告警增强与故障闭环管理

陈晓敏 2026-03-18 10:06:30

本文作者：陈晓敏，来自联易融数字科技，To B金融科技资深运维架构师，一个爱思考、爱钻研、爱折腾的技术爱好者。

夜莺项目开源地址：https://github.com/ccfos/nightingale 欢迎收藏，欢迎分享您的落地案例。

一、公司与业务背景

联易融数字科技是一家致力于向核心企业和金融机构提供世界领先的供应链金融科技解决方案提供商。旗下围绕核心企业云、金融机构云、跨境云等多个业务板块，截至2025年6月30日，联易融累计服务的供应链资产规模超过1.7万亿元，已经与超过2,900家核心企业及金融机构合作伙伴达成合作；客户覆盖全国30个省及行政区，客户涵盖全球27个国家及地区，服务了超过38万家中小微企业。

监控对象多、类型复杂，覆盖网络、节点、公有云与容器化等多种形态，整体属于大规模、多源异构的可观测性场景。之前的监控技术栈：Prometheus + VictoriaMetrics + Alertmanager。

二、监控痛点与挑战

2.1 告警信息不足

传统告警只显示单个故障表现，缺少上下文信息，就像"盲人摸象"——只能看到局部，无法把握全局。

典型场景：收到告警“HTTP 5xx 增多”

❌ 出问题的 RS Pod 是否集中在某个节点，共性问题还是单点
❌ 关联的资源 CPU/内存负载如何
❌ 同时段是否有关联的 K8s 事件
❌ 同时段是否有其他告警
❌ 是否有变更

人工排查流程：在多个系统间“跳来跳去”

登录 ClickHouse 查询网关日志
登录 Grafana 查看 Pod 指标
登录 K8s 查看 Pod 事件
看宿主机负载、SQL 慢查询及中间件等指标

2.2 缺乏闭环管理

告警无法集中管理
无法追踪故障处理进度
缺少值班管理和升级机制

三、选型与决策

3.1 为什么选择 Prometheus + VM + 夜莺 + FlashDuty？

监控端采集、存储端（Prometheus + VM + 各类 exporter）保持不变，只是更换了告警引擎，对架构的改动最小，但收益很大。

我们对比了多种方案，最终选择「夜莺 + FlashDuty 」的组合替代 Alertmanager：

决策点：

Event Processor 机制：可以在告警触发时自动执行自定义逻辑
- Event Update API：在告警事件中注入关联数据
- Callback API：执行自动化诊断脚本
FlashDuty 闭环管理：
- 多渠道告警平台聚合（Prometheus、Zabbix、各类公有云平台）
- 故障闭环管理（认领/分配/处理/关闭）
- 值班排班和自动升级机制

四、核心能力：Event Processor

在介绍具体架构之前，我们先了解一下夜莺 v8 的核心能力——事件处理器（Event Processor）。

4.1 什么是 Event Processor？

根据夜莺官方文档的定义：

事件处理器（Event Processor）是夜莺 v8 版本引入的一个概念，当告警事件产生之后，在发送通知之前，可以使用事件处理器对告警事件做额外的处理。

简单来说，就是给告警装上了"大脑"和"手脚"，让它在发送前能够自动补充信息、执行诊断、甚至调用 AI 分析。

支持 5 类处理器：

Relabel：标签的"美容师"，可以删除、重命名、合并和修改标签值
Callback：告警的"传话筒"，通过 HTTP 调用将告警信息发送到外部系统
Event Update：告警的"信息员"，调用外部服务来动态更新告警内容
Event Drop：告警的"过滤器"，根据自定义条件决定是否删除特定告警
AI Summary：告警的"分析师"，调用 AI 模型分析告警并生成总结建议

Pipeline 机制：多个处理器可以组成一个 Pipeline，对告警事件做一系列灵活的处理。

4.2 Additional Info：另一种告警增强方式

除了 Event Processor，夜莺还提供了 Additional Info（附加信息） 功能，它不属于 Event Processor，但同样能丰富告警上下文。

核心特点：

直接在告警规则中配置附加查询
无需 HTTP 调用，性能最优
使用限制：附加查询的指标必须来自与告警触发相同的 TSDB 数据源

典型应用场景：

队列堆积告警附加消费速率、队列增长量等指标
服务响应慢告警附加 CPU、内存、连接数等资源指标
磁盘告警附加 IO 使用率、inode 使用率等关联指标

具体实践案例见第五章。

4.3 整体流程设计

我们的告警增强方案分为三层：

数据关联层（Event Update）：按告警类型关联日志、K8s 事件、邻近时段告警等上下文。
自动诊断层（Callback）：执行 SOP 脚本（连通性、端口、节点状态等），生成结构化诊断结果。
协同处置层（FlashDuty）：将增强后的告警纳入统一值班、升级、故障闭环流程。

4.4 Event Pipeline 工作流程简介

告警触发
  ↓
夜莺 Alert Engine
  ↓
Event Update → Event Processor
  ├─ 执行 ClickHouse 关联查询
  ├─ 查询 K8s 事件
  └─ 结果写入 event.annotations
  ↓
Callback → Callback Processor
  ├─ 执行 SOP 自动诊断
  ├─ 网络连通性检测
  └─ 结果写入 event.annotations.callback
  ↓
增强后的告警 → FlashDuty
  ↓
值班人员收到带完整上下文的告警

4.5 告警增强之前：监控采集自动化底座

在讨论 Event Update、Callback 时，会把注意力放在“查询和诊断”本身。但在我们的实践里，查询只是结果，不是起点。真正耗时、也最决定效果的工作在查询之前，包括数据采集、字段清洗、标签标准化和存储建模。

我们总结了一个实践原则：对于排障高频使用的数据（如网关日志、K8s 事件、核心业务指标、网络流量），尽量汇聚到同一查询平面（例如 ClickHouse）。这样可以减少跨系统跳转和多数据源对时成本，让 Event Update 的查询更快、更稳定，也更容易做统一关联分析。

主要依托我们 BeeCloud 运维平台的两个功能板块完成这件事：

CMDB：CI 自动发现与关系维护
- 自动发现主机、数据库、应用实例等 CI 项，并持续同步变更。
- 统一维护环境、业务域、负责人、资源关系（应用-服务-节点）等元数据。
- 为后续告警标签、分派策略和关联分析提供一致的数据基线。

DEVOPS：应用监控采集配置标准化
- 统一配置日志采集、APM 埋点和自定义指标采集。
- 通过模板化方式下发采集规则，避免人工逐项配置带来的遗漏。
- 将“监控接入”前置到交付流程，让新应用在上线时就具备可观测性。

这两块能力结合后，我们把监控建设从“告警后补数据”变成“上线即有数据”。这也是后文 Event Processor 能稳定发挥作用的关键前提。

五、实践与经验

5.1 Event Update：多维度关联查询

基于夜莺的 Event Update 机制，我们实现了告警事件的上下文自动增强。

大致流程如下：

场景1：HTTP 5xx 告警自动分析

触发条件：rule_name 匹配 5xx

自动执行的查询：

网关层分析：APISIX/Traefik 5xx 分布（按 route/upstream）
Pod 定位：找到具体出问题的 Pod
K8s 事件关联：查询 Pod 重启/OOM/节点异常事件
关联告警：前后 2 分钟的相关告警

场景2：网络带宽告警自动分析

触发条件：alert_type=network

自动查询：专线上行/下行 Top3 流量对，快速定位流量来源。

5.2 Callback Processor：SOP 自动诊断

基于夜莺的 Callback 机制，我们实现了自动化诊断。

场景：节点不可达告警

触发条件：rule_name 含 “节点不可达”

自动执行三层检测：

Ping 检测：ICMP 连通性
TCP 端口检测：关键端口（SSH/HTTP/HTTPS）
SSH 登录诊断：CPU 负载、Top 进程、端口监听状态

5.3 Additional Info：同源数据关联

基于夜莺的 Additional Info 机制，我们实现了告警的同源数据关联增强。

场景：RabbitMQ 队列堆积告警

触发条件：队列消息数 > xx，持续 10 分钟

阈值说明：xx 为历史运行数据下的业务阈值（结合峰值水位和处理时延目标设定）。

传统告警只会告诉你"队列堆积超过阈值"，但使用 Additional Info 后，告警中会自动包含：

最近 3 分钟平均消费速率：xx 条/s
最近 5 分钟队列增长了：xx 条
该队列的消费端进程数为：xx 个

配置方式：

在告警规则中添加附加查询（PromQL）：

再配合 AI Summary Processor，还能得到根因分析和处理建议, 告警从"只有现象"变成"现象+数据+分析+建议"

5.4 FlashDuty 闭环管理

Event Processor 解决了告警信息不足并提升了自动化处理能力，但仍缺少告警事件的闭环管理。我们依然无法直观看到：告警是否被及时响应、由谁处理、处理进度如何，团队成员也需要频繁沟通同步信息。

通过 FlashDuty，我们实现了完整的故障处理闭环：

告警聚合：多平台告警统一入口，避免告警分散
故障管理：认领 → 分析 → 处理 → 关闭，全流程可追溯，无需额外的传达与沟通
值班排班：自动轮换，支持多级升级
数据回填：处理结果自动回写到FlashDuty，形成知识库

5.5 实施经验

把手动排查的操作转换为 Event Processor 自动化执行。

识别哪些操作适合做成 Event Processor：

重复性高的查询：日志、指标、事件等数据源的查询
有明确判断逻辑的诊断步骤：网络连通性、资源使用率等可量化的检查
可以标准化的处理流程：扩容、重启等有明确 SOP 的操作

实施原则：

从最高频的故障场景入手，优先自动化
保持 Event Processor 的简单性，避免过度复杂

六、效果与收益

1. 告警噪音降低超过 60%

通过故障聚合和智能抑制，告警从"狼来了"变成了"真的有狼"。

2. 值班体验提升

告警通知直接包含根因分析，不再需要手动查询多个系统。非工作时间值班压力显著降低。

3. 故障处理可追溯

每个故障都有完整的处理记录，可以回溯历史故障的处理过程，便于复盘和经验沉淀。

4. 团队协作更高效

故障可以快速分配给相关负责人，支持多人协作处理复杂故障，自动升级机制保证故障不遗漏。

七、未来规划

7.1 AI 值守：基于 Agent + Skills 的智能运维

我们正在探索基于 AI Agent 的值守模式，从"人工触发"向"完全自动化"演进。

实现方式：

Agent：AI 智能体，具备推理和决策能力
Skills：可复用的运维技能（查日志、查指标、执行脚本等）
工作流：Agent 根据告警内容，自动编排 Skills 执行诊断和修复

当前实践：人工触发 Agent + Skills

下面通过一个真实的生产故障案例，展示 Agent + Skills 协同工作的效果。

案例：从 5xx 告警到节点过载根因定位

故障概况：

时间：2026-03-02 10:51-10:57（持续 6 分钟）
影响：4 个服务同时出现 HTTP 5xx 错误
错误类型：504 Gateway Timeout、502 Bad Gateway

诊断流程（人工触发 Agent 使用 Skills）：

第一步：FlashDuty Skill - 告警聚合

使用 flashduty-oncall skill 查询最近几条 HTTP 5xx 的故障列表，发现 4 个服务同时出现 5xx，都在同一命名空间，初步判断是共同根因。

第二步：Log Analytics Skill - 日志分析

使用 log-analytics skill 查询 ClickHouse 中的 Nginx 访问日志，发现 504/502 错误模式，upstream_time 特征表明是后端处理超时。

第三步：Log Analytics Skill - 定位节点故障

查询 VictoriaMetrics 节点状态，发现所有故障服务的 Pod 都在同一个节点上，该节点在 10:56 变为 NotReady。

第四步：Log Analytics Skill - 分析节点性能指标

查询节点 CPU、内存、Load，发现 CPU 打满（97%-99%）是直接原因。

第五步：Log Analytics Skill - 定位 CPU 消耗源

查询节点上各 Pod 的 CPU 使用率，发现 sae-drission（浏览器自动化服务）扩容导致节点 CPU 资源耗尽。

完整根因链路：

月初业务上量 → 某 OCR 应用扩容到 100 副本
→ 节点 CPU 打满（97-99%） → 所有 Pod 响应变慢
→ 504/502 错误 → 节点 NotReady → K8s 驱逐 Pod
→ 服务恢复

第六步：FlashDuty Skill - 故障闭环

使用 flashduty-oncall skill 回填根因和解决方案，将 5 个相关故障合并为一个主故障，完成闭环。

案例价值：

定位速度：从发现问题到定位根因，用时不到 2 分钟
证据充分：多数据源交叉验证，结论具备高置信度
完整闭环：诊断 → 回填 → 合并，全流程自动化
Skills 协同：flashduty-oncall + log-analytics 无缝配合

未来演进：完全自动化的 AI 值守

当前模式是"人工触发 Agent 使用 Skills"，未来将演进为"AI Agent 自动值守"：

告警触发 → AI Agent 自动接收
  ↓
Agent 分析告警内容
  ↓
自动编排 Skills：
  - flashduty-oncall: 查询告警列表
  - log-analytics: 分析日志和指标
  - flashduty-oncall: 回填根因
  ↓
生成诊断报告

预期价值：

人工值守变为 AI 自动值守
被动响应变为主动修复

7.2 知识库沉淀

将故障处理经验沉淀为知识库，并转化为可复用的 Skills。

沉淀流程：

故障处理 → 根因分析 → 经验总结
    ↓
知识库文档化
    ↓
提炼为 Skill（标准化、自动化）
    ↓
下次故障自动调用

通过这种方式，每次故障处理都在为未来的自动化积累"弹药"。

八、总结

通过夜莺 Event Processor + FlashDuty 的组合，我们实现了告警的自动增强和故障的闭环管理。

价值总结：

告警增强：Event Update 机制让告警"会说话"
自动诊断：Callback 机制让告警"会动手"
闭环管理：FlashDuty 让故障"有始有终"

实践经验：

监控系统不仅要"发现问题"，更要"分析问题"
自动化不是目的，提升效率才是目标
工具只是手段，方法论才是核心

希望我们的实践能给大家一些启发。

夜莺项目开源地址：https://github.com/ccfos/nightingale

FlashDuty 官网：https://flashcat.cloud/product/flashduty/