chronyc tracking 可精准获取 chronyd 管理的系统时钟实时偏移值，单位秒，字段稳定易解析；批量检查需用 ssh + 超时控制 + awk 提取 Last offset，并用 bc 比较是否超 0.5 秒。
用 chronyc tracking 批量抓取 offset 值
chrony 是现代 Linux 发行版默认的时钟服务，chronyc tracking 输出里有 Last offset 字段，单位是秒，直接反映当前同步偏差。这个值比 ntpq -p 更准、更易解析，尤其适合脚本批量采集。
关键点在于：它不依赖远程 NTP 服务器响应，只读本地 chronyd 状态，即使网络断开也能拿到最新 offset；且输出稳定，字段位置固定，方便 awk 提取。
- 在目标节点上执行：
chronyc tracking | awk '/^Last offset/ {print $3}'，会输出类似-0.000421234这样的浮点数（单位：秒） - 注意：如果 chronyd 没运行或未同步，该命令可能报错或输出空，需加
2>/dev/null || echo "0"容错 - 不要用
date或hwclock对比来算偏移——那测的是绝对时间差，不是 chronyd 实际校正效果，意义不同
写一个 ssh 批量检查脚本
不能手动一台台登，得靠循环 + ssh + 超时控制。核心逻辑是：对每个 IP 执行远程 chronyc tracking 解析，判断绝对值是否超过 0.5 秒，并记录主机名和偏差值。
示例脚本片段（保存为 check-clock-drift.sh）：
#!/bin/bash
nodes=("192.168.1.10" "192.168.1.11" "192.168.1.12")
for ip in "${nodes[@]}"; do
drift=$(ssh -o ConnectTimeout=3 -o BatchMode=yes "$ip" \
'chronyc tracking 2>/dev/null | awk "/^Last offset/ {printf \"%.6f\", \$3}"' 2>/dev/null)
if [[ -n "$drift" ]] && (( $(echo "$drift 0.5" | bc -l) )); then
hostname=$(ssh -o ConnectTimeout=3 "$ip" 'hostname -s' 2>/dev/null)
echo "$hostname ($ip): offset = ${drift}s"
fi
done
- 必须加
-o ConnectTimeout=3，避免某台节点卡死拖慢整个检查 -
-o BatchMode=yes禁用交互式提示（比如首次连接的 yes/no），否则脚本会挂住 - 用
bc -l做浮点比较，bash 本身不支持小数运算 - 别用
for host in $(cat hosts.txt)这种方式——遇到含空格或特殊字符的主机名会崩
为什么不用 ntpq -p 或 timedatectl
ntpq -p 在 chrony 环境下不可靠：很多系统已禁用 ntpd，ntpq 连不上本地 ntpd 就直接失败，返回码 1，无法区分“服务停了”还是“没装”。而 timedatectl 的 System clock synchronized 只是布尔值，不提供具体 offset 数值，无法判断是否超 500ms。
-
timedatectl status里的System clock synchronized: yes不代表 offset -
chronyc sources -v显示的是上游源状态，不是本机当前 offset，容易误判 - 某些容器或精简镜像里
chronyc可能被删掉，但只要 chronyd 在跑，/var/run/chrony/chronyd.sock就存在，可用chronyc -c /var/run/chrony/chronyd.sock tracking强制指定 socket 路径
注意硬件时钟与系统时钟的混淆风险
脚本检测的是 chronyd 维护的系统时钟偏移，不是硬件时钟（RTC）偏差。这两者可能相差很大——比如某台机器重启后 RTC 比实际时间慢了 2 分钟，但 chronyd 启动后几秒就拉回来了，chronyc tracking 显示 offset 是 0.001s，完全正常。所以你真正要监控的是系统时钟的实时漂移能力，而不是“上次关机前 RTC 记得对不对”。
如果发现一批节点的 Last offset 持续缓慢增大（比如每小时涨 0.02s），说明 chronyd 没法压住硬件晶振漂移，得查 chronyc makestep 是否启用、rtcsync 是否配置、或者物理机 CMOS 电池是否快没电了——这些才是深层根因，光靠定时检查 offset 只能告警，不能自愈。
