2. 延迟尖峰告警系统架构:整体设计

精算模型延迟尖峰告警系统采用分层架构,将数据采集、计算、告警与可视化四个核心环节解耦。每一层独立部署、独立扩展,通过标准接口传递数据,确保系统在高吞吐、低延迟场景下的稳定性和可维护性。整体架构遵循“采集-计算-推送-展示”的数据流向,形成闭环监控体系。

架构设计原则:
  • 解耦性:各层通过消息队列或API网关通信,任一层的升级或故障不影响其他层。
  • 可扩展性:计算引擎层支持横向扩展,应对业务量增长。
  • 实时性:从数据采集到告警推送,端到端延迟控制在秒级。
  • 可观测性:每一层都输出关键指标,便于排查和调优。
延迟尖峰告警系统整体架构图 延迟尖峰告警系统整体架构图 数据采集层 SQL日志 / 埋点 / 消息队列 计算引擎层 SQL聚合 / 滑动窗口 / 阈值判定 告警推送层 邮件 / 短信 / 企微 / 钉钉 可视化看板层 Grafana / 实时大屏 / 趋势图 数据存储 ClickHouse / Elasticsearch 数据流:采集 → 计算 → 存储 → 看板;告警推送与看板之间通过反馈机制联动

2.1 数据采集层

数据采集层是整个系统的入口,负责从精算模型运行环境中捕获延迟数据。采集方式包括:

  • SQL 执行日志:从数据库慢查询日志或自定义审计日志中提取每条 SQL 的执行耗时。
  • 应用埋点:在精算模型调用链路上植入埋点,记录每个步骤的起止时间。
  • 消息队列消费:从 Kafka / RabbitMQ 中消费模型运行状态事件,解析延迟字段。

采集层输出的数据格式统一为 JSON,包含 model_id、run_id、step_name、start_time、end_time、duration_ms 等字段,直接写入计算引擎层的输入队列。

采集方式 数据源 延迟精度 适用场景
SQL 执行日志 MySQL / PostgreSQL 慢查询日志 毫秒级 数据库密集型模型
应用埋点 Java / Python SDK 埋点 微秒级 全链路追踪
消息队列消费 Kafka / RabbitMQ 毫秒级 异步模型任务

2.2 计算引擎层

计算引擎层是系统的核心,负责对采集到的延迟数据进行实时聚合与阈值判定。该层基于 SQL 实现,主要包含以下模块:

  • 滑动窗口聚合:使用 OVER (ORDER BY ... ROWS BETWEEN ... PRECEDING) 计算最近 N 条记录的平均延迟、P99 延迟。
  • 尖峰检测:通过 LAG() 函数对比当前延迟与历史基线,当偏差超过阈值时标记为尖峰。
  • 多维度分组:按 model_id、step_name、data_center 等维度分别计算,避免单一维度掩盖局部尖峰。
性能优化要点:计算引擎层使用 ClickHouse 物化视图或 Flink SQL 实现,避免全表扫描。窗口函数尽量使用 PRECEDING 限定范围,减少计算量。
计算引擎层内部流程图 计算引擎层内部流程图 原始延迟数据 滑动窗口聚合 尖峰检测 告警事件输出 核心 SQL 函数:LAG()、AVG() OVER、CASE WHEN 阈值判定

2.3 告警推送层

告警推送层接收计算引擎输出的告警事件,根据配置的规则进行分级推送。推送方式包括:

  • 即时推送:对于 P0/P1 级尖峰,通过短信、电话、企业微信机器人立即通知值班人员。
  • 聚合推送:对于 P2/P3 级尖峰,按 5 分钟窗口聚合后发送邮件或钉钉消息,避免告警风暴。
  • 静默规则:支持按模型、时间段、频率设置静默,过滤重复告警。
告警级别 延迟阈值 推送方式 响应要求
P0(严重) 基线 + 500% 短信 + 电话 + 企微 5 分钟内响应
P1(高) 基线 + 200% 企微 + 邮件 15 分钟内响应
P2(中) 基线 + 100% 邮件 30 分钟内响应
P3(低) 基线 + 50% 看板标记 次日复盘

2.4 可视化看板层

可视化看板层为运维和精算团队提供实时监控界面,展示延迟趋势、尖峰分布、告警历史等关键信息。看板基于 Grafana 搭建,数据源对接 ClickHouse 或 Elasticsearch。

  • 实时趋势图:展示最近 1 小时各模型的平均延迟、P99 延迟曲线。
  • 尖峰热力图:按模型和步骤展示尖峰发生频率,颜色深浅代表严重程度。
  • 告警事件列表:实时滚动展示最新告警,支持按级别、模型、时间筛选。
  • 历史对比:支持选择任意时间范围,对比当前延迟与历史基线。
注意:看板层的数据查询必须使用索引优化,避免大范围全表扫描。建议为时间字段和 model_id 字段建立复合索引,确保看板页面加载时间不超过 3 秒。

2.5 层间通信与数据流

各层之间通过以下方式通信,确保数据不丢失、不重复:

  • 采集层 → 计算引擎层:通过 Kafka 主题传递原始延迟事件,使用 exactly-once 语义保证数据一致性。
  • 计算引擎层 → 告警推送层:通过 Redis 队列或 gRPC 接口传递告警事件,支持背压机制。
  • 计算引擎层 → 数据存储:批量写入 ClickHouse,使用 ReplacingMergeTree 引擎去重。
  • 数据存储 → 可视化看板层:通过 Grafana 数据源插件直连,使用 dashboard 变量实现动态过滤。