1. 介绍

kafka0.10.x监控项分析一文中,我们提到过,如何来监控broker、生产者和消费者。

生产者和消费者的监控需要给出client-id才能从通过JMX来监控。client.id属性可以在kafka属性配置配置文件中指定。

2. 疑惑

我们知道consumer经常会以一个组的形式来运行,同一个group下的消费者如果都采用同一个clinet-id,我们是否能以group的级别来进行监控呢?因为通过文档资料和自己查看JMX的MBean发现Kafka并不显示提供以group级别来监控消费者消费消息的情况。

为了验证猜想,我们简单做个实验。运行一个6个线程的消费者来消费消息。这6个线程在同一个group。然后通过观察MBean的值,来判断设定同一个client-id是否能够使得我们在group级别来监控消费者消费消息。

生产者和消费者的监控在broker和producer、consumer都分别存在一些监控项。如果只是单纯研究生产者和消费者收发的消息量,我们可以通过监控broker上的监控项即可。

下图中的fetch和produce即broker上可以监控生产者和消费者的项目。

2.1 设定同一个client-id

在JMC里面观察发现,设定同一个clinet-id(我们这里设定的client.id为test_client_id)在这里会只显示一个。我们通过观察broker上的byte-rate这个度量指标来判断,设定同一个client.id的时候,是否意味着所有组内的消费者监控项的值都进行了累加,从而达到了以group级别来监控组内所有消费者。

我们总共有两台broker,分别查看kafka.server下的byte-rate监控项的值

我们可以发现,如果线程全部设定一个client-id,那么这里只会显示一个。

PS: 该值基本每秒都变化,变化区间为80-120(此时生产者没有发送任何信息,这个信息量应该只是一些心跳信息)

2.2 设定不同的client-id

接下来我们将同一个组内的线程设定为不同client-id,然后查看各个线程的fetch-size-max值为多少。生产者仍然不发送任何信息。

  1. 10.45.10.31上的情况

  1. 10.45.10.34

剩下两个图就省略了,因为情况和10.45.10.31这台机器上的结果是差不多的。

2.3 总结

可见,设定同一个client-id,多个线程的值实际上会是会累加的。虽然kafka没有显示的提供了以group来进行监控,但是实际上,要做到也是十分简单的。

3. consumer和producer机器上的监控

刚才我们说的都是broker上的监控,现在我们也对consumer和producer上的监控看看是否具备这样的累加特性。

这里的监控项很多都是平均值和最大值以及一些消费速率。如果不进行大量数据收发,我们无法看出来监控的值是否是叠加。因此这里我们会用生产者产生大量信息,持续发送,然后观察records-consumed-rate来判断监控项是否有累加特性。

3.1 相同client-id

此时broker上的监控项情况

3.2 不同client-id

最后结束时,每个线程的record-consumed-rate,基本在8500的样子,其他几个差不多,我这里就不放图了。

此时broker上的情况

3.3 总结

经过以上实验可以发现,在consumer和producer上的JMX监控,如果采用了同一个clinet-id,并不会有累加效果,应该只是取了其中的一个线程的情况。我们可以看到图上的结果,在client-id相同和不同的2种情况下,在生产和消费端的机器上的监控值几本是差不多的,可以看那个record-consumerd-rate这个值。

反观broker上的byte-rate监控项,可以看到,当client-id不同时的byte-rate值乘以3,差不多即为client-id相同时,byte-rate监控的值。

4. 总结

  1. 设置相同client-id可以在broker上以group的级别监控消费者消费的速率
  2. 设置相同client-id在consumer端无法以group的级别监控所有消费者的消费的速率。JMX只会随机取一个线程来监控。