时钟同步为什么重要
慢日志、延迟事件与业务日志要能对齐时间线，前提是各机器时钟同步，这件事由 NTP 或 chrony 负责。时钟漂移会让「哪台机器先出问题」这类推断失效：明明是先发生的错误，在日志里看起来却在后面。排查大事故之前先确认时钟，是成本最低、收益最明显的一步。
基本信息
| 常用工具 | chronyc tracking、chronyc sources、ntpq -p |
|---|---|
| 关注指标 | 同步状态与当前偏移量 |
| 典型表现 | 跨机日志时间线顺序矛盾 |
| 检查时机 | 故障排查开始前、跨系统对账时 |
| 适用平台 | Linux 用 chrony 或 ntpd；容器共享宿主时钟 |
典型使用场景
- 事故复盘：把多机日志按时间排序之前，先确认时钟一致
- 慢日志分析：实例时间与采集端时间对不上时，先查同步状态
- 容器环境：容器共享宿主时钟，宿主未同步则容器一起漂移
- 对账类任务：账务或统计跨系统比对时，时间戳必须可信
- 常态巡检：把时钟偏移纳入监控，避免问题积累到无法解释
检查写法
检查写法
chronyc tracking # 同步状态与当前偏移
chronyc sources # 逐级查看时间源的可用状态
ntpq -p # 使用 ntpd 时查看对端与偏移
timedatectl status # 确认系统时间与同步服务是否启用
date -u # 与另一台机器对比 UTC 时间输出的关键字段
| 字段 | 含义 | 正常/异常 |
|---|---|---|
| Leap status | 闰秒状态 | Normal 为正常 |
| System time | 本机与时间源的偏移 | 明显偏离说明同步有问题 |
| Last offset | 上一次调整的偏移量 | 持续偏大需要继续追源 |
| Stratum | 时间源层级 | 层级过深说明链路长、误差累积 |
排查大事故前先确认时钟是常见做法：两台机器差了几秒，事件顺序的推断会完全反过来，围绕错误时间线做的分析全部作废。
同步服务中断又长期没有告警时，偏移会随天数累积，跨系统日志对账逐渐失效，等需要用它取证时才发现数据不可信。