时间不同步造成的trace高时延假象

开头

该 topic 有点唬人,只为水一篇文章, 如果大家有跟我类似的调用链路 trace 需求,则需要关注下时间校对问题.

缘由

收到了大量的消息高延迟的报警信息, 排查了一圈可以确定 push 内部运转正常, 但为什么会出现高延迟的问题 ?

大部分的消息延迟在 < 100ms 区间内, 但通过监控图可以看到还有一部分耗时集中在 15s-30s 区间, 这个延迟着实有点高呀.

通过监控系统查了近半个月的耗时曲线,耗时随着日期而加大, 半个月前的最高耗时在 3s, 半个月之后直接爆到 30s.

我们在系统里对消息加入各个流程的好时记录,监控图中的延迟是 cost = (消费发给客户端时间点 – 业务端发送时间点), 通过 kibana 抽查了几个慢消息的trace, 让人奇怪的日志和时间乱掉了 ?

日志的时间就是日志中的时间字段,而不是 filebeat 的收集时间. 既然时间不对,那么可以猜测出大概率是时间无对齐.

果然 ops 给我的答复是 ntp 关闭了自动同步, ntp 关了那么就只能依赖于晶振脉冲了, 但这玩意在不同温度和湿度下产生不同的频率, 所以时间一长date就对不齐了.

简单说是因为时间不对,导致消息在各个组件中流转时记录偏移的时间戳. 所以,这也解释了为什么业务方没人投诉我.

解决 ?

运行 ntpdate 或者启动 ntpd 服务就可以了.


大家觉得文章对你有些作用! 如果想赏钱,可以用微信扫描下面的二维码,感谢!
另外再次标注博客原地址  xiaorui.cc