日志采集与传输
日志采集与传输，是整个审计巡检链条的第一道关卡。数据源如果从源头就歪了，后面再怎么分析也是徒劳。我习惯把这一章拆成三个核心环节：采集代理、传输协议、数据完整性。这三块彼此关联，但出现问题时的表象和排查手段完全不同。
采集代理——第一道防线
采集代理就是部署在目标机器上的守护进程，负责读取日志文件、过滤无关内容、格式化后再推送到服务端。听起来简单，但实际踩坑的地方不少。
最常见的两个问题：日志积压和资源耗尽。我个人习惯在代理启动参数里加上--max-buffer-size 256MB和--queue-type memory，但仅仅这样还不够。我曾经遇到过一台机器日志写入速度远超代理消费速度，最终磁盘被临时缓冲文件撑满。
--disk-spool-limit，导致代理把缓冲文件写到了根分区，整个系统响应变慢。从那以后我强制所有代理必须搭配独立的日志缓冲盘，并设置配额告警。
采集代理另一个常见坑是权限不足。有些代理以低权限用户运行，无法读取/var/log/audit/下的审计日志。你应该在部署时检查用户组是否在adm或systemd-journal组里。
还有过滤规则写错导致的丢日志。我习惯先在测试环境用--dry-run模式跑一遍，确认过滤出来的日志行数和预期一致，再推送到生产。
代理选型对比
| 特性 | Filebeat | Fluentd | Rsyslog |
|---|---|---|---|
| 内存占用 | 低 (~30MB) | 中 (~100MB) | 低 (~20MB) |
| 缓冲机制 | 内存+磁盘 | 内存+插件磁盘 | 内存+队列 |
| TLS支持 | 原生 | 需插件 | 原生 |
| 重传策略 | 指数退避 | 固定间隔 | 线性退避 |
选择哪种代理取决于你的环境规模。几百台以内用rsyslog完全够，跨数据中心我建议Filebeat，它的TLS握手和重传实现更成熟。
传输协议——TLS/HTTPS不能只配个证书
日志传输必须加密，这个没有商量余地。但很多团队只是简单地启用了TLS，然后发现偶发断连、重传风暴，甚至数据泄露。
我印象很深的一次：某项目日志传输频繁中断，排查了一整天，最后发现是客户端系统时间比服务端快了3分钟。TLS握手时会检查证书有效期，时间偏差直接导致握手失败。解决方法很简单——用NTP统一校时，并且在代理配置里加上--tls-skip-verify false（别为了省事设true）。
HTTPS相比自定义TLS，最大的优势是可以用现成的Web反向代理（比如Nginx）做负载均衡和访问控制。但注意HTTPS的额外开销：每次连接需要TCP三次握手+SSL握手，日志量大时连接复用就很关键。我个人习惯在代理里开启keepalive，超时时间设为60秒。
传输协议参数对照
| 参数 | TLS 1.2 | TLS 1.3 | HTTPS (HTTP/2) |
|---|---|---|---|
| 握手延迟 | 2-RTT | 1-RTT | 1-RTT (TLS1.3) |
| 推荐加密套件 | ECDHE-RSA-AES128-GCM-SHA256 | TLS_AES_128_GCM_SHA256 | 同TLS1.3 |
| 连接复用 | 需应用层实现 | 0-RTT (有重放风险) | 支持多路复用 |
| 日志场景适用性 | 经典可靠 | 低延迟推荐 | 高并发推荐 |
如果你们的日志量每秒超过10万条，我建议直接上HTTP/2 over TLS，多路复用能显著减少连接数。但别忘记配置max_concurrent_streams，否则一个慢日志会阻塞其他流。
数据完整性保证——校验与重传
日志传输过程中可能发生丢包、重复、乱序。你需要一套机制来保证最终存储在服务端的日志和源头发出的完全一致。说白了，就是校验和重传。
校验通常有两种方式：
- 基于消息的校验：每条日志附上SHA256哈希，服务端收到后计算对比，不一致就丢弃并请求重传。
- 基于链式哈希：每条日志的哈希包含上一条的哈希值，形成哈希链。这样一旦中间有任何篡改或丢失，整条链断裂。适合密文审计等高安全场景。
重传机制也很关键。我曾经遇到一个坑：代理在收到服务端NAK后立即重传，而服务端还在处理前一批数据，结果重传的数据和原有数据混在一起，造成乱序。正确的做法是使用序列号+滑动窗口，类似TCP的机制。每条日志有一个单调递增的SeqID，服务端按SeqID排序，缺口超过窗口大小就触发重传。
SeqID（64位递增整数）、Timestamp（微秒级）、Checksum（当前日志的SHA256）。服务端收到后先校验Checksum，再按SeqID写入有序缓冲区，最后批量刷盘。
常见完整性故障及根因
| 故障表现 | 可能原因 | 排查方向 |
|---|---|---|
| 日志缺失条数 | 采集代理缓冲区溢出 | 检查代理内存限制和磁盘溢出策略 |
| 日志内容被截断 | 传输层MTU限制，或TCP分段重组问题 | 在代理端启用--max-message-size 1MB并检查TCP分段 |
| 大量重复日志 | 应用层ACK丢失导致代理重传 | 检查网络延迟和代理的ACK超时设置 |
| 乱序严重 | 服务端多线程写未加SeqID排序 | 在写入前按SeqID排序，或使用单线程写 |
最后说一个很多人忽略的点：数据完整性不只在传输阶段，还有一个容易被忽视的阶段——存储前的验证。服务端接收后、写入持久化存储前，应该再做一次校验。我见过一个案例：代理端校验通过，但服务端内存中Data Corruption导致日志字段错乱。解决方案是在服务端的写入队列里加一个checksum_validator拦截器，每个消息入库前重新计算哈希。
本章知识体系：日志采集与传输流程
下面这幅图涵盖了从日志生成到服务端存储的完整链路，重点关注采集代理、TLS传输、完整性校验三个关键环节。
好了，这一章的核心就这些。采集代理要配置得当，TLS要双向认证，完整性要校验到应用层——这三板斧砍下去，日志传输链路基本上就稳了。如果你在实际巡检中遇到日志漏采、传输中断或内容不一致，优先检查代理配置和证书，不要一上来就怀疑网络。我吃过不少这方面的亏，希望你能少走弯路。