告警里判断tidb或pd等节点是否重启的逻辑可以优化一下

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】5.3.3
【遇到的问题:问题现象及影响】
生产系统这两天一直莫名其妙的告警,pd和tidb均有,报节点重启的告警。
image

func (s ProcStat) StartTime() (float64, error) {

fs := FS{proc: s.proc}

stat, err := fs.Stat()

if err != nil {

return 0, err

}

return float64(stat.BootTime) + (float64(s.Starttime) / userHZ), nil

}

看了下代码,取值是系统时间点+进程启动时系统已分配的clock ticket对应的时长=进程启动时间点。

0 */6 * * * /usr/sbin/ntpdate ntp.cloud.aliyuncs.com ntp7.cloud.aliyuncs.com > /dev/null 2>&1

正好ntpdate每隔6个小时会同步一次,在18:00强行同步设置了系统时间,增大了1s,但不会修改clock ticket。

导致StartTime函数返回的值也大了1s,对应上grafana图:

官方对应pd或者tidb的restart的rule为
image

这边要改一下逻辑,再加一下间隔时间>10s优化一下这个问题。 process_start_time_seconds{job=“tidb”} - (process_start_time_seconds{job=“tidb”} offset 1m) >= 10

2 个赞

个人觉得这一块需要优化一下,小细节。

专业,一来就是源码级别的排查。

这个源码,我没有去查看过;大佬分析的专业

分析的有理有据。赞

回复有积分啊

确实要仔细看下,光看uptime看不出来问题。

其实是prometheus的代码。

:smile:,哈哈,多谢

专业,大佬分析的有理有据。

学习了。

如果这是一个产品需求,辛苦按照以下的要求进行反馈:

【需求涉及的问题场景】

【期望的需求行为】

【需求可替代方案】

【背景信息】
如哪些用户将从中获益,以及一些使用场景,任何API设计,模型或者图标都会更有帮助。

每隔6小时同步一次时间,都会有1秒的时间跳变吗,这个时间也太不准了?

会有几次,但不频发。