开头
该 topic 有点唬人，只为水一篇文章, 如果大家有跟我类似的调用链路 trace 需求，则需要关注下时间校对问题.
缘由
收到了大量的消息高延迟的报警信息, 排查了一圈可以确定 push 内部运转正常, 但为什么会出现高延迟的问题 ?
大部分的消息延迟在 < 100ms 区间内, 但通过监控图可以看到还有一部分耗时集中在 15s-30s 区间, 这个延迟着实有点高呀.
通过监控系统查了近半个月的耗时曲线，耗时随着日期而加大, 半个月前的最高耗时在 3s, 半个月之后直接爆到 30s.
我们在系统里对消息加入各个流程的好时记录，监控图中的延迟是 cost = (消费发给客户端时间点 – 业务端发送时间点), 通过 kibana 抽查了几个慢消息的trace, 让人奇怪的日志和时间乱掉了 ?
日志的时间就是日志中的时间字段，而不是 filebeat 的收集时间. 既然时间不对，那么可以猜测出大概率是时间无对齐.
果然 ops 给我的答复是 ntp 关闭了自动同步, ntp 关了那么就只能依赖于晶振脉冲了, 但这玩意在不同温度和湿度下产生不同的频率, 所以时间一长date就对不齐了.
简单说是因为时间不对，导致消息在各个组件中流转时记录偏移的时间戳. 所以，这也解释了为什么业务方没人投诉我.
解决 ?
运行 ntpdate 或者启动 ntpd 服务就可以了.
