一、日志体系总览：交易系统日志的价值、分级标准与字段规范

大家好，我是老张。做量化交易系统运维这些年，我踩过最大的坑，就是日志没写好。

你想想看，一个交易系统跑着跑着突然出问题了——订单没成交、仓位对不上、甚至直接崩了。这时候你怎么办？靠猜？靠重启？

嗯，真正靠谱的做法，就是看日志。

日志是什么？说白了，就是系统在每一个关键时刻留下的「脚印」。好的日志体系，能让你在几分钟内定位到问题根因。差的日志体系……我见过有人花了一整周，最后发现是配置文件里少了个逗号。

1.1 交易系统日志的价值

我个人习惯把日志的价值总结为三点：

• 故障定位——系统出问题，日志是第一现场。没有日志，你就是盲人摸象。
• 行为审计——谁在什么时间做了什么操作？日志里一清二楚。合规审查时，这就是铁证。
• 性能分析——每个接口的耗时、每个订单的处理链路，日志都能告诉你瓶颈在哪。

我在项目中遇到过一件事：某天凌晨，策略突然停止下单。运维同事重启了三次，每次过半小时又停了。后来我查了日志，发现是数据库连接池耗尽，但异常被吞掉了——因为日志级别设成了ERROR，而连接超时只打了WARN。你看，日志级别没设对，也能坑死人。

1.2 日志分级标准

日志分级这件事，很多团队做得太随意。我见过有人把所有信息都打INFO，也见过有人把「用户登录成功」打成了FATAL……

这里我给出一个实战中验证过的分级标准：

级别	含义	使用场景	我个人的建议
DEBUG	调试信息	开发环境、临时排查问题	生产环境默认关闭，否则日志量会爆炸
INFO	正常流程信息	订单提交成功、行情接收正常	记录关键业务节点，别什么都打
WARN	警告，但系统可继续运行	网络抖动重试、行情延迟超过阈值	这是最容易忽略的级别，但往往藏着隐患
ERROR	错误，需要人工介入	下单失败、数据库连接断开	必须包含足够上下文，方便定位
FATAL	致命错误，系统即将退出	内存溢出、核心配置加载失败	触发后建议自动发告警给值班人员

1.3 日志字段规范

日志光有级别还不够，字段必须规范。我见过最离谱的日志长这样：

2024-01-15 10:23:45 下单失败

你告诉我，哪个订单？哪个策略？哪个用户？全都没有。

一个合格的交易系统日志，至少应该包含以下字段：

• 时间戳——精确到毫秒，最好带时区。跨时区交易时，这个特别重要。
• 线程ID——多线程环境下，帮你追踪并发问题。
• 交易ID——这是灵魂字段。一个订单从生成到成交，所有日志都应该带上同一个交易ID。
• 类名/方法名——快速定位代码位置。
• 消息体——描述发生了什么，以及相关的上下文数据。

我推荐的标准格式是这样的：

[2024-01-15 10:23:45.123][Thread-12][TXID:ORD202401150001][OrderService.submitOrder] INFO - 订单提交成功 | 合约: BTC-USDT | 方向: BUY | 数量: 0.1 | 价格: 42000.5

你看，每一段信息都清晰可辨。出了问题，直接按交易ID一搜，整条链路就出来了。

1.4 日志体系的核心逻辑

说了这么多，我画了一张图，帮你把日志体系的整体结构理清楚：

这张图展示了一个完整的日志链路：从各个模块产生日志，经过分级过滤，按照规范字段格式化，最终落地到存储系统。每一步都环环相扣，缺一不可。

1.5 实战中的几个建议

最后，分享几个我这些年总结出来的实战经验：

1. 日志不要打太多——INFO级别一天几百万条很正常，但DEBUG级别一天可能上亿条。磁盘撑不住，查询也慢。
2. 交易ID必须透传——从接收到订单请求开始，生成一个唯一ID，贯穿整个处理链路。这是追踪问题的命脉。
3. 异常日志要带堆栈——光打一句「下单失败」没用，必须把异常堆栈和关键参数一起打出来。
4. 敏感信息脱敏——API Key、密码这些，绝对不能出现在日志里。我曾经见过有人把私钥打到了日志里……后果很严重。

嗯，这一章就到这里。日志体系是基本功，但往往越基础的东西越容易被忽视。希望你能从这一章开始，真正重视起日志来。

---