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的监控并没有“放之四海而皆准”的解决方案，应该说每种框架都有自己独到的地方。用户需要结合自身监控需求选择适合的监控框架~