Chrony 时间同步：为什么日志、证书和监控都依赖它

归档日期：2026-10-27；补录发布：2026-10-28。

排错时需要把 Nginx、数据库日志与监控曲线对齐。机器时间不准，时间线可能互相矛盾，TLS 证书也可能被误判为尚未生效或已过期。

时区与校时不同

Asia/Shanghai 决定显示方式，NTP 同步使时钟接近可信时间源。修改时区不能解决时钟漂移。

timedatectl status
date --iso-8601=seconds
date -u --iso-8601=seconds

同一时刻的本地时间与 UTC 表示不同，比较日志要看偏移与格式。

先确认现有服务

Rocky 常见服务是 chronyd，配置通常在 /etc/chrony.conf，chronyc 用于检查和控制。不要让多个校时守护进程同时调整时钟。

systemctl status chronyd --no-pager
chronyc tracking
chronyc sources -v

这些是只读检查，不会要求系统立即跳时。

输出先看什么

tracking 中 Leap status 帮助判断同步，System time、Last offset 提供偏差线索。sources 中 * 表示当前选中源，? 可能表示不可达、未同步或样本不足。

Reach 是八进制可达性记录，377 表示最近八次轮询成功，不是毫秒数。Stratum 是层级，更小也不自动意味着当前来源更可靠。

为什么不直接改时间

date -s 或强制步进会造成时间跳变，影响数据库记录、认证、定时任务和日志排序。需要步进时，应评估业务影响并选择维护窗口。

服务异常先查来源、DNS、网络路径和日志，再考虑修改配置。云服务器优先遵循云平台或组织批准的时间源。

对齐后再复盘

记录带明确时区的故障窗口，再查询各组件日志。程序计算耗时应优先使用单调时钟，避免墙上时钟校正影响结果。

本文整理检查方法，不表示本站需要对公网提供 NTP。客户端校时与开放对外授时是不同的配置目标。

判定同步不只看进程 active

chronyd 运行中可能仍没有可用来源。结合 tracking 的同步状态、sources 中选中源、Reach 与偏差趋势判断。只做客户端不需要为公网任意来源开放入站 UDP 123。调试时保留原时间源；虚拟机还要注意宿主机制与 guest 校时的关系。更改时区与调整真实系统时钟是两件事。

内容复核与修订：2026-10-29。实验示例与本站运行记录分别说明；原始归档日期保留。