聊到 Linux 时间同步我发现很多同行一开始都是随手装个 ntpd然后基本不再管。直到某天证书验证突然失败、数据库主从复制眼看不正常、日志时间莫名其妙“倒流”才回头查问题结果发现系统时间已经偏差好几十秒了。这几年我在生产环境里几乎把所有服务器都换成了 Linux Chrony 时间同步体验下来最直接的感觉是它比 ntpd 更快进入稳定状态对虚拟化环境和网络抖动的容忍度也高很多。这篇文章不打算写教科书式文档我想把实际部署、参数设计、验证排障的经验完整梳理一遍给正准备换工具或已经用上 Chrony 的同学做个参考。1. 为什么现在的 Linux 发行版都默认改用 Chrony迁移背后的真实原因1.1 老牌 ntpd 的痛点收敛慢、调时间费劲在很长一段时间里Linux 服务器的时间同步默认方案都是 ntpd。ntpd 的优势是稳定、老牌、资料多但实际用下来有几个比较明显的痛点。首先是启动后的收敛速度。ntpd 在刚启动时会花很长时间来选择和评估时间源尤其是网络抖动比较大的机房环境经常要等好几分钟甚至更久ntpq -p里看到的源才慢慢进入可用状态。如果服务器是刚开机、需要尽快恢复业务这种慢热会让“时间刚同步完”这件事变成启动流程里的隐性瓶颈。其次是时间跳变的问题。ntpd 默认策略也是尽量平滑调整但在偏移量过大的时候依然会直接 step 跳动。对于数据库、消息队列这类对时间顺序敏感的业务一次毫无预兆的时间跳变可能直接引发主从复制异常或者分布式锁失效。我遇到过一个案例某内部集群的一台数据库在做逻辑备份时时间突然往前跳了 40 多秒随后 binlog 位置和时间戳对不上恢复流程差点出大问题。还有一个容易被忽视的点ntpd 对网络延时的变化非常敏感。如果时间源服务器和你之间的网络路径不稳定RTT 忽高忽低ntpd 会频繁调整频率、反复纠偏结果就是系统时间看起来一直“在同步”但实际始终处于小幅震荡状态。1.2 Chrony 的方案为什么更合适Chrony 之所以能成为各大发行版默认的时间同步软件核心原因是它在算法上做了更精细的控制。它不是单纯跟着某个时间源跑而是会通过多个采样点估算本地时钟的漂移率再结合网络延时做平滑修正。这样一来即使网络 RTT 偶尔波动系统时钟也不会被带偏。在实际对比中我用同一批物理机做了测试相同的外部时间源tuning 前 ntpd 在满载状态下时钟偏移大概在 50 到 200 毫秒左右波动切换为 chronyd 后大多数时间能稳定在 10 毫秒以内。对于普通业务场景来说这个差距可能不致命但对于需要精确记录事件顺序、做计费或者审计的系统这个精度提升是非常明显的。Chrony 另一个让我很满意的点是启动速度。它可以在几十秒内完成初始同步并进入稳定状态这在大规模服务器批量重启的场景下非常实用。而且它默认会在启动时检查本地 RTC 和保存的漂移文件如果偏差不大可以直接用已有参数恢复不需要重新走一遍“从零学习时钟频率”的过程。1.3 迁移的成本其实很低说实话从 ntpd 切换到 chronyd 的成本非常低主要就是apt install chrony或者yum install chrony然后停掉并禁用 ntpd、启用 chronyd配置语法也非常接近。Chrony 兼容 ntp 协议客户端不需要做任何修改依然可以通过标准 NTP 端口 123/UDP 来获取时间。唯一的注意点是不能同时运行 ntpd 和 chronyd因为两个服务都会监听 UDP 123端口冲突会导致时间源问题。对于已经有成熟 NTP 体系的机房迁移 Chrony 可以只用改服务器端客户端保持不变这个兼容性让整个替换过程的业务风险降到很低。2. 安装与基础配置从一台空机器到能正常同步2.1 安装、启动与开机自启不同发行版的安装方式略有差异但核心步骤基本相同。在 RHEL/CentOS 系上yum install -y chrony systemctl enable --now chronyd在 Ubuntu/Debian 系上apt install -y chrony systemctl enable --now chronyd装完之后先用systemctl status chronyd确认服务跑起来了。多数情况下发行版自带的默认配置已经可以直接工作它默认会使用发行版维护的公共 NTP 服务器池。但对于生产环境我建议不要把命运完全交给默认配置而是按自己的网络情况重写/etc/chrony/chrony.conf。2.2 先定时区再谈时间同步很多人容易把“系统时间不同步”和“系统时区不对”混在一起。NTP 负责同步的是 UTC 绝对时间它解决的是“你的机器和标准时间差多少”而时区解决的是“这个绝对时间显示成哪个地区的本地时间”。两者是独立的事情。所以部署时间同步之前我建议先设置好时区timedatectl set-timezone Asia/Shanghai然后看timedatectl的输出Local time: 2025-01-06 14:22:33 CST Universal time: 2025-01-06 06:22:33 UTC RTC time: 2025-01-06 06:22:33 Time zone: Asia/Shanghai (CST, 0800) System clock synchronized: yes NTP service: active这里有个容易踩的坑硬件时钟 RTC 默认是否使用 UTC。对于配置了多系统的物理机如果 Windows 和 Linux 对 RTC 的解释不同会出现重启后时间相差 8 小时的情况。稳妥的做法是让 RTC 统一使用 UTCLinux 在启动时把 RTC 时间加时区偏移转换成系统时间。确认方法timedatectl | grep RTC time如果 RTC 显示的是本地时间而不是 UTC可以在某些发行版上用timedatectl set-local-rtc 0改回 UTC 模式。大部分云服务器默认就是这么配置的不用额外处理。2.3 防火墙与 SELinux两个容易被忽略的坑Chrony 服务的通信端口固定为 UDP 123。云服务器除了安全组要放行之外本机防火墙也需要确认。在 firewalld 环境里执行firewall-cmd --permanent --add-servicentp firewall-cmd --reload在 ufw 环境里执行ufw allow 123/udpSELinux 方面发行版自带的 chronyd SELinux 策略一般已经放开了标准端口和默认目录。但如果你自定义了 driftfile 路径或者绑定了非默认端口就需要注意策略是否允许。排查的时候可以直接看/var/log/audit/audit.log有没有denied记录避免被 SELinux 拦截了还在反复查网络。3. 配置参数逐项拆解每个关键选项背后的设计逻辑3.1 server、pool、iburst、prefer时间源选择的取舍Chrony 配置的核心是时间源定义。最常见的是server指令server ntp.example.com iburstiburst参数非常关键。它表示在服务刚启动时快速发送一组请求进行初始校准可以让系统在几十秒内完成同步。如果没有iburst同步初期的确认过程会比较慢我不建议去掉。当你有多个时间源时可以用pool指令替代多个serverpool pool.ntp.org iburstpool适用于一个域名下有多台解析地址的场景比重复写多条server更简洁。不过 pool.ntp.org 是公共资源生产环境我会倾向于使用自建时间源或者云的 NTP 地址。prefer则是用来标记优先级较高的时间源。比如内网有一个自己搭的高精度时钟服务器同时也接入了公网 NTP可以这样配server 192.168.1.10 iburst prefer server ntp.example.com iburstChrony 会优先使用带prefer的源但也会参考其他源进行交叉验证。这样做的好处是即使首选源暂时不可用系统也能从备用源获得时间不会一断就彻底失步。3.2 driftfile 与 makestep平衡精度和风险driftfile用于保存本地时钟的频率漂移信息。它的意义在于每次重启之后 chronyd 不用重新测量本地时钟漂移率直接读取上次保存的值即可快速进入稳定状态。路径一般设置为driftfile /var/lib/chrony/drift另外一个重要参数是makestep。格式为makestep 1 3含义是如果系统时间与标准时间的偏差超过 1 秒并且这一情况发生在启动后的前 3 次时钟更新中那么 chronyd 会直接 step跳变到正确时间。超过这个窗口之后即使偏差很大也会采用缓慢调整方式避免影响业务。这个参数设计得非常聪明。开机时系统时间可能偏差较大快速 step 可以节省恢复时间而在正常运行期间突然出现大偏差往往意味着更复杂的问题此时选择平滑调整比强制 jump 更安全。如果追求绝对严谨可以写成makestep 0.5 3把 step 阈值收紧到 0.5 秒。但要注意不是所有场景都适合收紧阈值业务对时间跳变的容忍度需要自己把握。3.3 allow、deny 与 local把一台服务器变成内网时间源Chrony 既可以当客户端也可以当服务器。如果希望让内网其他机器从这台服务器同步时间需要配置allow字段allow 192.168.0.0/16与之对应的是deny可以写具体 IP 或网段。allow可以写多条但要记得如果只写了allow而没有指定网段Chrony 默认只允许本地访问。所以很多人在内网搭时间服务器发现客户端连不上多半就是allow没写。另一个容易忽略的是local stratumlocal stratum 10这行的意思是当所有外部时间源都不可达时本机仍然可以对外提供时间服务只是层级stratum会被标记为 10。这个配置对内部测试环境和离线机房很有用。否则一旦外部 NTP 源断了这台服务器会拒绝回应任何客户端请求内网所有机器都会跟着失去时间源。单台服务器作为全内网时间源时典型配置如下server 192.168.1.10 iburst prefer server ntp.example.com iburst driftfile /var/lib/chrony/drift makestep 1 3 rtcsync allow 192.168.0.0/16 local stratum 10rtcsync会让 chronyd 定期将系统时间同步到 RTC避免服务器长时间断电后 RTC 漂移太严重。物理机建议保留虚拟机因为 RTC 本身由宿主机虚拟化通常不需要但保留也不会造成问题。4. 验证与排障chronyc 命令的实战用法和踩坑记录4.1 sources 与 tracking一眼看出同步质量配置完后最重要的就是验证。最直观的命令是chronyc sources -v输出会包含时间源状态符号。看到^*表示当前正在使用该源同步^表示该源可用但当前未使用^?表示该源不可达^-表示该源被判定为不可用。我基本只看两点是否至少有一个^*以及^?是否过多。如果大量的源都是^?优先怀疑网络或防火墙问题。另一个命令是chronyc tracking输出里的System time是系统时间与参考源的最新偏差Last offset是最近一次校准后的偏移量RMS offset是这段时间的均方根偏差更有代表性。我会用RMS offset来判断整体同步质量。正常网络环境里如果 RMS offset 稳定在几十毫秒以内说明同步状态很好。如果这个值持续增大就算sources显示^*也要检查网络或者配置了。4.2 完整排查链路从 timedatectl 到 journalctl遇到时间同步异常我的排查链路一般是这样的。第一步看系统状态timedatectl重点看System clock synchronized: yes/no。如果是 no说明内核判断系统还没有完成任何一次有效同步这时继续追查时间源。第二步查时间源状态chronyc sources -v如果全部是^?先 ping 一下时间服务器 IP再确认防火墙端口。很多云安全组默认只放行 TCPUDP 123 没有放行导致 NTP 请求发出去但没有回应。第三步确认服务监听ss -ulpn | grep 123如果 123 端口被占用且不是 chronyd 的 PID极可能是 systemd-timesyncd 还在运行。它是 systemd 自带的时间同步服务会和 chronyd 抢端口。解决办法是关闭并禁用 systemd-timesyncdsystemctl disable --now systemd-timesyncd第四步看日志journalctl -u chronyd --since 10 minutes ago日志里经常能直接看到原因比如时间源不可达、SELinux 拒绝、配置文件语法错误等。Chrony 的日志写得比较清楚比 ntpd 那些晦涩的日志友好得多。4.3 三个真实踩坑场景第一个坑是虚拟化环境时钟冲突。我在虚拟机上同时开启了 VMware Tools 的时间同步和 chronyd结果两个机制都在改时间系统时间不断小幅跳动日志里全是时间戳错乱。后面关掉了虚拟化层的自动时间同步只保留 chronyd问题立刻消失。在 KVM 环境里类似宿主机如果开启了 kvm-clock 的某些自动校准特性也可能和 chronyd 产生竞争。建议在虚拟化平台只保留一种时间同步机制避免两者互相干扰。第二个坑是防火墙配置。有一次内网某个网段的机器始终^?但同一个机房其他机器同步正常。最后排查发现那几台机器除了云安全组之外还在系统层开了 firewalld而策略里只放行了 TCP 123UDP 123 没有放行。NTP 是 UDP 协议TCP 放行完全没有作用。这个问题靠chronyc sources -v看不出来必须到节点本机检查防火墙规则才能定位。第三个坑是时区导致日志时间“倒流”。有台机器 UTC 时间本地时间都设置正确但应用日志记录的时间总和其他服务器差 8 小时。后来发现是 Java 应用读取了系统里的TZ环境变量而这个变量在启动脚本里被错误地写成了 UTC。这个不算 chronyd 的问题但它提醒我时间不同步的原因不只在同步服务本身应用程序的时区配置、容器镜像里的/etc/localtime、甚至 JDK 的默认时区都可能造成干扰。排查时域广一点不要只盯 NTP。5. 进阶调优与监控让时间同步服务持续可靠5.1 优化轮询间隔与首选源默认配置下chronyd 会动态调整轮询间隔范围一般在 64 秒到 1024 秒之间。如果对时间精度要求比较高可以手动缩小范围加快探测频率server ntp.example.com iburst minpoll 4 maxpoll 6minpoll 4对应 16 秒maxpoll 6对应 64 秒。轮询间隔越小跟踪越紧密但也会增加网络负荷和时间服务器的压力。对普通业务来说默认参数完全够用不建议为了数据好看而盲目加大频率。只有在确实承担了高精度任务、或者作为内网时间源对外提供服务时才值得这样调。如果网络里有多条链路可以结合prefer指定一个稳定的首选源。同时留意不要把多个不稳定的公共源都设为prefer那样反而会让 chronyd 在多个“首选源”之间摇摆。5.2 偏差超阈值告警时间同步服务平时很安静但一出问题影响就很大。我给服务器加了一个简单的监控脚本每 5 分钟检查一次#!/bin/bash offset$(chronyc tracking | grep RMS offset | awk {print $4}) threshold100 if [ $(echo $offset $threshold | bc) -eq 1 ]; then echo Time offset too large: ${offset}ms fi这里没有引入额外的监控平台只是用 cron 或 systemd timer 定期跑脚本超过阈值就输出告警。接入现有告警系统时把脚本输出转成监控指标即可。重点是阈值要根据业务设定像交易系统可能要求 10 毫秒内普通日志服务器 100 毫秒都能接受。5.3 使用 GNSS 或 PTP 的更高精度方向如果业务对时间精度的要求已经提升到微秒级单纯靠 NTP 网络同步是不够的。这时候可以考虑两个方向一个是给服务器接 GNSS 接收模块让 chronyd 直接读取本地参考时钟不受网络波动影响另一个是引入 PTP精确时间协议在支持硬件时间戳的网卡上实现亚微秒级同步。Chrony 其实也支持 PTP 相关能力但绝大多数场景用不到这个深度。真正需要这么高精度的通常是证券交易、工业控制或者科研数据采集环境。普通企业服务器能把时间稳定在毫秒级已经完全可以满足证书校验、日志审计和分布式协调的需求。部署这类高精度方案之前先确认业务真的需要避免为了炫技增加复杂度。5.4 把维护变成常规动作最后说说维护习惯。我现在的标准流程是新装系统后第一件事设置时区第二件事配置 chrony第三件事确认timedatectl里NTP service: active。每次变更时间相关配置都会重启 chronyd 后用chronyc tracking和chronyc sources -v双确认。长期运行的服务器每周看一眼 RMS offset 趋势及时发现问题。时间同步不像业务系统那样天天有变化但它是所有分布式系统一致性的地基。我也见过因为一台服务器时钟漂移导致某分布式缓存集群里的节点互相认为对方过期最终引发连锁故障的例子。这类问题一旦发生光靠日志定位就要花不少时间。把这些检查都融入到日常运维里之后我在实际项目里因为时间问题翻车的次数明显少了很多服务器时间也从“偶尔想起来看一眼”变成了“稳定可信的基础设施”。