日志系统架构：从产生到查询，一条完整的链路

日志系统这件事，说白了就是一条流水线。日志从应用里冒出来，经过传输、存储，最后被人翻出来查问题。我这些年转过不少项目，每次改日志格式都得把这条链路从头到尾捋一遍——哪个环节改了，后面全得跟着动。国密改造也一样，不是光改改日志内容就完事，你得清楚每个环节该怎么适配。

这一章，我就带你完整走一遍这条链路。你想想看，日志生命周期的四个阶段：产生 → 传输 → 存储 → 查询。每个阶段都有它的坑，也有它的适配策略。

日志产生：源头在哪里

日志产生是最容易忽略适配的地方。大家往往只盯着后台的日志文件，却忘了前面的代码里到底输出了什么。

常见的日志来源

• 应用日志 —— 业务代码里打的 info、error、debug，格式最灵活。
• 系统日志 —— syslog、事件日志，格式相对固定，但字段可以扩展。
• 安全设备日志 —— 防火墙、IPS、堡垒机，通常走 syslog 或者特定协议。
• 中间件日志 —— Nginx、Redis、Kafka 自己的访问日志和运行日志。

我在项目里碰到过一个案例：业务系统已经按国密要求改了日志内容，加了签名字段，但日志产生的那个 SDK 版本太老，签名字段的值一直是空字符串。排查了三天才发现是 SDK 没升级。这种坑，我后来总结出一个习惯：在产生阶段就做格式校验，别等到存储了才发现。

日志传输：怎么安全送出去

日志从应用服务器到集中存储，中间这段路最容易出事。传输协议、队列、网络抖动、丢包……每个点都可能把日志搞丢或者搞乱。

常见的传输方式

方式	协议/组件	特点	国密改造关注点
直接推送	TCP/UDP	实时性强，但易丢	传输层加密（国密TLS）
消息队列	Kafka, RabbitMQ	削峰填谷，可靠	消息签名，防止篡改
文件转存	rsync, S3	离线传输，周期长	文件完整性校验（SM3/SM4）
自定义	HTTP/gRPC	灵活但开发量大	请求签名 + 加密

我记得有一次，客户要求日志传输必须签名，我们用了 RabbitMQ，但签名是在生产者应用里做的。结果消费者收到消息后验签失败，排查发现是 RabbitMQ 对消息做了序列化，导致签名前后的二进制不一致。那次之后我明白了：签名必须在最终传输的二进制上做，不要在应用层自己拼字符串签名。

日志存储：如何可靠保存

日志存储是整条链路里改动最大的部分。原来的纯文本日志，改成带签名、加密的格式，存储系统也得跟着变。我见过很多团队只改了应用和传输，存储还是老的文本文件，最后审计时发现日志已经被篡改过，但没任何报警。

存储选型的对比

存储类型	国密改造前的做法	国密改造后的做法	优点	缺点
本地文件	普通文本，无校验	日志行末尾追加SM3摘要	简单，兼容老系统	查询性能差，难做高级分析
ES集群	明文索引	字段加密存储，签名单独字段	检索快，支持全文搜索	加密后索引可能需要重建
数据库	表字段明文	敏感字段SM4加密，附带SM3签名	关系查询方便	写入压力大，加密影响性能
对象存储	文件无加密	每个文件带国密签名的元数据	容量大，成本低	适合归档，不适合实时查询

嗯，这里要注意：如果你用ES做日志存储，国密改造后尽量保持原始日志的明文和签名同时存储。我用过一个方案：原文写在原始字段里，签名字段单独建一个 keyword 类型，查询时可以快速验证某一条日志有没有被改过。

日志查询：如何快速定位

查日志是最后一环，也是用户体验的体现。国密改造后，查询不只是搜关键词，还得能验证日志的真伪。我在项目里遇到一个场景：安全审计人员需要逐条验证日志签名，如果查询界面没有提供“验签”按钮，他只能拉到本地用脚本验，效率极低。

查询阶段要解决的两个核心问题

1. 数据可见性 —— 加密后的日志字段查询前需要先解密。如果直接在查询条件里用明文搜，存储端必须知道加密方式。我建议：查询接口封装成专门的日志服务，客户端传明文条件，服务端解密后匹配。
2. 完整性验证 —— 每次查询结果返回时，附带该条日志的签名。客户端可以随时点击“验签”按钮，验证签名是否匹配。这个功能看似简单，但很多项目都忽略了。

全链路关系图

以下这张 SVG 图，把四个阶段以及每个阶段的关键适配点串在一起，方便你对照理解。

看完这张图，你应该能感受到：国密改造不是给日志加个字段那么简单。它是一条链上的四个节点都要动的手术。我个人觉得，只要把产生和存储两个节点最前面的适配做好，后面传输和查询的改动量会小很多。但很多团队反过来，先改传输和查询，结果发现产生阶段格式不对，又回头改，反而更折腾。