Kafka设计解析(二十三)关于Kafka监控方案的讨论
转载自 huxihx,原文链接 关于Kafka监控方案的讨论
目前Kafka监控方案看似很多,然而并没有一个“大而全”的通用解决方案。各家框架也是各有千秋,以下是我了解到的一些内容:
一、Kafka manager
Github地址: https://github.com/yahoo/kafka-manager。 这款监控框架的好处在于监控内容相对丰富,既能够实现broker级常见的JMX监控(比如出入站流量监控),也能对consumer消费进度进行监控(比如lag等)。另外用户还能在页面上直接对集群进行管理,比如分区重分配或创建topic——当然这是一把双刃剑,好在kafka manager自己提供了只读机制,允许用户禁掉这些管理功能。
二、Kafka Monitor
Github地址:https://github.com/linkedin/kafka-monitor。 这款监控框架更多的是关注对Kafka集群做端到端的整体系统测试,并产出各种系统级的监控指标,比如端到端的延时,整体消息丢失率等。对于新搭建的Kafka线上集群,使用Kafka Monitor做个整体测试有助于你了解该集群整体的一些性能,但若是用于日常监控该框架便有些不便了,需要自己修改webapp/index.html中的监控指标,流程上有些不太友好。不过这款框架的优势是其主要贡献者是LinkedIn的lindong(Kafka 1.0.0版本中正式支持JBOD就是lindong开发的),质量上应该是有保证的。
三、Kafka Offset Monitor
Github地址:https://github.com/quantifind/KafkaOffsetMonitor。 KafkaOffsetMonitor应该算比较早的监控框架了,有着很酷的UI,使用者也是很多。但其比较大的劣势是对新版本consumer和security的支持,另外该项目已经近2年未维护了,其主力开发甚至是另起炉灶,重新写了一个新的KafkaOffsetMonitor来支持新版本consumer——https://github.com/Morningstar/kafka-offset-monitor。不过目前该项目star数很少,应该没有大规模应用,到底是否适用于生产环境需要用户自行判断
四、Burrow
Github地址: https://github.com/linkedin/Burrow。 Burrow是LinkedIn开源的一款专门监控consumer lag的框架。事实上,当初其开源时我对它还是期待挺高的,不过令人遗憾地是后劲不足,发展得非常缓慢,而且这款框架是用Go写的,安装时要求必须有Go运行环境,故Burrow在普及上不如其他框架。Burrow没有UI界面,只开放了很多HTTP endpoint,这对于想偷懒的运维来说更是一个减分项。总之它的功能目前十分有限,普及率和知名度都是比较低的。不过好处是该项目主要贡献者是LinkedIn团队维护Kafka集群的主要负责人,故质量上是很有保证的
五、JMXTrans + InfluxDB + Grafana
这实际上是一套监控框架的组合。有着非常非常炫酷的UI效果,极其适合向领导展示。具体搭建方法网上有很多教程,可以参考下。这里就不再赘述了。
总之,目前Kafka的监控并没有“放之四海而皆准”的解决方案,应该说每种框架都有自己独到的地方。用户需要结合自身监控需求选择适合的监控框架~