偏移修正的原则
测出主机时钟与标准时间的差值后，要对它产生的每个事件做修正，才能放进统一时间线。修正本身很简单——主机慢就加上偏移量，主机快就减去——难点在于「修正必须可回溯」：原始值、修正量、修正后时间与修正依据都要落盘。跨天分析时偏移往往不是常量（可能中途做过 NTP 校时），因此要按测量点把时间轴分段，每段用各自的修正量。
基本信息
| 修正方向 | 主机慢 → corrected = raw + offset；主机快 → corrected = raw - offset |
|---|---|
| 必须记录 | 原始时间、修正量、修正后时间、测量依据与测量时刻 |
| 分段依据 | NTP 校时事件、重启、虚拟化暂停都可能造成偏移跳变 |
| 适用范围 | 偏移在测量区间内视为恒定，超出区间需另测 |
| 产物 | 修正记录表，作为时间线的附件随报告交付 |
| 工具线索 | chronyc tracking、ntpq -p、systemd-timesyncd 状态 |
典型使用场景
- 离线主机时间与标准时间相差几十秒到几分钟，日志无法与流量对齐
- 虚拟机暂停恢复后时钟跳变，需要按跳变点分段修正
- 跨多台主机比对时，其中一台明显偏离，需单独修正后再合并
- 把设备日志与主机日志叠加分析前，先消除两侧固定差值
- 为结论写清误差范围，说明判定精度受时钟影响的程度
- 评估时间差是否恰好等于某个时区偏移，从而排除「时区问题」而非「时钟问题」
修正记录示例
修正记录示例
# host: H1（web-1）
# measure: chronyc tracking 输出 System time 为 -3.4s，即主机慢 3.4 秒
# measure_time: 2026-01-02T02:00:00Z（该时刻测得）
# rule: corrected = raw + 3.4s
# window: 2026-01-01T00:00:00Z ~ 2026-01-02T06:00:00Z
# 假设依据：区间内无重启、无 NTP 跳变，偏移视为恒定
# raw: 2026-01-02 03:22:10（主机本地日志时间，已换算为 UTC 表述）
# corrected: 2026-01-02T03:22:13.4Z
# after_jump: 2026-01-02T06:00:00Z 之后的偏移另测，见 measure 第 2 条修正记录逐列读法
| 字段 | 含义 | 填写要点 |
|---|---|---|
| host | 被修正的主机 | 与时间线里的 host 列写法保持一致 |
| measure | 测量到的偏移值与方向 | 写清工具与原始输出，如 chronyc tracking 的 System time |
| measure_time | 测量发生的时刻 | 决定该修正量适用的起点 |
| rule | 换算公式 | 方向写反是最常见错误，公式能让人一眼看出 |
| window | 适用时间窗 | 超出窗口必须重新测量，不能外推 |
| corrected | 修正后的值 | 与原始值并排保留，便于复核 |
长时间跨度内偏移并非恒定。跨天分析要按多次测量结果分段修正，跨越 NTP 跳变点前后必须使用不同修正量，否则修正本身会引入新的时间错位。
修正前先判断差值是不是整数个小时：恰好等于某时区偏移时，问题多半出在时区设置而非时钟漂移，处理方式完全不同（一个是换算，一个是校时记录）。