任何应用功能再强大、性能再优越，如果没有与之匹配的监控，那么一切都是虚无缥缈的。监控不仅可以为应用提供运行时的数据作为依据参考，还可以迅速定位问题，提供预防及告警等功能，很大程度上增强了整体服务的鲁棒性。目前的 Kafka 监控产品有很多，比如 Kafka Manager、Kafka Eagle、Kafka Monitor、KafkaOffsetMonitor、Kafka Web Console、Burrow等，它们都有各自的优缺点。以Kafka Manager为例，它提供的监控功能也是相对比较完善的，在实际应用中具有很高的使用价值。但有一个遗憾就是其难以和公司内部系统平台关联，对于业务资源的使用情况、相应的预防及告警的联动无法顺利贯通。在人力、物力等条件允许的情况下，自定义一套监控系统非常有必要。

监控数据的来源

消息滞后

消息堆积是消息中间件的一大特色，消息中间件的流量削峰、冗余存储等功能正是得益于消息中间件的消息堆积能力。然而消息堆积是一把亦正亦邪的“双刃剑”，如果应用场合不恰当，反而会对上下游的业务造成不必要的麻烦，比如消息堆积势必会影响上下游整个调用链的时效性。在某些情况下，有些中间件如 RabbitMQ 在发生消息堆积时还会影响自身的性能。对Kafka 而言，虽然消息堆积不会给其自身性能带来太大的困扰，但难免会影响上下游的业务，堆积过多有可能造成磁盘爆满，或者触发日志清除操作而造成消息丢失的情况。如何利用好消息堆积这把双刃剑，监控是其中关键的一步。

同步失效分区

消费Lag是Kafka的普通使用者特别关心的一项指标，而同步失效分区（under-replicated）的多少是Kafka运维人员非常关心的一项指标。在8.1.1节中我们了解了失效副本的概念：处于同步失效或功能失效（比如处于非活跃状态）的副本统称为失效副本。而包含失效副本的分区也就称为同步失效分区。

监控指标说明

Kafka自身提供的JMX监控指标已经超过了500个，本书不可能一一将其罗列，只能挑选部分重要及常用的指标来进行说明。

这两个指标都是broker 端的指标，分别对应前面章节中提及的 byteIn和byteOut。

监控模块

Kafka 的监控架构主要分为数据采集、数据存储和数据展示这 3 个部分。数据采集主要指从各个数据源采集监控数据并做一些必要的运算，然后发送给数据存储模块进行存储。数据源可以是 Kafka 配套的 ZooKeeper、Kafka 自身提供的内部运行指标（通过 JMX 获取）、Kafka内部的一些数据（比如__consumer_offset 中存储的信息，通过 Kafka 自定义协议获取）、Falcon/Zabbix等第三方工具（或者其他类似的工具，主要用来监控集群的硬件指标）。 数据存储指将采集的原始数据经过一定的预处理后进行相应的存储，方便数据清洗（这个步骤可以省略）和数据展示。数据存储可以采用OpenTSDB之类的基于时间序列的数据库，方便做一些聚合计算，也可以附加采用Redis、MySQL等存储特定数据。

顾名思义，数据展示是将经过预处理的、存储的数据展示到监控页面上，以便提供丰富的UI给用户使用。当然数据展示模块也可以“绕过数据存储模块直接通向数据采集模块，或者从数据源直接拉取数据。

参考

• 深入理解Kafka：核心设计与实践原理 2019 朱忠华 此材料可能受版权保护。

如果这篇文章帮助到了你，欢迎评论、点赞、转发。