问题 / 你大概正在遇到
出事想查三个月前的日志,发现已经没了。
一、为什么会反复发生
- 默认保留 7 天
- 日志和业务数据同机,磁盘满了被清
- 没有分级:所有日志一样对待
二、四步做法
- 三类分级:安全日志 12 个月、业务日志 6 个月、调试日志 7 天
- 安全日志单独存储,只追加不修改
- 设容量告警,别等磁盘满
- 每季度抽查一次能否检索
三、对照表
| 类型 | 保留 | 原因 |
|---|---|---|
| 登录/权限变更 | 12 个月 | 追责与合规 |
| 业务操作 | 6 个月 | 排障 |
| 调试日志 | 7 天 | 成本高、价值低 |
四、常见问题
云服务默认保留够吗?
多数只有 7–30 天,要主动配置导出。
要不要存全量?
不必,存关键字段即可,体积能降一个量级。
五、怎么落地
上面这些做法,用一张表 + 一个看板就能先跑起来:免费模板里有窗口台账、日报、审批队列与周会议程; 跑通之后想固化成一屏,再看在线看板与定价。
我们不写客户案例(当前 ARR $0,没有可公开的付费客户),所以文中只给方法与边界,效果需要你自己测。
六、日志方案的最小落地清单
不用买系统,先做四件事就能有明显的追查能力:
- 单独目录:日志写到独立磁盘或独立路径,与业务数据分开,避免磁盘写满时被一起清掉。
- 每日打包:按天打包成 gzip,命名带日期,存档到另一台机器或对象存储。
- 保留策略:安全类 12 个月、业务类 6 个月、调试类 7 天,用脚本自动清理,不要靠人记。
- 每月抽查:随机挑一天,试着查「某人在 14:00 改了什么」,查不到就说明字段缺失。
第四步最关键也最常被跳过——很多人搭了日志,真出事时才发现没记录操作对象,只能看到「登录成功」。
RELATED // 继续读
相关的几篇(含跨分类)
- 减少无效沟通:把「问进度」换成「看状态」 · 效率提升
- AI 对话工具怎么选:按「数据能不能出去」先分流 · 对比与选型
- 工时工具怎么选:先想清楚「给谁看」 · 对比与选型
- AI 转型多久见效:8 周看第一个信号,三个月看结论 · AI 转型