timekeeping watchdog expired 表明内核检测到单调时钟停滞或倒退超阈值（约1秒），强制校正导致 CLOCK_REALTIME 跳变；主因是硬件计时器异常或虚拟化时间同步失控。
为什么 timekeeping watchdog expired 会引发时间跳跃
这个内核日志不是警告，而是故障已发生的信号：内核时间子系统检测到单调时钟（如 TSC 或 HPET）在两次更新之间停滞或倒退超阈值（默认约 1 秒），于是强制触发时间校正——表现为系统时间突然跳变（clock_gettime(CLOCK_MONOTONIC) 不跳，但 CLOCK_REALTIME 可能跳）。根本原因几乎总是硬件计时器异常或虚拟化层时间同步失控。
物理机上重点检查 TSC 稳定性与 BIOS 设置
现代 x86 物理服务器默认依赖 TSC（时间戳计数器）作为主时钟源，但它必须满足 invariant TSC（频率恒定、跨核同步）才能安全使用。若 BIOS 关闭了 Invariant TSC、Intel SpeedStep（或 AMD Cool'n'Quiet）动态调频未禁用，或 CPU 进入深度 C-state 后 TSC 暂停，就可能触发 watchdog。
- 确认当前时钟源：
cat /sys/devices/system/clocksource/clocksource0/current_clocksource，若为tsc，继续排查 - 检查 TSC 是否 invariant：
dmesg | grep -i "tsc.*invariant"，应有类似TSC now invariant的输出 - BIOS 中关闭所有 CPU 节能特性（C-states > C1、SpeedStep、Turbo Boost），并启用
Invariant TSC（名称因厂商而异，如 Intel 的Enhanced Intel SpeedStep Technology需禁用） - 启动参数强制降级时钟源测试：
clocksource=acpi_pm或clocksource=hpet，观察是否消失（性能会下降，仅用于验证）
KVM/QEMU 虚拟机需禁用 host-passthrough 的 TSC 并校准 guest 时间
当 KVM 使用 host-passthrough 暴露宿主机 CPU 特性给 guest 时，guest 的 TSC 直接映射宿主机 TSC。一旦宿主机因节能、迁移或负载导致 TSC 异常，guest 就会立即中招。这不是 guest 自身问题，而是虚拟化层透传了不稳定的硬件行为。
- 修改 VM XML，将
- 确保宿主机已启用
kvm-clock：检查dmesg | grep kvm-clock，应有Using kvm clock - guest 内安装
chrony并配置为只用kvm-clock校准：makestep 1 -1+rtcsync，禁用 NTP 硬件时钟同步（hwtimestamp） - 宿主机上禁用
qemu-ga的时间同步功能（org.qemu.guest_agent.0.command_time_sync设为 false），避免干扰内核 timekeeping
容器与云环境要警惕 hypervisor 时间漂移传递
在 AWS EC2（尤其是 t3/t4g burstable 实例）、Azure 的 B-series 或 GCP 的 E2 实例上，底层 hypervisor 为控制 CPU 积分会主动暂停 vCPU，导致 guest TSC 停滞。这种暂停对 guest 内核不可见，但 timekeeping watchdog 能感知到“时间没走”，从而跳变。
- 查看实例类型文档，确认是否属于 burstable 类型；如果是，升级到固定性能实例（如 EC2
m5、GCPe2-standard）是根治方案 - 临时缓解：在 guest 中设置
kernel.tsc=reliable（仅限已知稳定 TSC 的场景），或加启动参数clocksource=tsc tsc=reliable - 云平台监控中重点关注
CPUCreditBalance（AWS）或cpu-usage-rate（GCP），持续低于阈值说明 CPU 被节流，时间异常大概率伴随发生
真正棘手的不是日志本身，而是它往往只在时间跳变后才出现——等你看到 timekeeping watchdog expired，服务可能已经因时间回跳丢弃了 TLS 证书、拒绝了 NTP 请求、或让分布式锁失效。务必在部署前就锁定时钟源和虚拟化配置，而不是等告警再查。
