1. 为什么你的服务器时间总是不准？从NTP到Chrony的演进

你有没有遇到过这样的场景：服务器上部署的应用日志时间戳对不上，排查问题时发现两台机器的时间差了十几秒；数据库主从同步报错，一查是主库和从库的系统时间不一致；甚至在做分布式事务或者依赖时间戳的加密认证时，因为毫秒级的偏差导致整个流程失败。这些问题，根源往往都指向一个看似不起眼的基础服务——系统时间同步。

在Linux世界里，提到时间同步，老司机们第一时间会想到ntpd（Network Time Protocol daemon）。它确实是过去几十年的行业标准，像一位德高望重的老教授，严谨、稳定，但配置起来也略显繁琐，对网络波动和系统负载的适应性在今天看来有些“迟缓”。而chrony，则可以看作是这位老教授培养出的“高徒”，它继承了NTP协议的精髓，但在算法和实现上做了大量现代化改进。它更快、更精准，尤其在虚拟化、云计算和移动网络环境下表现突出。现在，包括RHEL/CentOS 8、Fedora、Ubuntu等主流发行版，都已经将chrony作为默认的时间同步服务。如果你还在用ntpd，是时候了解一下这位“后起之秀”了。

简单来说，chrony是一个更现代化的NTP协议实现，它由两个核心组件构成：chronyd守护进程和chronyc命令行客户端。chronyd在后台运行，负责与时间服务器通信、计算时间偏差并逐步调整系统时钟；chronyc则让你可以随时查询同步状态、手动调整或检查时间源。它的设计目标很明确：在保持高精度的同时，更快地收敛到正确时间，并且对间歇性网络连接（比如笔记本电脑合盖休眠后唤醒）和虚拟机的时钟漂移有更好的处理能力。

2. Chrony 核心工作机制：它凭什么比NTPD更“聪明”？

要理解chrony的配置，必须先搞懂它是怎么工作的。这不仅仅是改几个配置文件参数那么简单，知其所以然，才能在出问题时快速定位。

2.1 时钟的“性格”：漂移与偏移

每个计算机的硬件时钟（Real Time Clock, RTC，也就是CMOS时钟）和由内核维护的系统时钟，都不是绝对准确的。它们受温度、电压、主板晶体振荡器精度等因素影响，会以一个相对稳定的速率变快或变慢，这个速率就是时钟漂移率（clock drift）。比如，你的服务器时钟可能每天会慢2秒。而时钟偏移（clock offset）指的是当前系统时间与真实时间之间的瞬时差值。

ntpd和chronyd的核心任务，就是通过持续测量偏移量，并估算出漂移率，来“驯服”这台不守时的机器。chrony的算法更激进一些。它采用了一种更复杂的滤波和选择算法，能够更快地识别并丢弃不可靠的时间源样本，同时更积极地计算漂移率。这意味着，在系统启动后，或者时间发生较大偏差时，chrony能比ntpd更快地将系统时间调整到正确范围。

2.2 时间源的“选举”与“信任”

chronyd会同时向多个配置的NTP服务器（时间源）发送请求。它并不简单地取平均值，而是进行一场精密的“选举”：

1. 测量与筛选：chronyd会持续测量到每个时间源的往返延迟（delay）和时间偏移（offset）。它会根据这些测量的稳定性和一致性，为每个时间源计算一个“误差范围”和“权重”。
2. 层级与距离：NTP服务器本身是分层的（Stratum）。Stratum 0是原子钟、GPS时钟等绝对时间源；Stratum 1是直接连接Stratum 0的服务器；Stratum 2从Stratum 1同步，以此类推。chrony会优先选择层级低（数字小）且网络延迟小的服务器。
3. 真假源检测：这是chrony的一个强项。它通过交叉比对多个时间源，能够有效检测并拒绝那些提供错误时间的“假”服务器（可能是配置错误或恶意服务器）。ntpd在这方面相对脆弱。
4. 组合时间：最终，chronyd会综合所有“可信”时间源的信息，计算出一个最优的“组合时间（combined time）”，并以此为目标来调整本地时钟。

这个过程的细节都记录在chronyd的内存状态中，我们可以通过chronyc命令来窥探。理解了这个过程，你就会明白为什么配置文件里pool、server指令后面可以跟minpoll、maxpoll、iburst这些参数，它们直接影响了测量行为的频率和积极性。

2.3 调整方式： “猛药”还是“温补”？

当发现时间偏差时，有两种调整方式：

• 步进调整（Step）：如果时间偏差超过一个阈值（默认是1000秒），chronyd会直接“跳变”时钟。这就像发现手表慢了半小时，直接拧到正确时间。在生产环境中，巨大的时间跳变可能导致依赖连续时间的应用（如数据库事务日志）出错，所以这个阈值需要谨慎设置。
• 渐进调整（Slew）：如果偏差在阈值之内，chronyd会通过加快或减慢系统时钟的“滴答”频率，让时间逐渐“滑”到正确位置。这是默认且推荐的方式，对应用无感。

chrony的渐进调整算法更平滑，允许在短时间内补偿更大的偏移量，这也是它收敛速度快的原因之一。

3. 从零开始：一份详尽的Chrony配置指南

理论说再多，不如动手配一遍。我们假设你正在配置一台新的CentOS 8或Rocky Linux 8服务器，其默认已安装chrony。

3.1 安装与基础状态检查

首先，确认chrony是否已安装并运行：

# 检查安装包 rpm -q chrony # 或使用dnf/yum dnf list installed chrony # 检查服务状态 systemctl status chronyd # 如果未安装，则安装 dnf install -y chrony

启动并设置开机自启：

systemctl enable --now chronyd

现在，用chronyc看看初始状态：

chronyc sources -v

这个命令会列出所有配置的时间源。初始状态下，它可能使用的是发行版预置的pool.ntp.org池地址。-v参数会显示详细信息，包括状态（^*表示当前选中的同步源，^+表示可用的候选源，^?表示未连接或状态未知）、层数、精度等。

3.2 解剖配置文件：/etc/chrony.conf

主配置文件/etc/chrony.conf的每一行都至关重要。我们分段解读。

第一部分：时间源配置这是核心，告诉chronyd向谁同步。

# 使用pool指令指向一个NTP服务器池。系统会从池中自动选择多个服务器。 pool 2.rocky.pool.ntp.org iburst # 或者使用server指令指定具体的服务器。可以指定多个。 server ntp1.aliyun.com iburst server ntp2.aliyun.com iburst server time.cloudflare.com iburst # 如果在内网有自建的、更精确的NTP服务器（如连接GPS的硬件时钟），优先使用。 server 192.168.1.100 iburst prefer

• poolvsserver:pool指向一个域名，该域名背后是多个服务器地址，可以实现负载均衡和自动故障转移，是推荐做法。server用于指定确定的单个服务器。
• iburst：一个非常重要的选项。当服务启动或服务器不可达后首次恢复时，chronyd会发送一连串（通常是4-8个）数据包来快速完成初始测量，极大加速初始同步过程。建议始终为每个server或pool条目加上iburst。
• prefer：标记为“首选”服务器。chronyd会给予这个源更高的权重，但最终选择仍基于算法。通常用于内网中更稳定、延迟更低的时间源。
• minpoll和maxpoll：定义轮询间隔的最小和最大值（以2的幂秒为单位）。默认是minpoll 6（64秒）和maxpoll 10（1024秒，约17分钟）。在网络稳定、追求高精度的内网环境中，可以适当减小maxpoll，例如maxpoll 8（256秒）。注意：过于频繁的查询可能会被公共NTP服务器视为滥用，请尊重上游服务器策略。

第二部分：时间调整策略

# 允许系统时钟在前1000秒的偏差内进行渐进调整，超过则步进调整。 makestep 1000 3 # 启用RTC（硬件时钟）的内核同步。 rtcsync

• makestep 1000 3：这是时间校正策略。1000是阈值（秒），3是前3次更新的限制。意思是：在前3次时钟更新中，如果偏差超过1000秒，就步进调整；之后，无论偏差多大，都只用渐进调整。生产环境建议：如果你的服务器可能因长时间关机产生巨大偏差，但又担心步进调整影响应用，可以将阈值调小（如makestep 1.0 -1）。-1意味着永远允许步进调整，但1.0秒的阈值使得只有非常大的偏差才会触发步进，通常应用能容忍1秒的跳变。更保守的做法是makestep 0.1 -1，只允许0.1秒以上的偏差进行步进，但这要求服务器时间基本保持在线。
• rtcsync：这个指令让chronyd定期（每11分钟）将系统时间同步到硬件时钟（RTC）。这非常重要，可以确保服务器重启后，系统时间从一个相对准确的值开始。务必启用。

第三部分：访问控制与网络

# 允许哪些网络查询本机时间（如果本机想作为NTP服务器） # allow 192.168.1.0/24 # 监听网络端口（作为服务器时） # bindcmdaddress 0.0.0.0 # local stratum 10

• 默认情况下，chronyd只监听本地回环地址（127.0.0.1）。如果你需要让这台服务器为内网其他机器提供时间服务，需要取消注释并修改allow和bindcmdaddress。
• local stratum 10：当所有配置的外部时间源都不可用时，chronyd可以将自己声明为一个层数为10的本地时间源。这样，内网中其他配置了此服务器为源的客户端，在外部网络中断时，仍然能在一个小的局域网内保持时间同步（虽然可能逐渐漂移）。这在隔离网络中有用。

第四部分：其他关键指令

# 指定存储漂移率记录的文件。chronyd通过它来记住你的时钟“通常跑多快/多慢”。 driftfile /var/lib/chrony/drift # 启用内核的硬件时间戳支持，可以大幅提高局域网内时间同步的精度（达到亚微秒级）。 # 需要网卡和驱动支持。 hwtimestamp * # 记录客户端访问日志（如果作为服务器） # logdir /var/log/chrony

• driftfile：这个文件记录了系统计算出的时钟漂移率。不要删除或随意修改这个文件。chronyd依靠它来在重启后快速应用已知的漂移率，加速收敛。
• hwtimestamp：对于金融交易、高性能计算等对时间精度要求极高的场景，这是“神器”。它利用网卡硬件为网络数据包打上精确的时间戳，绕过了操作系统协议栈的延迟。启用前需确认网卡支持。

3.3 配置实战：针对典型场景的配置模板

场景一：标准公有云服务器目标：快速、稳定同步，使用国内优质公共NTP源。

# /etc/chrony.conf server ntp.aliyun.com iburst server ntp1.tencent.com iburst server cn.pool.ntp.org iburst server time.apple.com iburst # 作为备用，质量通常很好 driftfile /var/lib/chrony/drift makestep 1.0 -1 rtcsync keyfile /etc/chrony.keys leapsectz right/UTC logdir /var/log/chrony

修改后务必重启服务：systemctl restart chronyd

场景二：内网时间服务器（母钟）假设你有一台能访问外网的服务器（192.168.1.10），要为整个内网（192.168.1.0/24）提供时间服务。 在这台服务器上配置：

# /etc/chrony.conf # 上游源 server ntp.aliyun.com iburst server time.cloudflare.com iburst # 允许内网访问，并声明自己为第3层服务器（如果上游是第2层） allow 192.168.1.0/24 local stratum 3 # 监听所有网络接口 bindcmdaddress 0.0.0.0 driftfile /var/lib/chrony/drift makestep 1.0 -1 rtcsync

在内网其他客户端服务器上配置：

# /etc/chrony.conf server 192.168.1.10 iburst prefer # 指向内网时间服务器，并标记为首选 # 可选：增加一个外部源作为备份，防止母钟完全失效 server ntp.aliyun.com iburst driftfile /var/lib/chrony/drift makestep 1.0 -1 rtcsync

4. 运维与排障：用chronyc命令洞察一切

配置好了不是结束，日常运维和问题排查才是关键。chronyc是你的瑞士军刀。

4.1 监控同步状态：你必须知道的几个命令

1. chronyc tracking：查看时间同步的核心指标。

   chronyc tracking

   输出类似：

   Reference ID : C0A8010A (192.168.1.10) # 当前同步的源ID Stratum : 3 # 层数，越小越好（1最佳） Ref time (UTC) : Thu Apr 10 08:00:00 2024 # 源报告的UTC时间 System time : 0.000123456 seconds fast of NTP time # 系统时间偏移量 Last offset : +0.000123456 seconds # 最后一次测量的偏移 RMS offset : 0.000012345 seconds # 偏移量的长期平均值（均方根） Frequency : 16.234 ppm slow # 时钟漂移率，正数表示慢 Residual freq : +0.001 ppm # 剩余频率误差 Skew : 0.123 ppm # 频率误差的估计界限 Root delay : 0.012345 seconds # 到根时间源的总延迟 Root dispersion : 0.001234 seconds # 到根时间源的累积误差 Update interval : 64.0 seconds # 最后两次更新的间隔 Leap status : Normal # 闰秒状态

   重点关注：Stratum（应在合理范围，如1-5），System time和Last offset（绝对值应非常小，理想情况在毫秒甚至微秒级），Frequency（显示你的硬件时钟天生跑得快还是慢）。

2. chronyc sources -v：查看所有时间源的详细状态。这是最常用的诊断命令。

   chronyc sources -v .-- Source mode '^' = server, '=' = peer, '#' = local clock. / .- Source state '*' = current synced, '+' = combined , '-' = not combined, | / '?' = unreachable, 'x' = time may be in error, '~' = time too variable. || .- xxxx [ yyyy ] +/- zzzz || Reachability register (octal) -. | xxxx = adjusted offset, || Log2(Polling interval) --. | | yyyy = measured offset, || \ | | zzzz = estimated error. || | | \ MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* 192.168.1.10 3 6 377 45 -123us[-456us] +/- 12ms ^+ time.cloudflare.com 2 6 377 46 +456us[+789us] +/- 9ms ^- ntp.aliyun.com 1 6 377 47 -987us[-321us] +/- 15ms

   • 第一列符号：^*是当前同步源，^+是好的备用源，^-是候选源但未被选中，^?表示源不可达或状态未知。
   • Reachability register (octal)：一个8进制的数，表示最近8次查询的成功/失败历史（成功为1，失败为0）。377（二进制11 111 111）表示最近8次全部成功，连接非常健康。0或很小的值表示连接有问题。
   • Last sample：-123us[-456us] +/- 12ms。第一个数字（-123us）是调整后的偏移量，第二个方括号内的数字（-456us）是原始测量偏移量，+/- 12ms是估计误差。偏移量在毫秒（ms）甚至微秒（us）级别是正常的。

3. chronyc sourcestats -v：查看时间源的统计信息，如偏移、延迟的标准差，帮助你判断源的稳定性。

4. chronyc activity：查看有多少时间源在线、离线等概要信息。

4.2 手动干预与调试命令

• 手动立即同步：chronyc makestep。有时你想立刻纠正时间，可以运行此命令。但注意，如果偏差超过makestep阈值，这会导致步进调整。
• 手动添加/删除时间源（临时生效，重启服务后失效）：

  chronyc add server ntp.newserver.com iburst chronyc delete server ntp.badserver.com

• 检查NTP服务器是否可达：chronyc ntpdata <server-ip>可以显示从该服务器获取的原始NTP数据包信息，用于深度调试。

4.3 常见问题与排障思路

问题1：chronyc sources显示所有源都是^?（不可达）。

• 检查网络：ping ntp.aliyun.com是否通？防火墙是否放行了UDP 123端口（出站）？对于客户端，出站规则需要允许udp/123。
• 检查DNS：如果使用域名，检查dig ntp.aliyun.com是否能解析。
• 检查服务状态：systemctl status chronyd确认服务正在运行。

问题2：时间同步了，但偏移量（offset）始终很大（几十到几百毫秒）。

• 网络延迟高：检查chronyc tracking中的Root delay。如果超过100ms，可能是网络路径不佳。尝试更换延迟更低的时间源。
• 系统负载高：在系统负载极高时，chronyd进程可能无法获得足够的CPU时间来进行精确测量。检查系统负载（uptime）和chronyd进程的CPU使用率。
• 虚拟机时钟问题：虚拟机（特别是KVM、VMware）的虚拟时钟可能不稳定。确保安装了VMware Tools或VirtualBox Guest Additions，并启用时间同步功能。对于KVM，可以考虑在宿主机和客户机都使用chrony，并配置/etc/chrony.conf中的rtcsync和更积极的makestep参数。有时，在虚拟机中需要禁用ntpd或timesyncd，避免多个时间服务冲突。

问题3：chronyc tracking显示Stratum很大（比如16）。

• 所有时间源都丢失：这意味着chronyd无法与任何配置的上游服务器通信，并且local stratum指令也未启用或生效。它会将自己标记为未同步的层16时钟。检查网络和源配置。
• local stratum未生效：如果你希望在没有外部源时作为本地源，确保配置了local stratum 10（或其他数字，非16）并且allow了客户端网段。

问题4：时间同步服务与其他服务冲突。

• 与systemd-timesyncd冲突：一些较新的发行版（如Ubuntu 16.04+）默认使用systemd-timesyncd进行轻量级时间同步。如果安装了chrony，务必禁用systemd-timesyncd：systemctl stop systemd-timesyncd && systemctl disable systemd-timesyncd。
• 与ntpd冲突：两者不能同时运行。使用systemctl stop ntpd && systemctl disable ntpd禁用ntpd。

5. 进阶话题与生产环境实践

5.1 虚拟化环境下的时间同步挑战

在VMware、KVM、Hyper-V等虚拟化环境中，虚拟机的时钟是个“老大难”问题。虚拟机的时钟依赖于宿主机的时钟和CPU的计时器（如TSC），在虚拟机被调度休眠或宿主负载高时，虚拟时钟容易发生“漂移”甚至“跳变”。

最佳实践组合拳：

1. 宿主机层面：确保宿主机自身的时间同步是精准和稳定的。在宿主机上配置chrony，使用可靠的外部源，并启用hwtimestamp（如果硬件支持）。
2. 虚拟机工具：务必安装并运行VMware Tools、VirtualBox Guest Additions或KVM的virtio驱动。这些工具提供了与宿主机时钟同步的“准虚拟化”接口，比纯粹模拟的硬件时钟稳定得多。
3. 客户机配置：在虚拟机内，chrony配置需要更“激进”。
   • 减小maxpoll：增加同步频率，例如maxpoll 6（64秒）。
   • 调整makestep：使用makestep 0.1 -1，允许对超过0.1秒的偏差进行步进调整。对于虚拟机，小的步进调整（亚秒级）通常比大的渐进漂移对应用影响更小。
   • 禁用其他同步源：确保虚拟机内只运行chronyd，并禁用任何由虚拟化平台注入的旧式时间同步（如VMware的tp服务）。
   • 考虑使用chrony的smoothtime功能（实验性）：它可以尝试平滑处理来自虚拟化工具的时间更新，减少跳变感。

5.2 容器与Kubernetes中的时间

容器共享宿主机的内核，因此也共享系统时钟。容器内部无法运行chronyd来独立调整时间。这意味着：

• 宿主机时间必须准确：所有运行容器的宿主机节点，其时间必须通过chrony或其他方式保持高度同步。在K8s集群中，这是节点准备的基本要求。
• 容器内应用的处理：如果你的容器化应用对时间极其敏感，需要考虑在应用层面使用NTP客户端库（如ntplib）直接查询外部NTP服务器，但这会增加复杂性和网络依赖。更常见的做法是确保宿主机时间可靠，并信任它。

5.3 闰秒处理

闰秒是偶尔被添加到协调世界时（UTC）中的一秒，以补偿地球自转的微小变化。chrony默认知道如何处理闰秒。

• chronyc tracking输出中的Leap status字段会显示状态：Normal、Leap second等。
• chrony支持两种处理方式：在闰秒时刻通过step（跳秒）或slew（在更长时间内微调时钟频率）来消化这一秒。现代Linux内核和chrony的默认配合通常是平滑处理。
• 对于金融交易等极端场景，需要关注闰秒公告，并进行测试。可以通过chronyc leapsectz查看配置的时区闰秒信息。

5.4 安全考虑

• 认证：chrony支持使用对称密钥（keyfile）进行NTP消息认证，防止中间人攻击或恶意NTP服务器。这在严格的内网安全要求中可能需要配置。
• 服务暴露：除非必要，不要将chronyd绑定到公网IP（bindcmdaddress 0.0.0.0）。如果作为内网时间服务器，使用防火墙严格限制访问源IP（allow指令是第一道防线，但结合主机防火墙如firewalld或iptables是更佳实践）。

6. 从理论到实践：一次完整的时间偏差排查实录

最后，分享一个我最近遇到的实际案例。监控报警显示，某台运行Java应用的服务器，其日志时间与日志收集中心的时间存在约5秒的固定偏差。

第一步：快速确认问题登录服务器，先用date命令查看系统时间，同时用curl访问一个提供精确时间的API（如http://worldtimeapi.org/api/timezone/Etc/UTC）进行对比，确认偏差确实存在。

第二步：检查chrony状态

chronyc tracking

发现System time显示+5.123456 seconds fast。说明chronyd已经意识到了这5秒的偏差。

第三步：分析时间源

chronyc sources -v

发现当前同步源（^*）的Reach值是177（二进制01 111 111），表示最近8次中有7次成功，有一次失败。Last sample的误差（+/-值）较大，达到+/- 100ms。而另一个备用源（^+）的Reach是377（全成功），误差只有+/- 10ms。这说明当前选中的源质量不稳定。

第四步：深入探查与干预为什么chronyd不切换到更好的源？运行chronyc sourcestats查看历史统计，发现当前源虽然最近有一次失败，但其历史测量的偏移标准差（Std dev）很小，而备用源虽然当前延迟低，但过去一段时间偏移波动较大。chrony的算法更倾向于长期稳定的源，这是合理的，但也导致了当前偏差无法快速纠正。

第五步：手动干预与验证由于业务对时间敏感，我决定手动干预。

1. 首先，尝试让chronyd立即重新评估并同步：chronyc makestep。但偏差5秒超过了默认的makestep 1000 3阈值，所以它执行了步进调整。应用日志出现了1条关于时间跳变的警告，但之后恢复正常。
2. 步进调整后，再次检查chronyc tracking，偏移量变为微秒级。
3. 为了预防未来再次因源质量导致偏差累积，我修改了/etc/chrony.conf：
   • 将不稳定的那个时间源注释掉。
   • 增加了两个新的、知名的低延迟公共NTP源。
   • 将makestep策略改为makestep 0.5 3，允许在启动初期对超过0.5秒的偏差进行步进调整，以期更快收敛。
4. 重启chronyd：systemctl restart chronyd。
5. 观察几分钟后，运行chronyc sources -v，确认新的源被选中且状态健康（Reach值为377）。

经验点：chrony的“智能”算法大多数时候是优点，但在时间源质量发生微妙变化时，它可能“恋旧”。作为运维人员，不能完全放任自流，需要定期（比如通过监控chronyc tracking的偏移量）检查同步状态。对于关键业务服务器，配置多个高质量、低延迟、来自不同运营商的时间源是性价比最高的稳定性提升手段。