用 chrony 校准服务器时间（替代 ntpd / systemd-timesyncd）

时间不准的服务器会引发各种诡异 bug：

TLS 证书"还没生效"或"已过期"
Kerberos 认证失败
分布式日志时间错乱，没法 trace
数据库主从复制时间戳混乱

systemd-timesyncd 是 Ubuntu 默认的 SNTP 客户端，能用但功能很基础
（只读 NTP，不会被别人查询，调整精度一般）。生产用 chrony，
小内存占用 + 快收敛 + 网络中断后的快速恢复。

安装 + 切换

sudo systemctl disable --now systemd-timesyncd
sudo apt install -y chrony
sudo systemctl enable --now chrony

# 校验当前用的是哪个
timedatectl
# System clock synchronized: yes
# NTP service: active

配置

/etc/chrony/chrony.conf 主流 distro 自带的默认就能跑。
生产建议改：

# 优先用 pool 而不是 server —— 自动负载均衡到多台
pool 2.debian.pool.ntp.org iburst maxsources 4

# 国内服务器换国内源
# pool cn.pool.ntp.org iburst maxsources 4
# server ntp.aliyun.com iburst
# server ntp.tencent.com iburst

# 启动后的前 10 个样本只要测量到偏差就立即跳调
makestep 1.0 10

# 系统时钟同步到 RTC 硬件时钟（关机后保留）
rtcsync

# 允许哪些客户端查询（如果本机也是 NTP server）
# allow 192.168.0.0/16
# 默认拒绝，注释掉它就 client-only

# 数据存储
driftfile /var/lib/chrony/chrony.drift
makestep 1 3
keyfile /etc/chrony/chrony.keys
ntsdumpdir /var/lib/chrony

# 日志
logdir /var/log/chrony
log measurements statistics tracking

iburst 是关键：启动时连发 8 个查询，秒级完成初始同步（默认每 64 秒一次
会慢得让人无奈）。

校验

# 当前选用的服务器 + 偏差
chronyc tracking
# Reference ID    : C0A87B0F (ntp1.aliyun.com)
# Stratum         : 3
# Ref time (UTC)  : Sat May 23 09:00:12 2026
# System time     : 0.000001234 seconds slow of NTP time
# Last offset     : +0.000045678 seconds
# RMS offset      : 0.000123456 seconds
# Frequency       : 12.345 ppm slow
# ...

# 看所有 source 状态
chronyc sources
# MS Name/IP address         Stratum Poll Reach LastRx Last sample
# ===============================================================
# ^* 100.100.5.1                   2   7   377   45   +12us[+15us] +/- 1567us

# ^* 是当前在用；^+ 是候选；^? 是不可达；^x 不一致；^- 被算法排除

# 各 source 的详细测量
chronyc sourcestats

System time 在毫秒级即合格；几十微秒到几百微秒是 Internet NTP 的正常范围。

NTS（NTP over TLS）

新硬件 / 新版 chrony 支持 NTS，给 NTP 流量加密 + 鉴权（防中间人篡改时间）：

server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts

需要 nts 关键字 + chrony >= 4.0 + 客户端能解析 nts 服务器的证书链。

给本机当 NTP server

# /etc/chrony/chrony.conf
allow 192.168.0.0/16    # 内网客户端
allow 10.0.0.0/8

# 监听 IPv4 / IPv6（默认开）
# bindaddress 0.0.0.0

sudo systemctl restart chrony
sudo ufw allow 123/udp comment 'NTP'

客户端 chrony.conf 写 server <你这台>.example.com iburst。

强制立即同步

sudo chronyc -a 'burst 4/4'
sudo chronyc -a makestep
# 之前都不行的话直接：
sudo chronyc -a 'manual on' && sudo chronyc settime ...

监控

# Prometheus node_exporter 自带 chrony collector
# node_chrony_system_time_offset_seconds 是要报警的指标
# 阈值 > 0.01 秒就告警

# 或直接定时脚本检查偏移
chronyc tracking | awk '/System time/ {print $4}' | xargs -I {} \
  python3 -c "import sys; v=abs(float('{}')); sys.exit(0 if v<0.01 else 1)"

踩过的坑

在云上（AWS / GCP / Azure）建议用 云供应商提供的内网 NTP 而不是公网
pool：低延迟 + 不出 VPC + 通常更稳定（AWS: 169.254.169.123）。
容器里运行的程序看到的时间是宿主的；容器里跑 chrony 多此一举，反而可能
和宿主冲突。
虚拟机长时间挂起后 wakeup，时间漂移可能很大，触发 makestep 跳变。
如果业务对时间不能跳（金融 / log 单调），考虑把 makestep 关掉接受
slewing（缓慢调整）。
同步上游用 IP 而不用域名时，AWS / 云上 169.254.169.123 这类 link-local
地址不要经过 DNS（永远查不到）。