看花眼了，这96.84是GB，不是百分比。。那和报告也对不上啊 @辞霜
是ocp的ip对着巡检集群执行clockdiff
这里看应该是采集的数据传输异常了，把used当成percent传输了。
试一下442版本吧
[root@cdh85-138 chansey]# clockdiff -o 192.168.81.38
Overflow 2 hops
.Overflow 2 hops
.Overflow 2 hops
.Overflow 2 hops
…
host=192.168.81.38 rtt=5(0)ms/3ms delta=0ms/0ms Tue May 26 18:17:24 2026
ocp往报错机器试clockdiff也是有结果的
还有就是ocp集群本身的巡检报告里也有这个clockdiff的can not query报错，明明clockdiff自己也是ok的
[root@cdh85-138 chansey]# clockdiff -o 172.20.85.138
.
host=172.20.85.138 rtt=750(187)ms/0ms delta=0ms/0ms Tue May 26 18:17:00 2026
你ocp是root用户部署的么。
是的 obd机器的root用户跑的部署，然后ocp机器上我ps -ef|grep server看也是运行在root下面的
1 个赞
感谢分享！
1 个赞
这个场景还没遇到过
1 个赞
大佬今天能再继续帮忙分析下吗
你升级ocp442版本吧，这边测试是没啥问题的。 磁盘检查问题是个已知bug在442修复了
你看下是否有chronyc或者ntpq命令
- 通过 ntpq 命令检查 NTP 偏移量：
ntpq -np | grep ‘^*’
∘ 该命令会列出当前 NTP 同步的服务器信息，其中以 * 开头的行表示当前正在使用的时钟源。
∘ 关注 offset 列的值，单位为毫秒（ms）。如果偏移量超过阈值（默认为 50ms 或 100ms），需要进行调整。
- 通过 chronyc 命令检查 Chrony 偏移量（如果使用 Chrony 服务）：
chronyc tracking
∘ 该命令会显示当前 Chrony 的时间同步状态，关注 Last offset 字段的值。
好的好的 多谢，我先升一下
OCPserver上都有，启用的是chronyd
磁盘是预占用的，是正常的
学到了
大佬，升级升挂了，能帮忙看看么
mark~~
66
66666