22、监控与告警系统：系统运行监控、策略异常告警、网络延迟监控、交易对账系统
做量化交易，最怕什么？
不是策略亏钱，而是系统挂了你还不知道。
我见过太多团队，策略逻辑写得漂漂亮亮，结果半夜网络断了，或者交易所接口超时，一觉醒来发现账户亏了几十万。嗯，我自己也踩过这个坑。所以今天咱们聊聊监控与告警系统——说白了，就是给你的交易系统装个“心跳检测仪”。
系统运行监控：你得知道机器在干嘛
系统运行监控，核心就三件事：CPU、内存、磁盘。
你想想看，如果服务器CPU飙到100%，你的策略还能正常跑吗？肯定不能。所以我们要实时采集这些指标。
核心监控指标清单：
- CPU使用率：超过80%就要预警，超过95%立刻停机检查
- 内存占用：物理内存剩余不足20%时触发告警
- 磁盘IO：读写延迟超过100ms就要排查
- 网络带宽：入站/出站流量接近上限时预警
- 进程存活：核心交易进程意外退出必须秒级告警
我个人习惯用Prometheus + Grafana这套组合。Prometheus负责采集数据，Grafana负责可视化。为什么选它们？因为生态好，社区活跃，而且支持自定义告警规则。
举个例子，我曾经遇到过一次磁盘写满导致日志无法写入，策略直接崩溃。后来我加了一条规则：磁盘使用率超过85%就发邮件+短信，超过95%直接自动清理旧日志。从那以后，再没出过类似问题。
策略异常告警：别让策略“带病运行”
策略异常告警，比系统监控更微妙。因为策略出问题，往往不是“挂了”，而是“跑偏了”。
什么叫跑偏？比如你的策略本来每天交易10次，突然一天交易了100次。或者你的策略本来只做多，突然开始做空了。这些都属于异常行为。
我建议设置以下几类告警：
- 交易频率异常：单位时间内开仓次数超过历史均值的3倍
- 持仓偏离度：当前持仓与策略预期持仓偏差超过阈值
- 盈亏异常：单笔亏损超过账户净值的2%
- 信号缺失：连续N个周期没有产生交易信号
- 参数突变：策略参数被意外修改（比如有人手滑改了配置）
小技巧：告警阈值不要设得太死。我一般用“动态阈值”——根据过去7天的数据自动计算上下限。比如交易频率，如果市场波动大，交易次数自然多，这时候用固定阈值就容易误报。
网络延迟监控：毫秒级的生死线
做高频交易的朋友都知道，网络延迟就是钱。延迟每增加1毫秒，你的订单可能就排到别人后面去了。
网络延迟监控，主要盯三个地方：
- 交易所到服务器的延迟：用ping或者WebSocket心跳包测量
- 服务器内部处理延迟：从收到行情到发出订单的时间差
- 订单到交易所的确认延迟：发出订单到收到成交回报的时间
我记得有一次，某个交易所的API网关出了问题，导致订单确认延迟从2ms飙升到200ms。我们的监控系统第一时间发现了，自动切换到了备用交易所。如果没这个监控，那天的交易基本就废了。
下面是我常用的网络延迟监控代码片段：
import time
import asyncio
import aiohttp
async def measure_latency(exchange_url):
"""测量到交易所的网络延迟"""
start = time.time()
async with aiohttp.ClientSession() as session:
async with session.get(exchange_url + '/ping') as resp:
await resp.text()
end = time.time()
return (end - start) * 1000 # 返回毫秒
# 每5秒测一次
async def monitor_loop():
while True:
latency = await measure_latency('https://api.binance.com')
if latency > 50: # 超过50ms告警
print(f'[WARN] 网络延迟异常: {latency:.2f}ms')
await asyncio.sleep(5)交易对账系统：钱不能算错
交易对账，说白了就是“算账”。你的策略说赚了10万，交易所说赚了9.8万，那2000块去哪了？
对账系统要解决的核心问题：
- 订单对账：本地记录的订单与交易所的订单一一比对
- 持仓对账：本地计算的持仓与交易所的持仓核对
- 资金对账：账户余额变动与交易记录匹配
- 手续费对账：每笔交易的手续费是否正确扣除
注意：对账不是一次性的，要定时跑。我建议每5分钟做一次增量对账，每天收盘后做一次全量对账。如果发现差异超过0.01%，立刻冻结交易并人工介入。
我曾经遇到过一个问题：某个交易所的返佣规则改了，但我们的系统没更新，导致手续费对不上。虽然金额不大，但如果不及时发现，日积月累也是一笔不小的损失。从那以后，我把手续费对账的阈值调到了0.001%，宁可误报也不能漏报。
整体架构图
下面这张图展示了监控与告警系统的整体架构。你可以看到数据从采集到告警的完整链路：
从架构图可以看出，数据从底层采集上来，经过规则引擎判断，触发告警后通过多种渠道通知到人，同时数据落地到数据库方便事后复盘。这个链路看起来简单，但每个环节都有坑。
我的建议：告警不要太多，否则容易“狼来了”。我一般把告警分三级：
- INFO：记录日志，不通知
- WARN：发邮件，白天处理
- CRITICAL：短信+电话，7x24小时响应
这样既不会漏掉重要问题，也不会被垃圾告警烦死。
好了，监控与告警系统就聊这么多。记住一句话：没有监控的系统，就像闭着眼睛开车。你永远不知道下一秒会发生什么。