📟 日志、监控与告警基础

量化系统 99% 的时间无人值守，它的可靠性完全由日志与监控决定。个人量化者常见的两个极端：完全没有（出事靠事后翻券商 App 猜），或日志泛滥（每天几个 GB 没人看）。本篇给出分层最小的方案：每一层回答一个问题。

第一层：日志——事后能重建现场

结构化日志优于文本日志。每条记录是带字段的一行（JSON 或键值对），而不是一句散文：

1
2

2026-09-18 09:31:02 [SIGNAL] {"strategy":"mom20","action":"BUY","code":"600519.SH",
  "target_w":0.032,"price":1458.0,"cash":120340.5,"latency_ms":42}

必记的四类事件（对应一次交易的完整生命周期）：

1. 数据事件：行情/财务数据更新到哪个时间戳、缺失了哪些标的——数据断更是大多数「策略今天没交易」的真因；
2. 信号事件：每个目标仓位的计算结果 + 关键中间量（因子值、排名）——事后复盘「为什么买了它」的唯一依据；
3. 订单事件：下单、回报、部分成交、废单、撤单——含本地时间与交易所回报时间，延迟异常的原始证据；
4. 状态事件：进程启动/重启、配置版本、资金账户快照（每日收盘后一条总账）。

分级（DEBUG/INFO/WARNING/ERROR）+ 轮转（按天切割、保留 90 天）+ 日志里绝不打印密钥与完整账号。技术栈：Python 用 logging + structlog，个人项目写文件 + 每日压缩即可；机构的用 ELK/Loki 集中检索（见系统架构 ）。一个进阶习惯：每条日志带「运行指纹」（代码版本 + 数据版本 + 配置哈希）——三个月后任何一条决策都能定位到「哪个版本的程序读了哪个版本的数据」（版本纪律见Git ）。

第二层：监控——事前发现异常

监控回答「现在正常吗」，要盯的不是 CPU 内存这类通用指标（那交给云监控），而是业务健康度指标：

vs 模拟偏离是最被低估的指标：每天让实盘与一个影子模拟盘并行运行，两者收益差的分布一旦漂移，就是执行或数据出了问题——比看绝对收益灵敏得多。它也是区分「策略亏钱」与「系统出错」的第一道分诊（策略亏钱是市场问题，偏离是工程问题，处理人完全不同）。影子盘的实现成本极低：同一份信号代码跑在模拟账户上，只在日志里多一行（见事中风控 ）。

第三层：告警——什么才值得吵醒你

告警的工程学：太多 = 狼来了 = 无人再看。三条铁律：

1. 每个告警必须可行动：收到后明确知道下一步做什么（重启服务/暂停交易/人工核对），做不到的降级进日报；
2. 分级路由：P0（交易中断、风控熔断触发、资金异常）立即电话/短信，P1（数据迟到、成交率低）IM 即时消息，P2（绩效周环比下滑）进日报。个人用 Server 酱/企业微信机器人 + 手机推送即可实现三级；
3. 心跳（dead man’s switch）：不是「出错才报」，而是「预期没发生也要报」——每天 17:05 没收到「今日运行完成」的推送，等同于收到一条 P0。大量真实事故是静默失败（进程死了但没人发错误），心跳是对付它的唯一手段。

与风控的关系：监控是风控的眼睛

本篇的指标体系与事中风控 高度重叠，分工是：监控发现问题 → 风控执行动作。监控发现「实盘 vs 模拟偏离超阈值」只是通知；「当日回撤触及熔断线」则由风控模块自动降仓/平仓，事后留痕。个人实现上可以合并成一个脚本，但逻辑上必须分开：发现（可误报）与动作（不可误触发）用不同的阈值与确认机制。

最小可用清单（个人版，半天工作量）

1
2
3
4
5

□ logging 结构化日志（四类事件全覆盖 + 运行指纹）
□ 每日收盘后一行式日报推送（净值、持仓数、信号数、现金）
□ 心跳推送（固定时间没收到 = P0）
□ 三个 P0 告警：进程死（心跳兜底）、数据过期、PnL 超 4σ
□ 月度回看：本月告警次数、误报率——告警系统自己也要被审计

这套东西的性价比，高于任何额外的一个因子。

关联阅读：事中风控 是监控之上的自动动作层；策略上线流程 定义了监控从第一天就要在位；灾备与故障恢复 处理监控本身挂掉怎么办。