4. 监控哨兵架构：哨兵系统的整体架构图、数据采集层、计算层、告警层
行情坏账率漂移监控哨兵系统采用经典的三层分布式架构，将数据采集、实时计算与告警通知解耦，确保在高吞吐、低延迟场景下的稳定运行。整体架构遵循“采集→计算→告警”单向数据流，各层之间通过消息队列或API网关进行异步通信，避免单点瓶颈。
4.1 哨兵系统整体架构总览
下图展示了哨兵系统的核心组件与数据流转路径。数据从行情源出发，经过采集层标准化、计算层聚合分析，最终由告警层触发通知或自动化处置动作。
架构要点：三层之间通过消息队列（如 Kafka / RabbitMQ）解耦，采集层不关心计算逻辑，计算层不关心通知方式。这种设计使得每一层都可以独立扩缩容，应对行情数据洪峰。
4.2 数据采集层：多源接入与标准化
数据采集层是哨兵系统的“触角”，负责从各类行情源获取原始数据，并完成格式校验、去重、时间戳对齐等预处理操作。采集层必须支持高并发、断线重连与数据回填。
| 采集方式 | 适用场景 | 延迟级别 | 可靠性策略 |
|---|---|---|---|
| REST API 轮询 | 低频行情、历史数据补录 | 秒级～分钟级 | 指数退避重试 + 幂等写入 |
| WebSocket 订阅 | 实时行情、Tick 级数据 | 毫秒级 | 心跳保活 + 自动重连 + 序列号校验 |
| 文件/消息队列导入 | 离线批处理、第三方推送 | 分钟级～小时级 | 偏移量记录 + 去重表 |
采集层输出的标准化数据格式示例如下：
{
"symbol": "BTC/USDT",
"exchange": "Binance",
"timestamp": 1712563200000,
"bid": 67500.12,
"ask": 67501.88,
"last_price": 67500.50,
"volume_24h": 125000.0
}
常见陷阱：不同行情源的时间戳精度可能不一致（秒级 vs 毫秒级），采集层必须统一转换为毫秒时间戳，否则后续滑动窗口聚合会出现数据错位，导致漂移误判。
4.3 计算层：核心漂移检测引擎
计算层是哨兵系统的“大脑”，接收标准化行情数据后，执行滑动窗口聚合、坏账率计算、漂移检测与阈值对比。计算层通常采用流处理框架（如 Flink / Spark Streaming）或高性能内存计算引擎。
计算层内部包含四个关键子模块：
- 滑动窗口聚合：按固定时间窗口（如 5 分钟、1 小时）统计订单成交笔数、失败笔数、坏账金额。
- 坏账率计算：坏账率 = 坏账笔数 / 总成交笔数 × 100%，支持按交易对、按用户层级、按渠道维度下钻。
- 漂移检测算法：对比当前窗口坏账率与历史基线（过去 7 天同期均值），计算偏差百分比或 Z-Score。
- 阈值对比引擎：将漂移值与预设的告警阈值（如偏差 > 20% 或 Z-Score > 3）进行匹配，输出告警事件。
性能优化建议：计算层应使用增量聚合而非全量重算。每次新数据到达时，只需更新窗口末尾的统计值，避免每次触发全表扫描。对于高频交易对，建议预分配内存窗口数组，减少 GC 压力。
4.4 告警层：分级通知与自动化处置
告警层接收计算层输出的告警事件，根据严重级别、业务规则和用户配置，执行多渠道通知、工单创建或自动化熔断操作。告警层必须内置降噪机制，防止告警风暴。
| 告警级别 | 漂移幅度 | 通知方式 | 自动化动作 |
|---|---|---|---|
| INFO（提示） | 偏差 10%～20% | 内部日志 + 看板标记 | 无 |
| WARNING（警告） | 偏差 20%～50% | 邮件 + 企业微信/钉钉 | 创建工单，通知值班人员 |
| CRITICAL（严重） | 偏差 > 50% 或连续 3 个窗口超阈值 | 短信 + 电话 + 邮件 | 自动暂停该交易对，触发风控复核流程 |
告警层降噪策略包括：
- 聚合降噪：相同交易对、相同告警级别在 5 分钟内只发送一条聚合通知。
- 抑制规则：如果上游数据源标记为“维护中”或“数据延迟”，自动抑制告警。
- 衰减机制：连续告警超过 10 次后，通知频率自动降低为每 30 分钟一次，避免轰炸。
最佳实践：告警层应暴露 Webhook 接口，方便对接内部工单系统（如 Jira、飞书多维表格）或自动化运维平台（如 Ansible、K8s Operator）。告警事件必须包含完整的上下文信息（交易对、窗口时间、基线值、当前值、偏差百分比），便于快速定位根因。