3. 哨兵告警系统架构：哨兵系统组件、数据采集层、规则引擎层、告警通知层

哨兵告警系统是回测坏账率监控的“神经中枢”。一个健壮的架构需要将数据采集、规则判定、通知分发三个核心环节解耦，确保在高频回测场景下不丢数据、不误报、不漏报。本章从组件划分、分层职责、交互流程三个维度拆解哨兵系统的标准架构。

3.1 哨兵系统核心组件

哨兵系统由以下五大组件构成，各组件独立部署、通过消息队列或API网关通信：

3.2 数据采集层

数据采集层负责从回测系统获取原始指标，并进行清洗、格式化、缓存。采集层需要处理三个关键问题：采集频率、数据完整性、异常标记。

• 采集方式：支持推模式（回测引擎主动上报）和拉模式（哨兵定时轮询），生产环境推荐推+拉双通道。
• 指标预处理：对坏账率进行滑动窗口平滑（如5分钟均值），过滤毛刺数据。
• 元数据注入：为每条指标打上回测批次ID、策略版本、时间戳标签，便于规则引擎溯源。

# 数据采集层核心逻辑示例（伪代码）
class BadRateCollector:
    def __init__(self, window_size=300):
        self.window = deque(maxlen=window_size)
        self.cache = RedisCache()

    def ingest(self, raw_point: dict):
        # 1. 格式校验
        if not self._validate(raw_point):
            self._mark_as_invalid(raw_point)
            return
        # 2. 滑动窗口平滑
        self.window.append(raw_point['bad_rate'])
        smoothed = sum(self.window) / len(self.window)
        # 3. 写入缓存（TTL=60s）
        self.cache.setex(
            f"badrate:{raw_point['batch_id']}",
            60,
            json.dumps({'value': smoothed, 'ts': raw_point['timestamp']})
        )

3.3 规则引擎层

规则引擎是哨兵系统的“大脑”，负责加载告警规则、执行阈值比对、输出告警事件。规则引擎的设计直接影响告警的准确性和响应速度。

3.3.1 规则类型

3.3.2 规则执行流程

1. 规则加载：从配置中心拉取最新规则集，缓存到本地内存。
2. 指标匹配：根据回测批次ID、策略标签路由到对应规则组。
3. 阈值比对：依次执行静态阈值、动态基线、趋势规则。
4. 事件生成：命中规则后，生成告警事件（含规则ID、当前值、阈值、触发时间）。
5. 事件输出：将告警事件写入消息队列（Kafka / RocketMQ），供告警管理器消费。

3.4 告警通知层

告警通知层负责将规则引擎产出的告警事件，经过聚合、去重、降噪后，通过多渠道推送给相关人员。通知层的设计目标是：不轰炸、不遗漏、可追溯。

3.4.1 告警聚合与降噪

• 时间窗口聚合：相同规则在5分钟内只发一条通知，避免告警风暴。
• 严重级别分级：P0（立即处理）、P1（需关注）、P2（记录归档），不同级别走不同通知渠道。
• 抑制规则：如果上游策略已触发P0告警，下游关联规则自动抑制，减少重复通知。

3.4.2 通知渠道与模板

3.5 架构总览与交互时序

将数据采集层、规则引擎层、告警通知层串联起来，形成完整的哨兵告警系统架构。下图展示了从指标采集到通知触发的完整数据流：

整个架构采用异步解耦设计，每个组件都可以独立扩缩容。数据采集层和规则引擎层之间通过缓存解耦，规则引擎层和告警通知层之间通过消息队列解耦，确保任意一层故障不会导致整个系统瘫痪。