HubSpot是如何监控Kafka的性能的
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读者交流群 
）。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
