为什么告警堆积量和控制台堆积量不一致？

原因一

分区消息堆积量=分区最大位点-分区消费位点，而消息总堆积量则为各分区堆积量的总和。

例如：在一个实例中，有m个消费组和n个Topic，并且每个消费组都订阅了所有Topic，在计算某个消费组的消息堆积量时，有下面两种方式：

• 一般请求方式

  首先会发起一次RPC请求以获取该消费组的消费位点，然后再发起一次RPC请求以获取对应Topic的分区最大位点。此时，至少会产生m * n * Broker节点数次RPC请求，这将大大影响监控的计算效率。

• 批处理请求方式

  先获取所有消费组的消费位点，然后再批量请求获取所有订阅分区的最大位点。通过这种方式，能够将RPC请求的次数从m * n * Broker节点数缩减到仅为Broker节点数。由于批量请求的特性，获取消费位点的时间和获取分区最大位点的时间之间必然存在延迟，延迟期间分区的最大位点可能因消息发送而持续增大。这将导致在获取到消费位点与获取到分区最大位点之间产生时间差，从而引发消息堆积量的误差。

控制台Group 详情页面中的消息堆积总量是通过单独请求当前消费组的消费位点和分区最大位点来获取的，由于这两轮RPC请求之间的时间差相对较小，因此和实际消息堆积量的误差较小。监控中的消息堆积量采用批处理请求方式进行获取，因获取到消费位点与获取到分区最大位点之间产生时间差，必然会导致堆积量的误差，所以会出现告警堆积量与控制台堆积量之间存在不一致现象。

原因二

当用户的消费速率过慢且磁盘容量水位过高时，实例中的消息数据可能在未消费的情况下被删除，从而导致Group的分区消费位点小于最小位点。这种情况下开源Kafka和云消息队列 Kafka 版有不同的处理方式：

• 开源Kafka

  统计堆积量时默认会忽略该堆积量。

• 云消息队列 Kafka 版

  为了帮助您更快速地发现分区消费位点异常问题，监控报警策略会将该异常消费位点通过堆积报警的方式进行反馈，您可以根据实际情况进行处理。

云消息队列 Kafka 版为方便您在控制台上区分异常分区和正常分区，控制台Group 详情页面中的消息堆积总量不会统计该异常堆积量，因此监控中的堆积量会远大于控制台显示消息堆积量，所以会出现告警堆积量与控制台堆积量之间存在不一致现象。

具体现象如下图所示：

• 控制台消息堆积总量和告警堆积总量不一致。

  

• 控制台消息堆积总量没有统计异常堆积量。

  

• 没有统计异常堆积量的Topic消费详情中存在分区消费位点小于最小位点的情况。