印度机房 NTP 漂移：日志时间戳集体偏 47 秒

印度机房一批新增的采集节点，Ubuntu 22.04，chrony 默认配置，跑了大约两周后开始出现日志时间戳整体偏移。不是时区问题，UTC 数值本身错了：同一批 12 台机器里，有 5 台比参考机快 40 到 50 秒，另外 7 台正常。数据量不大，每台每天约 300MB 的日志，但下游按时间窗口做 join，偏移 47 秒足够让一批本该对齐的记录错位，排查时先怀疑时区，浪费了半天。

先确认不是时区：timedatectl 显示所有机器都是 UTC，TZ 环境变量也一致。再比对 chronyc tracking，偏移机显示 System time : 47.3 seconds fast of NTP time，Last offset 也是正值，说明是真实时钟漂移，不是显示问题。

处理步骤：

# 1. 看当前源和状态
chronyc sources -v
chronyc tracking

# 2. 强制立即校准（会跳变，先停写日志的服务）
sudo systemctl stop my-collector
sudo chronyc makestep

# 3. 确认偏移回到毫秒级
chronyc tracking | grep -E 'System time|Last offset'

但 makestep 只是止血。查 /etc/chrony/chrony.conf，发现这批机器用的是机房内网的两台 NTP 源，而这两台源本身没有上游，只靠本地晶振，配置里写着 local stratum 10。也就是说，源自己就在漂，客户端越同步越偏。

改法是把源换成可用的公网池加内网兜底，并限制单次最大校正步长：

pool ntp.ubuntu.com iburst maxsources 2
server 10.x.x.10 iburst prefer
makestep 1.0 3
maxslewrate 1000

makestep 1.0 3 表示前 3 次更新允许大于 1 秒时直接跳变，之后只做平滑调整。maxslewrate 1000 防止平滑调整太慢追不上。

为什么这样做：chrony 默认在小偏移时用 slew 慢慢追，大偏移要等 makestep 条件；如果上游源本身不准，客户端会把它当成真值，漂移被放大而不是纠正。把源分层、加兜底，是把单点故障从“时间源”这个最容易被忽略的地方挪开。代价是切换到公网源后，机房出口的 UDP 123 如果不通，chrony 会静默回退到内网源，状态看起来正常但精度没保证，所以必须看 chronyc sources -v 里每个源的 ^* 标记。

哪里会失效：容器里跑 chrony 没有意义，宿主机时钟才是真值；makestep 跳变会让依赖单调时钟的计时逻辑出错，停服务再跳是必须的；如果内网源是 stratum 10 且被标成 prefer，公网源再好也不会被选中。我自己踩的坑是只改了客户端没改源，第二周又漂回去，白折腾一轮。

你们在印度机房做时间同步时，内网源是单独配了上游，还是直接信任机房提供的 NTP 地址？