2. 日志数据类型：订单日志、交易日志、系统日志、风控日志、审计日志的定义与区别

做高频交易系统，日志这东西，说白了就是你的「黑匣子」。

我见过不少团队，一开始觉得日志嘛，随便打打就行。结果呢？出问题的时候，翻遍所有文件都找不到线索。那种感觉，就像飞机失事了才发现黑匣子没装电池——太要命了。

今天咱们就把高频交易里最常见的五类日志掰开揉碎讲清楚。你想想看，一个订单从客户端发出来，到最终成交，中间要经过多少环节？每个环节都会产生日志，但它们的用途完全不同。

2.1 订单日志：交易的「出生证明」

订单日志记录的是最原始的动作——谁、在什么时间、想买什么、多少钱、多少量。

我个人习惯把订单日志比作「出生证明」。它记录了订单从诞生到消亡的全过程。包括订单的创建、修改、撤销、拒绝等所有状态变更。

我在项目中遇到过一件事：某次回测结果和实盘差距巨大，查了两天没头绪。后来我翻了订单日志，发现回测系统里订单类型写错了，把IOC写成了FOK。嗯，就这一个字段的差异，导致整个策略失效。从那以后，订单日志的每个字段我都要求做校验。

2.2 交易日志：成交的「户口本」

交易日志和订单日志容易搞混，但其实它们分工明确。订单日志管「想做什么」，交易日志管「实际发生了什么」。

说白了，交易日志是交易所撮合引擎返回的成交确认。它记录的是「你的订单在什么时间、以什么价格、成交了多少」。

交易日志还有一个重要功能——对账。每天收盘后，系统会把交易日志和券商/交易所的结算数据做比对。我曾经遇到过一次，因为网络延迟导致成交回报重复发送，交易日志里多了一条记录。要不是对账发现了，那笔虚增的持仓第二天开盘就得爆仓。

2.3 系统日志：系统的「体检报告」

系统日志记录的是基础设施层面的信息。包括进程启动/停止、内存使用率、CPU负载、网络延迟、磁盘IO等。

你可能会问：「这些和交易有什么关系？」关系大了去了。我见过一个案例，某天策略突然频繁报错，查了半天发现是磁盘空间满了，日志写不进去导致系统崩溃。这就是典型的系统日志没监控到位。

我个人习惯把系统日志按模块拆分：

• 硬件层： CPU温度、风扇转速、电源状态
• 操作系统层： 进程状态、文件描述符、网络连接数
• 中间件层： 消息队列积压、数据库连接池、缓存命中率
• 应用层： 线程池状态、GC日志、API调用耗时

2.4 风控日志：系统的「刹车记录」

风控日志，嗯，这个最特殊。它记录的是「系统主动干预」的行为。

为什么特殊？因为其他日志都是被动记录，风控日志是主动触发。当系统检测到异常行为时，风控模块会介入，比如：

• 单笔订单金额超过阈值
• 日内累计交易量超标
• 自成交检测触发
• 价格偏离市场均价超过N%
• 撤单率过高

风控日志必须包含「触发原因」和「处置动作」。比如：「自成交检测触发，订单ID=123456，已拒绝」。这样事后审计时，才能说清楚为什么某个订单被拦下来了。

2.5 审计日志：合规的「呈堂证供」

审计日志是给监管看的。它记录的是「谁在什么时间、通过什么系统、做了什么操作」。

审计日志和前面几种日志最大的区别在于——它不能修改，不能删除，甚至不能追加。一旦写入，就是只读的。我见过有些团队用普通文件存审计日志，结果运维人员不小心删了，那麻烦就大了。

审计日志通常包含：

• 用户登录/登出记录
• 权限变更记录
• 策略参数修改记录
• 系统配置变更记录
• 数据导出/导入记录
• 管理员操作记录

2.6 五类日志的关系图

下面这张图展示了五类日志在高频交易系统中的位置和关系。你可以看到，订单日志和交易日志是核心业务流，系统日志是基础设施支撑，风控日志是安全屏障，审计日志是合规底线。

2.7 实际项目中的日志策略

说了这么多理论，来点实际的。我在设计日志系统时，一般遵循这几个原则：

1. 分类存储： 五类日志分别写入不同的文件或不同的数据库表。千万别混在一起，否则查询效率低到令人发指。
2. 分级保留： 订单日志和交易日志保留30天，风控日志保留90天，审计日志保留至少5年（监管要求）。系统日志保留7天就够了，除非要排查历史问题。
3. 独立通道： 风控日志和审计日志使用独立的IO线程和独立的磁盘。这样即使系统负载高，这两类日志也不会被其他日志阻塞。
4. 实时告警： 风控日志一旦写入，立即触发告警。我见过一个系统，风控日志写进去了，但告警延迟了3秒，结果那3秒内又触发了多次违规操作。

好了，这五类日志的定义和区别，咱们就聊到这儿。记住一句话：日志系统设计得好不好，直接决定了你出问题后能不能快速定位、能不能通过合规检查。别等到火烧眉毛了才想起来补日志，那时候就晚了。