如何正确地监控数据消费延迟

28 Apr 2018

需求: 监控数据消费地延迟, 最好以时间为度量

场景: kafka 消息队列 / mysql binlog 同步延迟

背景: 目前我们kafka, 做的是基于 offset 的延迟告警, 但这个不具有参考意义, 业务上能够更好理解的是时间上的延迟. 比如说: 配置变更还有多久到XIAN达SHANG战SHENG场XIAO?

预计的消费延迟 = 消息offset的差异 / 期望的消费消息的速率

由于每个topic的处理消息速率不一样, 这就导致基于offset的告警非常难做.

做法: kafka及mysql binlog都有生成时间戳相关字段. 取当前消费消息的时间戳, 和当前时间比较.

问题: 需要假定消息是一直产生的, 即假定最近消息产生时间戳=当前时间戳. 如果没有消息写入, 计算出来的延迟会越来越大, 产生误报.

改进: 最近写入消息的时间戳 - 最近消费的时间戳.

难点: 如何拿到最近消费时间戳 ???

MySQL binlog 解决”土办法”: 当前消费文件位置和show master status比较一下, 如果一样说明已经追到最新了, latency=0; 否则说明还在追, 比较保守的假定是最后消息产生时间戳=当前时间戳. latency=当前时间戳-最后消费消息的时间戳

注意MySQL binlog offset 不是每个事件一条单增, 而是基于文件位置的. 如果当前消费的文件 != master 最近的文件, 这个 offset 计算就坑了. MySQL binlog 文件是定期 rotate + 最大文件大小限制(max_binlog_size). 所以不太好计算offset的差异.

立个FLAG, 专门一篇研究下mysql replication / binlog相关的内容. 现在业务上基于mysql binlog做CDC, 对这块儿的深入理解还是挺重要的.

HOME