最近帮朋友处理一台服务器日志时间错乱的问题排查到最后发现是系统时钟漂移了快三分钟。三分钟在运维眼里可不短尤其是涉及定时任务、日志审计、数据库主从同步的场景时间一旦歪了连锁故障能让你怀疑人生。CentOS 7 自带的时间同步方案已经不是当年的 ntpdate 加 crond 了从我自己的使用体验来说chrony 才是目前最省心的选择配置简单、同步快、精度高而且对虚拟化环境的兼容性明显好过传统方案。这篇文章我就完整梳理一下 CentOS 7 上配置 chrony 时间源的整套流程包括安装、配置、验证、排查以及我在实际运维中踩过的坑。不管你手里是几台物理机还是一套内网虚拟化集群这套思路都能直接搬过去用。1. 为什么我建议弃用 ntpdate 和 ntpd改用 chronyCentOS 7 虽然还兼容 ntpdate/ntpd 那套老工具但官方已经明确把 chrony 作为默认的时间同步服务。这背后不单是例行更新而是 chrony 在很多关键特性上确实比老方案更适合现代服务器环境。1.1 老方案的三个突出问题先说 ntpdate。它本身是个一次性同步命令跑完就退出没有守护进程持续校时。以前常见的做法是把它写进 crontab每隔几分钟执行一次。但这里有个隐患ntpdate 的同步方式是跳变也就是直接把系统时间掰到正确值。如果是正跳会造成时间倒流对数据库这种依赖递增时间戳的服务来说这是很危险的。再来看 ntpd。它是常驻守护进程按理说比 crontab 调 ntpdate 靠谱但 ntpd 的问题在于起步慢。如果你系统时间差得特别多比如超过五分钟ntpd 默认会拒绝大幅调整它更擅长小幅度的渐进校准。这就导致刚部署或者长时间断电恢复的服务器时间长期停留在错误状态。生产环境里我遇到过好几回看到系统重启后时间差了十几分钟ntpd 却在日志里一直磨磨蹭蹭地微调。还有一个隐蔽问题——ntpd 对网络延迟和抖动非常敏感。在虚拟化环境里宿主机 CPU 抢占导致的时间波动很容易让 ntpd 误判为时钟异常进而触发警告甚至主动退出。1.2 chrony 设计上的核心优势chrony 由两个核心程序组成chronyd守护进程和 chronyc命令行控制工具。它跟我上面说的那几类毛病是针对性解决的。第一同步速度快。chrony 支持在启动后尽快完成一次粗同步即使时间偏差很大也能在几秒内校正到位。它的逻辑是先快速校准再逐步精调这种处理方式非常适合服务器重启之后快速回到正常时间线。第二频率补偿机制。chrony 不仅仅是把时间对准它还会持续跟踪系统时钟的频率误差也就是时钟走得快还是慢通过数学模型计算出漂移率并在后续进行补偿。这个机制让它能在不频繁发起网络请求的情况下长时间保持较高精度。第三网络条件适应性。chrony 在同步时会考虑网络往返延迟通过多次采样过滤掉明显异常的响应包。对于内网环境里偶发延迟、公共 NTP 服务器不稳定这类情况它的容忍度比 ntpd 高很多。从我实际使用的感受来说chrony 配置起来也更直观。ntpd 的配置文件里头参数类别多而 chrony 要用的指令就那几个理解成本低不少。2. 安装与环境准备两处容易被忽略的细节CentOS 7 默认安装时通常已经自带了 chrony但如果你用的是最小化安装或者做了裁剪镜像可能并没有装上。先确认一下再决定是否安装。2.1 安装与自启动直接通过包管理工具处理yum install -y chrony systemctl enable chronyd systemctl start chronyd这里有两个我经常在群里面强调的细节。第一个装完一定要检查 enable 状态。很多新手在本地跑通了 chronyd但忘了加入开机自启服务器一旦重启时间同步服务就彻底消失了而且还没有任何报错弹出来排查起来很被动。第二个细节selinux 和防火墙别忽略。默认情况下 chronyd 监听 UDP 123 端口如果你的服务器启用了 firewalld 并且没有放行 NTP 服务那么即使本机配置正确也会出现同步失败的状况。放行命令如下firewall-cmd --permanent --add-servicentp firewall-cmd --reload2.2 检查系统时间和时区在配置时间源之前先把系统时区校准到预期值。时区错误本身不是 chrony 的管辖范围但很多人会把这两个问题混在一起排查。timedatectl set-timezone Asia/Shanghai timedatectl status我在处理过的不少问题里发现有些服务器时间差了八个小时整这种往往不是同步问题而是时区设置成了 UTC。先解决时区再看同步情况否则你会在 chrony 的日志里看到时间已同步但系统时间仍然对不上业务的预期。另外建议顺手确认一下/etc/chrony.conf是否存在。如果之前为了做实验删过这个文件直接启动服务会失败报错信息是找不到配置文件。这种情况下最简单的办法是重新安装软件包把默认配置恢复出来。3. chrony.conf 配置文件逐项拆解每一个参数到底在管什么chrony 的配置逻辑不复杂但每个参数背后都有一层实际考量。我以一份典型的完整配置为例逐个说明关键项。# 示例配置/etc/chrony.conf server ntp1.example.com iburst server ntp2.example.com iburst pool 2.centos.pool.ntp.org iburst driftfile /var/lib/chrony/drift makestep 1 3 rtcsync allow 192.168.1.0/24 local stratum 10 logdir /var/log/chrony log measurements statistics tracking3.1 server、pool 与 iburstserver指令用来指定上游 NTP 服务器。后面跟的iburst参数建议一定要带特别是刚启动 chronyd 时。它表示在初始同步阶段会快速连续发送多个请求以便在很短时间内拿到一组有效响应。如果没有 iburstchrony 会按着正常的慢节奏去轮询首次同步可能要等几分钟才能完成。pool和server的主要区别在于pool 只是一个主机名对应的服务器池DNS 解析后可能得到多个 IPchrony 会从中挑选若干可达的地址进行连接。对于使用公共 NTP 池的场景用 pool 指令更合适。3.2 driftfile 的作用driftfile 就是用来保存时钟频率误差漂移率的文件。chronyd 在运行期间会不断估算系统时钟相对真实时间的偏移速度把这个值写入 driftfile。下次服务重启时chronyd 会先读取这个文件以之前学习到的漂移特性作为初始值从而缩短重新收敛的时间。这带来的一个显著收益是服务器的时钟是用出来的经验值。在正常使用几个小时后chrony 可以做到即使 NTP 服务器暂时不可达系统时间也能在一段时间内维持相对准确。不要把这个文件删掉也不要配置为 /dev/null 之类的虚拟路径否则每次启动都要重新学习。3.3 makestep 的玩法makestep 1 3是我最喜欢的一个参数。它表示如果检测到系统时间与标准时间之间的偏差大于 1 秒那么在服务启动后的前 3 个更新周期内chrony 会直接执行时间跳变step而不是渐进微调。这样设置的意图很明确开机瞬间优先保证时间立刻正确而不是等它慢慢爬。对于那种停机维护或断电后重启的服务器makestep 能避免系统带着明显错误的时间启动服务。如果你的业务系统接受不了时间跳变极端情况比如高频交易可以考虑把 1 改小一点或者不加这个参数但日常业务场景里makestep 的价值更大。3.4 rtcsync 与硬件时钟rtcsync启用后chronyd 会负责定期将系统时间写回硬件时钟RTC。不加这个参数的话硬件时钟的更新就只靠系统关机时的动作。服务器如果经常直接断电硬件时钟和系统时间的差距会越来越大。实际运维中建议保留这一行否则哪天你重启之后发现时间又回到过去十有八九就是硬件时钟带偏的。3.5 allow、local 与网络策略allow指定允许哪些网段的主机向本机请求时间同步服务。如果你这台机器只是作为客户端不需要对外提供时间服务allow 可以完全不配置。但如果你想让这台机器同时充当内网的时间源allow 这句就必须写好。local stratum 10的含义是当本机无法连接到任何上游服务器时它仍然宣告自己是 stratum 10 层的时间源可以向允许网段内的机器提供时间信息。这个配置要谨慎使用它只在断网但不希望内网客户端报错的场景下有意义。因为一旦上游恢复这个声明会自动被真实层级覆盖。4. 时间源怎么选内网环境下的层级规划思路这是很多人配置时容易陷入纠结的地方。到底用公共 NTP 服务器还是指定一台内网节点我的建议取决于你的网络环境和业务规模。4.1 直接使用公网 NTP 池如果你的服务器能直接访问互联网最简单的方式就是配置公共 NTP 池。CentOS 7 默认的配置里面保留了 CentOS 的 NTP 源实际生产中我更倾向于使用通用的公共 NTP 池。server 0.cn.pool.ntp.org iburst server 1.cn.pool.ntp.org iburst server 2.cn.pool.ntp.org iburst server 3.cn.pool.ntp.org iburst使用公共池时有个经验是不要把全部鸡蛋放在同一个池域名下。可以混搭比如用两个国内池域名加一个备用域这样即使某个解析结果统一故障还有另一条路。另外公共 NTP 服务器同样受到网络链路影响内网到外网的延迟波动、丢包都会反映到同步质量上如果你对时间精度要求很高纯公网模式并不理想。4.2 搭建内网时间源的正确姿势当你拥有多台服务器的时候更加合理的方案是选一台能访问公网的机器作为主时间源其他内网机器指向它。因为内网机器访问公网 NTP 会受出口带宽、防火墙策略、运营商链路等多重因素干扰而内网之间的 RTT 极低时间同步质量会好很多。我一般在规划时按这样的逻辑做角色机器配置特征上游主时间源能上公网的某台服务器server 公网NTP allow 内网段 local公网 NTP 池内部客户端无法访问公网的服务器server 主时间源IP iburst主时间源内部客户端备正常业务服务器同时配置 主时间源IP 和 另一个内网时间源IP两个内网源这里有一点需要注意内网主时间源的上游不要只配一个。至少要配置三个以上的公共 NTP 源因为一旦某个源响应异常主时间源自己还得兜底。实测中发现单个上游源在断网恢复之后同步回稳的时间会明显拉长。4.3 千万别让所有节点都指向公共 NTP我的一个真实经历是某个内网项目里约二十台服务器全都直接配置了公共 NTP 池。表面上每台机器都能正常同步但问题出在出口防火墙上——大量服务器同时高频访问外部 NTP 的 UDP 123 端口导致网关设备某些时段出现丢包进而引起部分机器时间同步中断。后来我改成两台内网时间源做冗余其余机器全部指向内网问题彻底消失。所以在这类配置里尽量把 NTP 请求收敛到少数入口。内网时间源之间互相用 server 指令做多点备份既保证冗余又不浪费带宽。5. 同步状态的检查和验证别再用 date 命令糊弄自己配置完以后第一件事当然是验证是否生效。但我要说一句很多新手不爱听的话——只看 date 输出根本不够。date 只能显示当前系统时间至于它跟真实时间的偏差、同步链路状态、频率误差一概看不出来。拿它跑一遍发现时间能对上就收工实际上是给自己埋雷。下面这几个验证手段才是我真正依赖的。5.1 chronyc tracking 输出的关键字段运行chronyc tracking输出大致类似:Reference ID : 192.168.1.2 (ntp-src.local) Stratum : 3 Ref time (UTC) : Mon Aug 21 15:30:45 2023 System time : 0.000123456 seconds fast of NTP time Last offset : 0.000013 seconds RMS offset : 0.000032 seconds Frequency : 1.234 ppm slow Residual freq : 0.000 ppm Skew : 0.002 ppm Root delay : 0.000987 seconds Root dispersion : 0.000123 seconds Update interval : 514.0 seconds Leap status : Normal重点看几项Leap status必须是 Normal表示没有闰秒告警或者未同步的异常状态。System time告诉你系统时间偏快还是偏慢单位是秒。Frequency系统时钟的频率漂移ppm百万分之一级别的数值。如果这个数字过大比如几百 ppm说明硬件时钟可能有问题。Update interval距离上一次成功更新时间。如果这个数值一直增大且没有刷新说明上游连接断了。Stratum层级数字越小越接近权威时钟源。内网客户端通常应该显示 3 或 4 左右。5.2 chronyc sources -v 的列含义另一个高频命令chronyc sources -v它会列出当前配置的所有时间源并给一个即时可达状态。看输出的关键点是状态符号^*表示当前选中的同步源^表示可用但未被选择候选^-表示被拒绝^?表示无法连接。如果所有源都是^?那多半是网络层面根本不通不是配置问题。5.3 日志文件是排查的重要依据chrony 的运行日志位于 /var/log/chrony/ 目录。默认情况下这个目录可能只有 chronyd.log 一个文件。我建议在配置里加上计量日志方便事后回溯log measurements statistics tracking加了之后会多出 measurements.log 和 statistics.log 两个文件。measurements.log 会显示每一次从远端收到的响应样本包括往返延迟和时间偏差。statistics.log 是聚合后的统计信息适合用来判断时间同步的长期稳定性。这些日志在排查为什么某段时期时间异常的时候价值很大。描述清楚哪个时间段开始漂移、当时和哪个服务器通信、往返延迟是否有尖峰基本就能定位问题范围。6. 排查实录三个我在实际环境中踩过的坑给再多的理论不如直接看几个实战问题。下面三个案例都是我或身边同事真实遇到过的说一下完整排查链路和最终解决办法。6.1 坑一chronyd 启动失败报错Could not open lock file现象是执行 systemctl start chronyd 后服务很快退出日志里出现类似 Could not open lock file /var/run/chronyd.pid 的报错。第一反应可能是权限问题但检查目录权限后并没有异常。排查链路其实是这样的先查进程是否已经存在。如果此前你已经手动启动过一次或者某个脚本调用了 chronyd 并常驻了再次启动就会因为锁文件被占用而失败。解决方法也简单systemctl status chronyd kill $(pgrep chronyd) systemctl start chronyd另外还有一种隐蔽原因就是在部分加固镜像里/var/run 被配置成只读临时文件系统。这种情况下需要确认目录挂载属性必要时把它换成持久化路径。不过这类场景比较少见不是常规排障首选。6.2 坑二时间同步正常但两台数据库服务器时间仍然互相偏移两台机器都配置了同一个 NTP 源chronyc tracking显示各自均已经同步系统时间也看不出明显问题但数据库主从复制偶尔报延迟对比两台服务器时间发现相差几十毫秒。深入查下来才意识到问题出在两台机器离 NTP 源的网络路径不对称。一台跟 NTP 源在同一个二层网络里另一台要经过三层路由和防火墙防火墙的深度检测带来了额外延迟。时间同步的精度受制于网络往返延迟网络路径不同收敛后的本地时间自然有细微差异。这种场景下我的处理建议是对于对时间一致性要求特别高的集群单独拉出一台低延迟的节点做专用时间源让集群内所有其他节点都直接指向它并且尽量让它们处于同一个广播域里。如果架构里无法保证这点就只能靠换用 PTP 精确时间协议来解决但那已经不是 chrony 的适用范畴了。6.3 坑三makestep 没有生效开机时时间依旧偏差很大配置里明明写了makestep 1 3但在某台机器上重启后观察时间仍然保持了错误值好像 makestep 根本没有触发。查看了 chronyd 日志发现它在启动后的几个周期内确实尝试做了调整但并没有跳变。排查后发现这台机器的系统时间偏差被 chrony 判断为小于 makestep 设定的阈值。因为偏差在 1 秒以内chrony 认为没必要跳变只做渐进微调就行。可问题在于业务上这个短暂的不一致也带来了负面影响。这类我以为会跳、实际没跳的情况比完全失效更难发现。处理办法是调整阈值比如makestep 0.1 3这样更小的偏差也会触发跳变。不过要注意跳变不可滥用它的副作用是时间瞬间变化会对依赖时序的应用造成冲击。常规建议是只在启动后初期允许跳变平时让 chrony 慢慢调整这个参数正是这种态度的体现。7. 经验总结与收尾建议回到开头那个帮朋友处理时间漂移的问题。最后我给他的方案其实特别朴素确认时区、装好 chrony、配好内网时间源、加好 makestep然后交给时间。做完这些之后他再没提过日志时间错乱的事。我在实际运维中总结下来chrony 配置这件事最重要的不是把配置文件写对而是建立起一套同步——验证——兜底的闭环意识。所谓兜底就是在服务异常时有人能第一时间发现而不是等到业务报障才想起来查时间。你可以在监控系统里加上对 chrony 状态的检查项比如脚本检测chronyc tracking是否返回 Normal 状态或者对系统时间与标准时间做一次偏差检测。这样才能保证同步服务长期稳定运行而不是只在刚配置完的那几天看起来一切正常。如果你只打算记住一个操作那我建议你把配置里这几项写好上游时间源至少两个、iburst 参数不要省、makestep 按业务场景设置、driftfile 让它自然积累。剩下的chrony 会自己干得很好。
最近帮朋友处理一台服务器日志时间错乱的问题排查到最后发现是系统时钟漂移了快三分钟。三分钟在运维眼里可不短尤其是涉及定时任务、日志审计、数据库主从同步的场景时间一旦歪了连锁故障能让你怀疑人生。CentOS 7 自带的时间同步方案已经不是当年的 ntpdate 加 crond 了从我自己的使用体验来说chrony 才是目前最省心的选择配置简单、同步快、精度高而且对虚拟化环境的兼容性明显好过传统方案。这篇文章我就完整梳理一下 CentOS 7 上配置 chrony 时间源的整套流程包括安装、配置、验证、排查以及我在实际运维中踩过的坑。不管你手里是几台物理机还是一套内网虚拟化集群这套思路都能直接搬过去用。1. 为什么我建议弃用 ntpdate 和 ntpd改用 chronyCentOS 7 虽然还兼容 ntpdate/ntpd 那套老工具但官方已经明确把 chrony 作为默认的时间同步服务。这背后不单是例行更新而是 chrony 在很多关键特性上确实比老方案更适合现代服务器环境。1.1 老方案的三个突出问题先说 ntpdate。它本身是个一次性同步命令跑完就退出没有守护进程持续校时。以前常见的做法是把它写进 crontab每隔几分钟执行一次。但这里有个隐患ntpdate 的同步方式是跳变也就是直接把系统时间掰到正确值。如果是正跳会造成时间倒流对数据库这种依赖递增时间戳的服务来说这是很危险的。再来看 ntpd。它是常驻守护进程按理说比 crontab 调 ntpdate 靠谱但 ntpd 的问题在于起步慢。如果你系统时间差得特别多比如超过五分钟ntpd 默认会拒绝大幅调整它更擅长小幅度的渐进校准。这就导致刚部署或者长时间断电恢复的服务器时间长期停留在错误状态。生产环境里我遇到过好几回看到系统重启后时间差了十几分钟ntpd 却在日志里一直磨磨蹭蹭地微调。还有一个隐蔽问题——ntpd 对网络延迟和抖动非常敏感。在虚拟化环境里宿主机 CPU 抢占导致的时间波动很容易让 ntpd 误判为时钟异常进而触发警告甚至主动退出。1.2 chrony 设计上的核心优势chrony 由两个核心程序组成chronyd守护进程和 chronyc命令行控制工具。它跟我上面说的那几类毛病是针对性解决的。第一同步速度快。chrony 支持在启动后尽快完成一次粗同步即使时间偏差很大也能在几秒内校正到位。它的逻辑是先快速校准再逐步精调这种处理方式非常适合服务器重启之后快速回到正常时间线。第二频率补偿机制。chrony 不仅仅是把时间对准它还会持续跟踪系统时钟的频率误差也就是时钟走得快还是慢通过数学模型计算出漂移率并在后续进行补偿。这个机制让它能在不频繁发起网络请求的情况下长时间保持较高精度。第三网络条件适应性。chrony 在同步时会考虑网络往返延迟通过多次采样过滤掉明显异常的响应包。对于内网环境里偶发延迟、公共 NTP 服务器不稳定这类情况它的容忍度比 ntpd 高很多。从我实际使用的感受来说chrony 配置起来也更直观。ntpd 的配置文件里头参数类别多而 chrony 要用的指令就那几个理解成本低不少。2. 安装与环境准备两处容易被忽略的细节CentOS 7 默认安装时通常已经自带了 chrony但如果你用的是最小化安装或者做了裁剪镜像可能并没有装上。先确认一下再决定是否安装。2.1 安装与自启动直接通过包管理工具处理yum install -y chrony systemctl enable chronyd systemctl start chronyd这里有两个我经常在群里面强调的细节。第一个装完一定要检查 enable 状态。很多新手在本地跑通了 chronyd但忘了加入开机自启服务器一旦重启时间同步服务就彻底消失了而且还没有任何报错弹出来排查起来很被动。第二个细节selinux 和防火墙别忽略。默认情况下 chronyd 监听 UDP 123 端口如果你的服务器启用了 firewalld 并且没有放行 NTP 服务那么即使本机配置正确也会出现同步失败的状况。放行命令如下firewall-cmd --permanent --add-servicentp firewall-cmd --reload2.2 检查系统时间和时区在配置时间源之前先把系统时区校准到预期值。时区错误本身不是 chrony 的管辖范围但很多人会把这两个问题混在一起排查。timedatectl set-timezone Asia/Shanghai timedatectl status我在处理过的不少问题里发现有些服务器时间差了八个小时整这种往往不是同步问题而是时区设置成了 UTC。先解决时区再看同步情况否则你会在 chrony 的日志里看到时间已同步但系统时间仍然对不上业务的预期。另外建议顺手确认一下/etc/chrony.conf是否存在。如果之前为了做实验删过这个文件直接启动服务会失败报错信息是找不到配置文件。这种情况下最简单的办法是重新安装软件包把默认配置恢复出来。3. chrony.conf 配置文件逐项拆解每一个参数到底在管什么chrony 的配置逻辑不复杂但每个参数背后都有一层实际考量。我以一份典型的完整配置为例逐个说明关键项。# 示例配置/etc/chrony.conf server ntp1.example.com iburst server ntp2.example.com iburst pool 2.centos.pool.ntp.org iburst driftfile /var/lib/chrony/drift makestep 1 3 rtcsync allow 192.168.1.0/24 local stratum 10 logdir /var/log/chrony log measurements statistics tracking3.1 server、pool 与 iburstserver指令用来指定上游 NTP 服务器。后面跟的iburst参数建议一定要带特别是刚启动 chronyd 时。它表示在初始同步阶段会快速连续发送多个请求以便在很短时间内拿到一组有效响应。如果没有 iburstchrony 会按着正常的慢节奏去轮询首次同步可能要等几分钟才能完成。pool和server的主要区别在于pool 只是一个主机名对应的服务器池DNS 解析后可能得到多个 IPchrony 会从中挑选若干可达的地址进行连接。对于使用公共 NTP 池的场景用 pool 指令更合适。3.2 driftfile 的作用driftfile 就是用来保存时钟频率误差漂移率的文件。chronyd 在运行期间会不断估算系统时钟相对真实时间的偏移速度把这个值写入 driftfile。下次服务重启时chronyd 会先读取这个文件以之前学习到的漂移特性作为初始值从而缩短重新收敛的时间。这带来的一个显著收益是服务器的时钟是用出来的经验值。在正常使用几个小时后chrony 可以做到即使 NTP 服务器暂时不可达系统时间也能在一段时间内维持相对准确。不要把这个文件删掉也不要配置为 /dev/null 之类的虚拟路径否则每次启动都要重新学习。3.3 makestep 的玩法makestep 1 3是我最喜欢的一个参数。它表示如果检测到系统时间与标准时间之间的偏差大于 1 秒那么在服务启动后的前 3 个更新周期内chrony 会直接执行时间跳变step而不是渐进微调。这样设置的意图很明确开机瞬间优先保证时间立刻正确而不是等它慢慢爬。对于那种停机维护或断电后重启的服务器makestep 能避免系统带着明显错误的时间启动服务。如果你的业务系统接受不了时间跳变极端情况比如高频交易可以考虑把 1 改小一点或者不加这个参数但日常业务场景里makestep 的价值更大。3.4 rtcsync 与硬件时钟rtcsync启用后chronyd 会负责定期将系统时间写回硬件时钟RTC。不加这个参数的话硬件时钟的更新就只靠系统关机时的动作。服务器如果经常直接断电硬件时钟和系统时间的差距会越来越大。实际运维中建议保留这一行否则哪天你重启之后发现时间又回到过去十有八九就是硬件时钟带偏的。3.5 allow、local 与网络策略allow指定允许哪些网段的主机向本机请求时间同步服务。如果你这台机器只是作为客户端不需要对外提供时间服务allow 可以完全不配置。但如果你想让这台机器同时充当内网的时间源allow 这句就必须写好。local stratum 10的含义是当本机无法连接到任何上游服务器时它仍然宣告自己是 stratum 10 层的时间源可以向允许网段内的机器提供时间信息。这个配置要谨慎使用它只在断网但不希望内网客户端报错的场景下有意义。因为一旦上游恢复这个声明会自动被真实层级覆盖。4. 时间源怎么选内网环境下的层级规划思路这是很多人配置时容易陷入纠结的地方。到底用公共 NTP 服务器还是指定一台内网节点我的建议取决于你的网络环境和业务规模。4.1 直接使用公网 NTP 池如果你的服务器能直接访问互联网最简单的方式就是配置公共 NTP 池。CentOS 7 默认的配置里面保留了 CentOS 的 NTP 源实际生产中我更倾向于使用通用的公共 NTP 池。server 0.cn.pool.ntp.org iburst server 1.cn.pool.ntp.org iburst server 2.cn.pool.ntp.org iburst server 3.cn.pool.ntp.org iburst使用公共池时有个经验是不要把全部鸡蛋放在同一个池域名下。可以混搭比如用两个国内池域名加一个备用域这样即使某个解析结果统一故障还有另一条路。另外公共 NTP 服务器同样受到网络链路影响内网到外网的延迟波动、丢包都会反映到同步质量上如果你对时间精度要求很高纯公网模式并不理想。4.2 搭建内网时间源的正确姿势当你拥有多台服务器的时候更加合理的方案是选一台能访问公网的机器作为主时间源其他内网机器指向它。因为内网机器访问公网 NTP 会受出口带宽、防火墙策略、运营商链路等多重因素干扰而内网之间的 RTT 极低时间同步质量会好很多。我一般在规划时按这样的逻辑做角色机器配置特征上游主时间源能上公网的某台服务器server 公网NTP allow 内网段 local公网 NTP 池内部客户端无法访问公网的服务器server 主时间源IP iburst主时间源内部客户端备正常业务服务器同时配置 主时间源IP 和 另一个内网时间源IP两个内网源这里有一点需要注意内网主时间源的上游不要只配一个。至少要配置三个以上的公共 NTP 源因为一旦某个源响应异常主时间源自己还得兜底。实测中发现单个上游源在断网恢复之后同步回稳的时间会明显拉长。4.3 千万别让所有节点都指向公共 NTP我的一个真实经历是某个内网项目里约二十台服务器全都直接配置了公共 NTP 池。表面上每台机器都能正常同步但问题出在出口防火墙上——大量服务器同时高频访问外部 NTP 的 UDP 123 端口导致网关设备某些时段出现丢包进而引起部分机器时间同步中断。后来我改成两台内网时间源做冗余其余机器全部指向内网问题彻底消失。所以在这类配置里尽量把 NTP 请求收敛到少数入口。内网时间源之间互相用 server 指令做多点备份既保证冗余又不浪费带宽。5. 同步状态的检查和验证别再用 date 命令糊弄自己配置完以后第一件事当然是验证是否生效。但我要说一句很多新手不爱听的话——只看 date 输出根本不够。date 只能显示当前系统时间至于它跟真实时间的偏差、同步链路状态、频率误差一概看不出来。拿它跑一遍发现时间能对上就收工实际上是给自己埋雷。下面这几个验证手段才是我真正依赖的。5.1 chronyc tracking 输出的关键字段运行chronyc tracking输出大致类似:Reference ID : 192.168.1.2 (ntp-src.local) Stratum : 3 Ref time (UTC) : Mon Aug 21 15:30:45 2023 System time : 0.000123456 seconds fast of NTP time Last offset : 0.000013 seconds RMS offset : 0.000032 seconds Frequency : 1.234 ppm slow Residual freq : 0.000 ppm Skew : 0.002 ppm Root delay : 0.000987 seconds Root dispersion : 0.000123 seconds Update interval : 514.0 seconds Leap status : Normal重点看几项Leap status必须是 Normal表示没有闰秒告警或者未同步的异常状态。System time告诉你系统时间偏快还是偏慢单位是秒。Frequency系统时钟的频率漂移ppm百万分之一级别的数值。如果这个数字过大比如几百 ppm说明硬件时钟可能有问题。Update interval距离上一次成功更新时间。如果这个数值一直增大且没有刷新说明上游连接断了。Stratum层级数字越小越接近权威时钟源。内网客户端通常应该显示 3 或 4 左右。5.2 chronyc sources -v 的列含义另一个高频命令chronyc sources -v它会列出当前配置的所有时间源并给一个即时可达状态。看输出的关键点是状态符号^*表示当前选中的同步源^表示可用但未被选择候选^-表示被拒绝^?表示无法连接。如果所有源都是^?那多半是网络层面根本不通不是配置问题。5.3 日志文件是排查的重要依据chrony 的运行日志位于 /var/log/chrony/ 目录。默认情况下这个目录可能只有 chronyd.log 一个文件。我建议在配置里加上计量日志方便事后回溯log measurements statistics tracking加了之后会多出 measurements.log 和 statistics.log 两个文件。measurements.log 会显示每一次从远端收到的响应样本包括往返延迟和时间偏差。statistics.log 是聚合后的统计信息适合用来判断时间同步的长期稳定性。这些日志在排查为什么某段时期时间异常的时候价值很大。描述清楚哪个时间段开始漂移、当时和哪个服务器通信、往返延迟是否有尖峰基本就能定位问题范围。6. 排查实录三个我在实际环境中踩过的坑给再多的理论不如直接看几个实战问题。下面三个案例都是我或身边同事真实遇到过的说一下完整排查链路和最终解决办法。6.1 坑一chronyd 启动失败报错Could not open lock file现象是执行 systemctl start chronyd 后服务很快退出日志里出现类似 Could not open lock file /var/run/chronyd.pid 的报错。第一反应可能是权限问题但检查目录权限后并没有异常。排查链路其实是这样的先查进程是否已经存在。如果此前你已经手动启动过一次或者某个脚本调用了 chronyd 并常驻了再次启动就会因为锁文件被占用而失败。解决方法也简单systemctl status chronyd kill $(pgrep chronyd) systemctl start chronyd另外还有一种隐蔽原因就是在部分加固镜像里/var/run 被配置成只读临时文件系统。这种情况下需要确认目录挂载属性必要时把它换成持久化路径。不过这类场景比较少见不是常规排障首选。6.2 坑二时间同步正常但两台数据库服务器时间仍然互相偏移两台机器都配置了同一个 NTP 源chronyc tracking显示各自均已经同步系统时间也看不出明显问题但数据库主从复制偶尔报延迟对比两台服务器时间发现相差几十毫秒。深入查下来才意识到问题出在两台机器离 NTP 源的网络路径不对称。一台跟 NTP 源在同一个二层网络里另一台要经过三层路由和防火墙防火墙的深度检测带来了额外延迟。时间同步的精度受制于网络往返延迟网络路径不同收敛后的本地时间自然有细微差异。这种场景下我的处理建议是对于对时间一致性要求特别高的集群单独拉出一台低延迟的节点做专用时间源让集群内所有其他节点都直接指向它并且尽量让它们处于同一个广播域里。如果架构里无法保证这点就只能靠换用 PTP 精确时间协议来解决但那已经不是 chrony 的适用范畴了。6.3 坑三makestep 没有生效开机时时间依旧偏差很大配置里明明写了makestep 1 3但在某台机器上重启后观察时间仍然保持了错误值好像 makestep 根本没有触发。查看了 chronyd 日志发现它在启动后的几个周期内确实尝试做了调整但并没有跳变。排查后发现这台机器的系统时间偏差被 chrony 判断为小于 makestep 设定的阈值。因为偏差在 1 秒以内chrony 认为没必要跳变只做渐进微调就行。可问题在于业务上这个短暂的不一致也带来了负面影响。这类我以为会跳、实际没跳的情况比完全失效更难发现。处理办法是调整阈值比如makestep 0.1 3这样更小的偏差也会触发跳变。不过要注意跳变不可滥用它的副作用是时间瞬间变化会对依赖时序的应用造成冲击。常规建议是只在启动后初期允许跳变平时让 chrony 慢慢调整这个参数正是这种态度的体现。7. 经验总结与收尾建议回到开头那个帮朋友处理时间漂移的问题。最后我给他的方案其实特别朴素确认时区、装好 chrony、配好内网时间源、加好 makestep然后交给时间。做完这些之后他再没提过日志时间错乱的事。我在实际运维中总结下来chrony 配置这件事最重要的不是把配置文件写对而是建立起一套同步——验证——兜底的闭环意识。所谓兜底就是在服务异常时有人能第一时间发现而不是等到业务报障才想起来查时间。你可以在监控系统里加上对 chrony 状态的检查项比如脚本检测chronyc tracking是否返回 Normal 状态或者对系统时间与标准时间做一次偏差检测。这样才能保证同步服务长期稳定运行而不是只在刚配置完的那几天看起来一切正常。如果你只打算记住一个操作那我建议你把配置里这几项写好上游时间源至少两个、iburst 参数不要省、makestep 按业务场景设置、driftfile 让它自然积累。剩下的chrony 会自己干得很好。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
