一、量化日志体系概述：日志的价值、分类与级别定义
做量化系统这些年，我越来越觉得日志这东西，就像飞机的黑匣子。
平时你可能根本想不起它，但一旦出事——策略跑偏、交易延迟、风控误杀——你第一个要找的就是它。说白了，日志就是系统的「记忆体」。没有它，你连复盘都无从下手。
1.1 日志的价值：不只是「记流水账」
很多人觉得日志就是打印点信息，方便调试。其实不然。在量化系统里，日志的价值体现在三个层面：
- 故障定位：系统崩了，是网络断了？还是数据库连不上？日志能告诉你第一现场发生了什么。
- 行为审计：谁在什么时候下了什么单？风控规则有没有被触发？这些都得靠日志还原。
- 性能分析：一笔订单从生成到成交，每个环节耗时多少？日志里的时间戳就是最好的性能指标。
我个人的经验：有一次生产环境出现「幽灵订单」，明明没下单，系统却显示成交了。查了两天没头绪，最后是翻出了网关层的debug日志，发现是消息队列重复消费导致的。如果没有那行日志，这个bug可能永远找不到。
1.2 日志分类：三类日志各司其职
量化系统的日志，我习惯分成三大类。你想想看，一个交易系统无非就是三件事：业务执行、系统运行、风险控制。日志分类也是围绕这三块来的。
| 日志类别 | 核心内容 | 典型场景 |
|---|---|---|
| 交易日志 | 订单生命周期、成交明细、策略信号 | 「订单ID: 1001 已发送至交易所」 |
| 系统日志 | 服务状态、资源使用、异常堆栈 | 「内存使用率 85%，触发告警阈值」 |
| 风控日志 | 规则检查、限额校验、黑白名单 | 「用户A 单笔下单量 1000手，超过上限 500手，已拦截」 |
交易日志
这是量化系统的核心日志。每一笔订单从生成、发送、确认到成交，每一步都要记录。我见过不少团队只记录最终成交结果，忽略了中间状态。结果出了问题，根本不知道是策略没发单，还是交易所没收到。
一个小建议：交易日志里一定要带上「请求ID」和「时间戳（精确到毫秒）」。这样你才能把分散在不同服务里的日志串起来，还原完整的交易链路。
系统日志
系统日志关注的是「机器能不能扛得住」。CPU、内存、网络IO、磁盘空间，这些指标直接决定了你的策略能不能稳定运行。我记得有一次，策略回测表现很好，一上实盘就亏钱。查了半天，发现是服务器磁盘IO被打满了，行情数据写入延迟，导致策略信号滞后了200毫秒。
风控日志
风控日志比较特殊。它不仅要记录「触发了什么规则」，还要记录「为什么触发」。因为风控误杀是常有的事，你得能回溯：是规则设得太严了？还是行情波动异常？
注意：风控日志建议单独存储，不要和交易日志混在一起。原因很简单——风控日志可能涉及合规审计，需要长期保留，而交易日志通常只保留30天。
1.3 日志级别定义：该用什么级别，心里要有数
日志级别这事，看似简单，但我在项目中踩过不少坑。级别设得太高，关键信息丢了；设得太低，日志刷屏，真正的问题反而被淹没了。
我一般用这五个级别，每个级别都有明确的「使用场景」：
| 级别 | 含义 | 使用场景 | 示例 |
|---|---|---|---|
| FATAL | 致命错误 | 系统无法继续运行，必须人工介入 | 数据库连接池耗尽、核心服务崩溃 |
| ERROR | 错误 | 功能不可用，但系统还能跑 | 下单失败、行情源断开 |
| WARN | 警告 | 潜在问题，需要关注 | 网络延迟偏高、内存使用率超过80% |
| INFO | 信息 | 关键业务流程节点 | 订单已发送、策略已启动 |
| DEBUG | 调试 | 开发/排查问题时使用 | 变量值、函数调用参数 |
嗯，这里要注意一点：生产环境不要开DEBUG级别。我曾经接手过一个项目，生产环境日志级别设成了DEBUG，结果一天产生了200GB日志，磁盘直接打满，系统挂了。你想想看，这得多冤。
避坑指南：我曾经在风控模块里，把「单笔下单量超过阈值」打成了WARN级别。结果有一次行情剧烈波动，这个警告疯狂刷屏，把真正的ERROR日志全冲走了。后来我改了——所有风控拦截行为，至少用ERROR级别。因为风控一旦触发，就意味着有异常情况，必须引起重视。
1.4 日志体系的核心逻辑
说了这么多，其实日志体系就围绕一个核心：可追溯、可定位、可分析。下面这张图能帮你快速理解整个体系的结构：
从这张图可以看出来，日志体系其实是一个「自下而上」的链路：先有分类，再定级别，然后统一采集，最后集中存储分析。每一步都有讲究，缺一环都不行。
一个小技巧：刚开始搭建日志体系时，别想着一步到位。我建议先从交易日志和ERROR级别开始，跑通了再加其他分类和级别。这样风险最小，也最容易看到效果。
公众号:蓝海资料掘金营，微信deep3321