日志断档怎么判断
日志断档既可能是正常轮转，也可能是人为清除。判断时要用多个维度交叉：按小时统计条目数找出空洞时段、用 stat 看文件 mtime 与内容时间是否矛盾、对比当前文件与轮转归档的行数。结论要谨慎——把轮转误判成反取证，会带偏整个排查方向。
基本信息
| 统计方法 | 按小时聚合条目数，找条目为 0 的时段 |
|---|---|
| 时间戳检查 | stat 看 mtime/ctime 与内容最后时间是否矛盾 |
| 常见正常原因 | 日志轮转、服务重启、磁盘写满 |
| 反取证特征 | 断档前后权限或属主变化、部分行被删改 |
| 交叉来源 | 上游日志采集平台与本机轮转归档 |
| 前置要求 | 先统一时区口径再跨文件比对 |
典型使用场景
- 事件时间线出现空档，需要先判断原因
- 日志文件的体积与时间跨度明显不匹配
- 排查日志文件属主或权限被改动的情况
- 与其他主机上同类服务的日志量做横向对比
- 判断是否需要补装日志采集或调整轮转策略
- 上报材料中说明日志可得性与缺口原因
- 观察期内监控日志是否再次出现异常空档
检查分布与时间戳
检查分布与时间戳
awk '{print $1" "$2}' /var/log/auth.log | uniq -c | tail -n 40 # 按小时看条目分布
stat -c '%y %z %s %n' /var/log/auth.log /var/log/secure 2>/dev/null # mtime/ctime 与体积
wc -l /var/log/auth.log /var/log/auth.log.1 2>/dev/null # 当前与上一份的行数
ls -la --time-style=long-iso /var/log/ | head -n 20 # 属主与权限是否变动
head -n 3 /var/log/auth.log; tail -n 3 /var/log/auth.log # 首尾时间跨度现象与成因判读
| 现象 | 常见正常原因 | 反取证信号 |
|---|---|---|
| 某小时条目为 0 | 服务重启或轮转 | 断档前后权限、属主变化 |
| 体积突然变小 | 轮转后重建文件 | 体积与时间跨度严重不匹配 |
| mtime 晚于末条日志 | 有新日志写入 | mtime 与内容时间明显矛盾 |
| 归档文件缺失 | 轮转未保留或已删除 | 归档被人为清空 |
| 条目格式不一致 | 版本升级改了格式 | 部分行被改写或伪造 |
内容时间与 mtime 矛盾时要提高警惕：例如 mtime 是凌晨，而最后一条日志停在昨天下午，说明文件在那之后被人动过。
单机日志缺失不等于全丢：多数环境配有上游日志采集，采集侧保留时间更长，也更难被本机攻击者删改。
不要直接在原日志上做清洗或截断：先复制副本再分析，原始文件是最关键的证据。