名称

log-timeline-reconstruction

描述

当发生线上故障或安全事件、需要从多来源日志还原事件时间线时使用。该技能统一时间基准与时区、处理时钟漂移、按追踪 ID 与实体关联跨服务日志，输出带证据引用与空白的分钟级时间线，并区分事实、推断与未知。适用于故障复盘、安全事件调查、跨系统对账与值班交接。关键词：日志分析、时间线、故障复盘、事件调查、时钟漂移、时区、追踪ID、trace、关联分析、根因定位、值班、可观测性、日志归一化、取证。

多源日志时间线重建

把散落在网关、应用、数据库、消息队列里的日志拼成一条可信的时间线。

何时使用

故障复盘需要精确到分钟的事件顺序。
安全事件调查需要证明“谁在何时做了什么”。
跨团队对账，各方日志时间对不上。
值班交接需要一份可读的事件经过。

不适用：单服务、单日志文件且时间线清晰的简单问题。

输入

各来源日志：网关、应用、数据库、中间件、云平台审计。
各机器的时钟同步状态（NTP 是否启用、偏移量）。
追踪 ID、请求 ID、用户 ID 等关联键。
事件发生的大致时间窗与已知现象。

时间窗不明时，先用监控告警时间反推，不要全量导出。

工作流

第 1 步：统一时间基准

全部转换为 UTC 存储，展示时再按需转换。
记录每条日志的来源时区与格式（ISO 8601、epoch 秒/毫秒、本地时间）。
检查 NTP：偏移超过 1 秒的节点单独标注。
同一节点内以单调时钟顺序为主，墙钟时间仅作参考。

第 2 步：归一化字段

统一为：timestamp_utc, source, level, service, instance, trace_id, span_id, user_id, message, raw_ref。

raw_ref 指向原始日志行，确保每个结论可回溯。

第 3 步：关联

按优先级：

trace_id 串联一次请求的完整链路。
span_id 还原父子调用。
业务实体（订单号、设备 ID、会话 ID）跨链路关联。
时间邻近 + 同实例作为弱关联，需标注置信度。

第 4 步：排序与去重

按 UTC 时间排序，同毫秒按来源优先级：客户端 → 网关 → 应用 → 数据库。
去重：同一事件在多个采集端重复出现时保留最详细的一条。
标记“时间倒挂”：下游记录早于上游，通常说明时钟漂移。

第 5 步：构造时间线

每个节点包含：时间、来源、事件、证据引用、判定（事实/推断/未知）。

三类必须分开写：

事实：日志原文直接支持。
推断：由多条证据推出，写明推理链。
未知：信息缺失，写明需要什么证据。

第 6 步：找空白与异常

时间空白：应为周期性日志却缺失，可能是进程崩溃或采集中断。
顺序异常：先失败后成功但无重试记录。
数量异常：某时间段日志量突降。
内容异常：错误码跳变、超时集中。

检查清单

[ ] 全部时间已转 UTC，并标注原始时区。
[ ] 时钟偏移节点已识别。
[ ] 每条时间线节点都有原始日志引用。
[ ] 事实、推断、未知已区分。
[ ] 关键空白已列出并说明可能原因。
[ ] 与监控告警时间交叉验证。
[ ] 涉及人员的结论有审计日志支撑。

输出模板

## 事件摘要
- 影响：
- 起止时间（UTC）：
- 影响面：

## 时间线
| 时间(UTC) | 来源 | 事件 | 证据 | 判定 |
| --- | --- | --- | --- | --- |

## 关键空白
| 区间 | 应有日志 | 实际 | 推测 |
| --- | --- | --- | --- |

## 根因假设
1. 假设 / 支持证据 / 反证 / 验证方式

## 待补证据
- ...

反模式

直接混用本地时间排序。
把推断写成事实。
只看应用日志，忽略网关与数据库。
忽略时区，导致“故障发生在发布前”的错误结论。
时间线精确到秒却无原始日志支撑。

参考文件

references/timeline-template.md：时间线表与证据引用格式。
references/correlation-tips.md：跨服务关联与时钟问题处理。