📚 课程目录第3章日志收集与存储策略

第三章：日志收集与存储策略归纳总结

密码套件变更日志这个东西，说实话，很多团队一开始根本不重视。我见过不止一次，出了安全事件才想起来“诶？上次改 cipher 是哪天来着？”。日志要是没收集好，或者存了几天就过期，那巡检就是空中楼阁。这一章咱们就把收集和存储的策略聊透。

3.1 收集策略：全量还是增量？

先说大方向。我个人习惯把收集模式分成两类：全量快照和增量事件流。

全量快照：每隔 N 分钟/小时，把当前所有密码套件配置 dump 一遍。好处是简单、无遗漏；坏处是数据量大，而且相同配置反复存，存储成本高。
增量事件流：只记录变更事件——谁、在什么时间、把什么 cipher 改成了什么。比如 OpenSSL 的 SSL_CTX_set_cipher_list 调用被 hook 后输出一行日志。

我在项目里踩过坑。一开始我们只用全量快照，结果一个月下来，ES 集群磁盘报警。后来改成增量 + 每日快照做校验，存储量直接降到原来的 1/5。你想想看，如果每天几百万次心跳连接，每次都 dump 一次全长配置，那简直是灾难。

推荐组合：增量事件流做主存储，全量快照做每日基线校验。这样既保证实时性，又能兜底漏事件的情况。

3.2 采集方式：推 vs 拉

这是老生常谈，但在 TLS 场景下需要特别留意。大部分服务器端的密码套件变更来自配置管理工具（Ansible、Puppet 等）或运维脚本。它们通常能主动推送日志。但有些嵌入式设备或老系统，不支持 agent，只能用拉模式。

采集方式	常见协议	适用场景	我的一点经验
推（Push）	Syslog / HTTP POST / Kafka Producer	Nginx、Apache、负载均衡等标准服务	配置简单，但要注意日志风暴
拉（Pull）	SSH + 定时脚本 / Prometheus exporter	嵌入式设备、遗留系统	我遇到过拉取失败导致漏采半天数据，建议加重试和告警

我记得有一次做金融客户的项目，他们的 F5 负载均衡不支持 syslog 推送，只能 SSH 上去 grep 配置文件。我们写了个轮询脚本，每 5 分钟拉一次。结果有个节点 SSH 密钥轮换没同步，脚本挂了 3 小时才被发现。后来加上健康检查和自动重连才解决。

3.3 存储策略：存什么、存多久、怎么查

日志存进来只是第一步，关键是怎么让它能高效地被巡检。我建议至少包含以下字段：

时间戳：精确到毫秒，时区统一用 UTC
源主机：IP + 主机名
进程/服务：例如 nginx、haproxy、openssl
变更类型：新增、删除、修改、回退
密码套件列表：全量或增量 diff
操作人/工具：谁触发的变更（如果可获取）

下面是我常用的一套存储方案，直接用的自建 ELK 栈，当然你也可以用云上的托管服务。

{
  "@timestamp": "2025-03-21T14:22:33.456Z",
  "host": "web-01.example.com",
  "process": "nginx/1.24.0",
  "change_type": "modify",
  "tls_version": "TLSv1.3",
  "ciphers_old": ["TLS_AES_128_GCM_SHA256", "TLS_CHACHA20_POLY1305_SHA256"],
  "ciphers_new": ["TLS_AES_256_GCM_SHA384", "TLS_CHACHA20_POLY1305_SHA256"],
  "operator": "ansible-tower",
  "message": "Cipher list updated due to security policy change"
}

存储周期方面，我的建议是：

热存储（如 ES 或 ClickHouse）：保留 30 天，用于日常巡检和实时告警
温存储（如压缩后存对象存储）：保留 1 年，用于季度或年度合规审计
冷归档：超过 1 年的数据，按合规要求保留（有些行业要求 3 年或 5 年）

注意：千万别把热存储周期拉太长。我见过一个团队把 ES 索引保留设为 180 天，结果集群每天写入几百 GB，查询慢到超时。巡检脚本跑一次要 20 分钟，根本没法用。热存储 30 天足够了，历史数据走温存储或冷存储。

3.4 工具链选择与实战

说白了，工具没有最好的，只有最适合你环境的。我这些年用过几套组合，简单列一下：

方案	采集端	传输/缓冲	存储与分析	一句话评价
方案 A（轻量）	Rsyslog / syslog-ng	直接写文件或发到 Logstash	Elasticsearch + Kibana	上手快，适合小于 100 台设备
方案 B（高吞吐）	Filebeat / Fluentd	Kafka 作为缓冲	ClickHouse + Grafana	吞吐量高，查询极快，就是运维有点重
方案 C（云原生）	云日志 agent（如 AWS CloudWatch Agent）	云自带队列	CloudWatch Logs / S3 + Athena	省心，但长期存成本略高

我个人现在偏好方案 B。为什么？因为 TLS 密码套件变更的日志量其实不会特别大（不像全链路追踪那种海量），但巡检要求低延迟、高精确度。Kafka 缓冲能防止日志丢失，ClickHouse 的 SQL 查询能力对巡检场景非常友好。我们曾用方案 A 遇到过 Logstash 挂掉导致日志积压，把 ES 写爆了……嗯，后来还是上了 Kafka。

3.5 避坑指南

说几个我实实在在踩过的坑：

不要忽略日志轮转：如果采集端不自己切分日志，磁盘很快会被写满。我习惯在 Rsyslog 配置里加 $outchannel 自动轮转，或者让 Filebeat 的 close_inactive 参数设置合理。
时间戳不对齐：服务器时钟不同步，日志时间会乱。我曾经排查一个变更回滚事件，发现 A 机记录在 B 机之后，后来才发现 NTP 没配好。务必先解决时钟同步。
存储压缩与索引：ES 里如果不对 ciphers_old、ciphers_new 这种数组字段做优化，查询会很慢。我一般会提前把 cipher 列表转成字符串做 keyword 索引，或者用 ClickHouse 的 Array 类型。
权限与审计：日志本身包含敏感信息（比如哪些主机用了弱密码套件）。存储时一定要做访问控制，我至少有两次被安全团队追问谁看过日志。

3.6 整体流程一览

关于存储，我最后再啰嗦一句：定期验证数据完整性。我有一次想查半年前的变更记录，发现 S3 上的归档文件因为轮转脚本 bug 少了一整周的数据，差点被合规罚款。从那以后我加了个每日校验任务，用 md5sum 对比归档前后的日志条数。这种基础工作，看着笨，但真能救命。