日志采集与传输归纳总结
日志采集和传输，是审计日志系统的第一道关卡。别看它只是“搬砖”，搬不好后面全是脏活。我见过太多项目，加密和查询做得再漂亮，前面采集丢了数据、传输被篡改，最后审计全废了。所以这一章，我把常见方案和坑都整理出来，给你一个能直接用的总结。
采集方式怎么选？
市面上的采集工具很多，但核心思路就几类。我用表格把常用方案列出来，你自己对比着看。
| 工具 | 协议 | 加密支持 | 可靠性 | 我推荐场景 |
|---|---|---|---|---|
| Syslog (RFC 5424) | UDP/TCP | 可加TLS | UDP无确认 | 网络设备、老旧系统 |
| Filebeat | Beats协议 | 内置TLS | TCP + ACK | 文件日志、容器日志 |
| Fluentd | HTTP/TCP | TLS/mTLS | 缓冲 + 重试 | 微服务、多数据源 |
| Logstash | 多种 | TLS/mTLS | 基于TCP | 复杂过滤、ES对接 |
我的建议：选工具别只看功能，要看你团队的运维能力。比如Syslog配TLS，证书管理搞不好就是个坑。我自己更喜欢Filebeat + Fluentd的组合，轻量又灵活。
传输安全不能凑合
审计日志要是明文传，等于把罪证送给别人看。你必须上TLS，最好是mTLS（双向认证）。
我曾经遇到一个项目，只用TLS单向认证，结果中间人伪造了接收端，日志全被偷了。后来改成mTLS，每个采集端都签独立证书，问题才解决。
配置mTLS的要点有几个：
- CA证书统一签发，别用自签名糊弄
- 证书轮换要自动化，手工换迟早出事
- 客户端证书加上CN或SAN标识，方便审计溯源
其实TLS握手时有个小细节——要禁用过时的密码套件。比如RC4、3DES，还有TLS 1.0/1.1。我习惯只允许TLS 1.2和1.3，密码套件用ECDHE + AES-GCM。
传输可靠性怎么保证？
日志丢了，审计就是笑话。但网络抖动、服务重启都是常态。
我总结了三层保障：
- 协议层： 能用TCP就别用UDP。如果非用UDP（比如Syslog），加个可靠传输插件，比如syslog-ng的磁盘缓冲。
- 应用层： 采集端要有本地缓存。我用Filebeat时，会把队列大小设到100MB以上，写入磁盘。一旦网络断了，日志不会丢。
- ACK机制： 接收端收到后必须回确认。别开fire-and-forget模式，那是给审计挖坑。
关键指标：端到端传输成功率必须达到99.99%以上。否则审计人员会来找你喝茶。
压缩与带宽优化
日志量大了，带宽就是钱。尤其跨机房传输，压缩能省一半费用。
我用gzip比较多，压缩率不错，CPU开销也低。配置上注意：
- 压缩级别设为1-3就好，别上9，不然CPU扛不住
- 实时流压缩用Snappy或LZ4，延迟更低
- 如果日志本身已经是二进制格式（比如Protobuf），压缩效果有限，别白费力气
嗯，有个坑提醒你：有些采集工具默认不压缩，你得手动开。比如Logstash的output插件里要配置codec => "gzip"。
整体流程长什么样？
下面这张图是我常用的日志采集传输架构。节点不多，但每个环节都不能省。
实践经验与避坑
最后聊几个实战中容易摔跤的地方。
- 采集端并发问题：我曾经用Logstash同时采集上千个文件，结果内存飙到8G。后来改成Filebeat，每个文件用独立协程，内存降了4倍。
- 时钟同步：审计日志的时间戳必须统一。NTP服务器一定要配好，我见过生产环境因为时间差30分钟，审计链全对不上。
- 重试风暴：接收端挂了，所有采集端同时重试，能把网络打崩。解决方案是增加指数退避，并且设置最大重试间隔。
测试环境压一把，看采集端在5倍流量下会不会丢日志。我没少在这上面栽跟头——开发环境一路绿灯，上线第一天就丢数据。
日志采集传输看起来简单，但它决定了整个审计系统的底线。做好加密、缓存、健壮性，后面查询优化才有意义。不然你查出来的数据都是假的，还不如不查。