📚 课程目录第3章日志管理基础

日志管理基础：日志级别、日志轮转、日志存储

日志这东西，看起来简单，真踩过坑才知道痛。我刚开始做密码迁移项目时，觉得日志嘛，随便打打就行。结果合规审计一来，查缺日志、轮转丢数据、存储违规……差点被扣上“不合规”的帽子。今天咱们就把这三个基础打扎实。

日志级别——你该在什么时候打什么日志

日志级别不是摆设。选对了，问题定位快得像开了透视；选错了，要么被海量信息淹死，要么关键线索全丢。

标准的日志级别从低到高：DEBUG、INFO、WARN、ERROR、FATAL。我个人的习惯是：生产环境默认开到 INFO，DEBUG 只在临时排障时开，排完立马关掉。为什么？你想想看，DEBUG 日志量大概是 INFO 的 10~100 倍，磁盘撑爆不说，检索都卡。

级别	含义	生产环境建议	典型场景
DEBUG	调试信息，细粒度	禁止 / 仅在排障时开启	跟踪密钥生成每一步
INFO	一般运行状态	开启，但注意频率	迁移任务启动、完成
WARN	异常但可自动恢复	开启，用于告警	重试次数超阈值、网络抖动
ERROR	功能失败，需人工介入	必须开启	密钥解密失败、数据库连接断开
FATAL	系统不可用，立即止损	必须开启，通常触发告警	HSM 硬件故障、数据损坏

一个小技巧：在密码迁移中，WARN 级别我通常用来记录“重试”。比如 RSA 密钥对生成第一次失败，重试成功就记 WARN；如果重试也失败，升为 ERROR。这样既能预警，又不会像 ERROR 那样直接触发报警疲劳。

日志轮转——别让日志撑爆你的磁盘

我说一个真实教训：之前在某个金融项目里，日志没配轮转，结果一个月后磁盘写满了，迁移进程直接挂掉。合规审计时，日志断档了整整 12 小时，差点被认定为“故意销毁证据”。

日志轮转的核心参数有三个：轮转策略、最大文件大小、保留份数。

推荐配置（以 Linux logrotate 为例）：

/var/log/keymigration.log {
    daily
    rotate 90
    compress
    delaycompress
    maxsize 200M
    missingok
    notifempty
    dateext
    postrotate
        systemctl reload syslog >/dev/null 2>&1 || true
    endscript
}

解读：每天轮转一次，如果文件提前超过 200M 也会触发；保留 90 天；旧日志压缩；用日期命名方便检索。

我这里给你整理三种常见轮转策略的对比：

策略	触发条件	适用场景	注意点
按时间	固定周期（如每天）	合规要求按天归档	日志量小可能一天就几 KB，浪费存储
按大小	文件达到阈值	日志流量波动大	可能一天轮好几次，索引碎片化
混合（推荐）	时间和大小谁先到谁触发	生产环境通用	需配合 maxsize 和 daily 参数

曾经踩过的坑：我写过一条轮转规则，忘记加 delaycompress，结果轮转后马上压缩，导致还在写的进程找不到原文件而产生“日志丢失”错误。切记：正在写入的日志不要立即压缩，延迟一个周期。

日志存储——合规视角下的保存策略

日志存储不只是找个地方放，它涉及持久性、加密、访问控制、合规保留期。我负责过的密码迁移项目，监管要求日志至少保存 6 年，且必须防篡改。

存储架构我建议分三层：

热存储：本地磁盘或 SSD，保留最近 7 天日志，方便快速检索。
温存储：NAS / 对象存储（如 MinIO），保留最近 1 年，可压缩归档。
冷存储：磁带 / 低成本对象存储（AWS Glacier 类），满足合规长期保存。

另外，存储时必须考虑加密——不仅是传输加密（TLS），还有存储加密。我习惯使用 AES-256-GCM 对日志文件进行逐文件加密，密钥由 KMS 管理，解密日志需要单独授权。

实战小贴士：合规审计时，审计员经常要求“日志不可修改”。我的做法是把日志先写到WORM（Write Once Read Many）存储，比如 AWS S3 Object Lock 或本地磁带库的 WORM 模式。这样任何人都无法事后篡改。

本章知识结构图

下面这张图帮你理清日志管理的三个核心环节以及它们之间的关系：

一句话总结本章核心：日志级别控粒度，日志轮转保容量，日志存储护合规。三个环节串起来，才是完整的日志管理体系。我在审计中被问得最多的就是“你们日志到底怎么保存的？”——能把这三点讲清楚，合规基本不慌。