HubSpot 是如何监控 Kafka 的性能的

  • 谢丽

2015 年 10 月 11 日

话题:语言 & 开发架构

Sidekick是数字营销公司HubSpot的一款产品,用于在接收者打开邮件时实时通知发送者。创建和发送通知的基础设施以Kafka为基础创建。Ze'ev Klapow是 Sidekick 基础设施团队的一名资深软件工程师。近日,他撰文介绍了他们如何在 Sidekick 中监控 Kafka 的性能。

Sidekick 通知管道的架构大致如下:

Ze'ev指出,像上图这样就许多 Kafka 消费者连接在一起,需要监控每个消费者的性能,而且需要在消费者出现问题时快速定位。为此,他们开发了如下两个指标。

“增量(Delta)”

该指标用于确定消费者是否能够跟上某个主题的数据生成速度,如下图所示:

在 Kafka 中,每条消息会发送到某个主题的一个分区上,每条消息在写入时会获得一个递增的偏移量数值。消费者在消费消息时会记录它消费的最后一条消息的偏移量。增量即是该偏移量与分区头之前差异。对于每个 Kafka 消费者,他们会记录如下两个增量数据:

  • 增量总和为所有分区的增量之和。增量总和增加说明消费者太慢或数据量太大,可以考虑扩展消费者,或者增加并发。
  • 最大增量为所有分区中的最大增量。最大增量增加说明只有一个工作进程出现问题,或者分区之间没有实现很好的负载均衡。

“延迟(Lag)”

该指标用于监控消息处理延迟。在 Sidekick 中,他们会在所有的消息上都存储一个时间戳。如下图所示,总延迟为事件创建和通知发送之间的时间,可以帮助他们监控整个管道:

另外,如下图所示:

他们还可以进行更细粒度地延迟监控,这有助于在总延迟开始偏离正常轨道时进行调试。

按照 Ze'ev 的说法,上述两个指标提供了系统健康状况的一个完整视图。当消费者出现问题时,他们首先会依据下表进行问题判断:

   Δ↑

情况糟糕!

有地方出现问题了。

情况可能并不坏。

增量增加但延迟稳定可能代表流量峰值或类似的问题。

   Δ↑

增量没有增加,但延迟增加。

可能是该消费者的上游存在问题。

一切正常!

 

LAG↑

LAG↓

Ze'ev 表示,当出现问题时,此表可以为问题调试指明方向;当没有问题时,此表可以让他们对系统的性能更加自信。


感谢郭蕾对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群)。

语言 & 开发架构