4. 网络排查工具：ntpq -p、chronyc sources、ptp4l 状态查看
时钟同步出问题的时候，你第一反应是什么？
我个人的习惯是——先看工具输出。别急着改配置，先看看当前系统到底在跟谁同步，偏差有多大。说白了，诊断的第一步就是「问状态」。
这一节，咱们把三个最常用的排查工具掰开揉碎讲清楚。分别是 NTP 时代的 ntpq -p、Chrony 时代的 chronyc sources，以及 PTP 时代的 ptp4l 状态查看。每个工具我都踩过坑，咱们一个一个来。
4.1 ntpq -p：老牌工具，但依然能打
如果你还在用传统的 NTP 服务，ntpq -p 就是你最亲密的战友。我在项目中遇到过好几次，用户说「时间不准了」，我第一件事就是 SSH 上去敲这个命令。
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*ntp1.aliyun.com .INIT. 1 u 62 64 377 28.123 -0.052 0.023
+ntp2.aliyun.com 100.122.123.1 2 u 31 64 377 32.456 +0.018 0.035
-ntp3.aliyun.com 192.168.1.1 3 u - 64 17 45.678 +5.234 1.234
这个输出怎么看？我教你几个关键点：
- 第一列前面的符号：
*表示当前同步源，+是候选源，-是被排除的源。如果没有任何*，说明系统没同步上。 - st（Stratum）：层级。越小越准。1 是原子钟，2 是跟原子钟同步的服务器，以此类推。我见过有人配了 stratum 10 的源，那基本等于没配。
- when：上次查询到现在过了多少秒。如果这个值一直增长，说明通信断了。
- reach：八进制表示的成功率。377 表示最近 8 次全部成功，0 表示全部失败。嗯，这里要注意，如果 reach 是 0，那基本可以断定网络有问题。
- offset：偏差值，单位毫秒。正数表示本地比源慢，负数表示本地比源快。绝对值超过 1000ms 就要警惕了。
ntpq -p 输出为空，先检查 NTP 服务是否在运行。用 systemctl status ntpd 看一眼。我曾经排查了半小时，最后发现服务根本没启动。
4.2 chronyc sources：现代系统的首选
现在大多数新系统都默认用 Chrony 了。为什么？因为它同步更快，对网络抖动的容忍度更高。我个人也更喜欢 Chrony，尤其是在虚拟机环境里，表现比老 NTP 好太多。
查看同步源状态，用这个命令：
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
===============================================================================
^* ntp1.aliyun.com 2 6 377 32 -5us[ -8us] +/- 11ms
^- ntp2.aliyun.com 2 6 377 63 +12us[ +12us] +/- 13ms
^? ntp3.aliyun.com 3 6 0 112 +20ms[ +20ms] +/- 40ms
你看，这个输出比 ntpq 更详细。我重点看这几个字段：
- Source state：
*是当前同步源，^?表示不可达。如果全是^?，那网络肯定有问题。 - Reach：同样是八进制，377 是满分。0 就是全丢。
- Last sample：最近一次采样的偏差。注意看单位，
us是微秒，ms是毫秒。偏差在微秒级说明状态很好。
chronyc sources 显示 * 正常，但时间就是不准。后来发现是防火墙把 NTP 端口封了，但 Chrony 用了别的端口做测量。所以，光看状态还不够，还得用 chronyc tracking 看实际偏差。
顺便提一句，chronyc tracking 也很重要。它会告诉你系统当前的时钟偏差、频率偏差、以及最后一次校正的时间。我一般两个命令配合着用。
4.3 ptp4l 状态查看：高精度场景的利器
如果你在做金融交易、5G 基站或者工业控制，那 PTP（精确时间协议）才是你的菜。PTP 的精度能到纳秒级，比 NTP 高好几个数量级。
PTP 的守护进程叫 ptp4l。查看它的状态，我通常用两种方式：
4.3.1 直接看日志输出
ptp4l 默认会把状态打印到标准输出。关键信息长这样：
ptp4l[12345]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED.
ptp4l[12345]: rms 12 ns max 45 ns freq -12345 ppb delay 567 ns
这里要注意几个状态机转换：
- UNCALIBRATED → SLAVE：这是正常流程，表示从钟已经锁定主钟。
- rms 12 ns：均方根偏差，12 纳秒，相当不错。
- freq -12345 ppb：频率偏差，单位是十亿分之一。这个值如果太大，说明本地晶振质量不行。
- delay 567 ns：路径延迟。这个值如果突然变大，可能是网络拓扑变了。
UNCALIBRATED 或者 LISTENING，说明主从之间没协商成功。我遇到过最坑的一次，是交换机的 PTP 透明时钟功能没开，导致报文被丢弃。
4.3.2 用 pmc 工具查询
pmc 是 PTP 的管理工具，可以主动查询状态。我个人习惯用这个命令：
pmc -u -b 0 'GET CURRENT_DATA_SET'
currentDS.offsetFromMaster: -12
currentDS.meanPathDelay: 567
currentDS.stepsRemoved: 1
- offsetFromMaster：与主钟的偏差，单位纳秒。负值表示本地比主钟快。
- meanPathDelay：平均路径延迟。这个值应该稳定，如果剧烈抖动，说明网络有问题。
- stepsRemoved：跳数。1 表示直连主钟，2 表示经过了一级边界时钟。
ethtool -T eth0 查看。如果不支持硬件时间戳，PTP 精度会从纳秒级掉到微秒级，那就失去意义了。
4.4 三个工具的核心对比
为了方便你快速选择，我整理了一个对比表：
| 工具 | 适用场景 | 精度 | 关键字段 | 常见问题 |
|---|---|---|---|---|
| ntpq -p | 传统 NTP 环境 | 毫秒级 | reach, offset, st | reach 为 0，无 * 符号 |
| chronyc sources | 现代 Linux 系统 | 毫秒级 | Reach, Last sample, Source state | ^? 不可达，偏差突变 |
| ptp4l / pmc | 高精度场景 | 纳秒级 | rms, offsetFromMaster, delay | 状态卡在 UNCALIBRATED |
你想想看，这三个工具其实覆盖了从毫秒到纳秒的整个精度范围。排查时，先确认你用的是哪个协议，再选对应的工具。别拿 ntpq 去查 PTP 环境，那肯定查不出东西。
4.5 知识体系结构图
下面这张图，帮你理清这三个工具的关系和排查路径：
说白了，这三个工具就是你的「三把刀」。NTP 环境用 ntpq，Chrony 环境用 chronyc，PTP 环境用 ptp4l。别搞混了。我见过有人用 ntpq 去查 Chrony 的状态，结果啥也看不到，还以为是系统坏了。
嗯，这一节的内容就到这儿。工具是死的，人是活的。多敲几次命令，你自然就能一眼看出问题在哪儿。
公众号:蓝海资料掘金营，微信deep3321