The alert system and the ApsaraMQ for Kafka console calculate message accumulation differently. A small discrepancy between the two values is expected and does not indicate a problem.
Both methods use the same per-partition formula:
Accumulated messages = Maximum offset - Consumer offsetThe total is the sum across all partitions. The discrepancy comes from when each method fetches the offsets.
How each method calculates message accumulation
Console (Group Details page)
The Group Details page fetches the consumer offset and maximum offset for each partition in separate, back-to-back remote procedure call (RPC) requests. Because the time gap between these two requests is small, the result closely reflects the actual accumulation at that moment.
Alert system
The alert system monitors all consumer groups and topics on an instance simultaneously. To reduce overhead, it batches offset requests: one RPC request fetches consumer offsets for all consumer groups, then another fetches maximum offsets for all partitions across all subscribed topics. This reduces the total number of RPC requests from m x n x number of brokers to just number of brokers, where m is the number of consumer groups and n is the number of topics.
The tradeoff is a timing gap. Producers keep sending messages between the two batch requests, so the maximum offsets increase while the consumer offsets stay fixed. This inflates the calculated accumulation.
Example: Suppose a partition has a consumer offset of 1,000 and a maximum offset of 1,050 when the first batch request runs. By the time the second batch request fetches the maximum offset 200 ms later, producers have written 30 more messages, pushing the maximum offset to 1,080. The alert reports 80 accumulated messages (1,080 - 1,000), while the console would report closer to 50 (1,050 - 1,000).
When expired messages cause larger discrepancies
If the consumption rate is very slow and disk usage is high, the instance may delete messages before consumers process them. In this situation, consumer offsets for some partitions fall below the minimum offset of the partition.
ApsaraMQ for Kafka and open source Apache Kafka handle expired-message partitions differently:
| Behavior | Apache Kafka | ApsaraMQ for Kafka |
|---|---|---|
| Alert calculation | Ignores partitions where consumer offset < minimum offset | Includes these partitions in the alert total |
| Console display | N/A | Excludes these partitions from the Group Details total |
Because the console excludes these abnormal partitions but the alert includes them, the alert value is larger than what the console shows. The following screenshots demonstrate this behavior.
The console and alert show different totals:
The console total excludes abnormal topics:
The console total excludes partitions where the consumer offset is below the minimum offset:
Which number to trust
For point-in-time accuracy, use the Group Details page in the console. It fetches offsets per partition with minimal timing gap.
For trend monitoring across many consumer groups, use the alert value. It is optimized for scale, not precision.
A small discrepancy between the two is normal. Investigate further only if the gap is consistently large or growing.
Suppress unwanted accumulation alerts
Ignore alerts for specific topics: Reset consumer offsets to 0 for the consumer group in the ApsaraMQ for Kafka console. The alert system stops reporting accumulation for those topics.
Disable accumulation alerts entirely: Submit a ticket to temporarily turn off the message accumulation alert feature.