22 | 消费者组消费进度监控都怎么实现？

---

Kafka 核心技术与实战

客户端实践及原理剖析

22 | 消费者组消费进度监控都怎么实现？

对于 Kafka 消费者来说，最重要的事情就是监控它们的消费进度，或者说是监控它们消费的滞后程度。这个滞后程度有个专门的名称：消费者 Lag 或 Consumer Lag。

所谓滞后程度，就是指消费者当前落后于生产者的程度。 比方说，Kafka 生产者向某主题成功生产了 100 万条消息，消费者当前消费了 80 万条消息，那么就说消费者滞后了 20 万条消息，即 Lag 等于 20 万。

通常来说，Lag 的单位是消息数，而且一般是在主题这个级别上讨论 Lag 的，但实际上，Kafka 监控 Lag 的层级是在分区上的。如果要计算主题级别的，需要手动汇总所有主题分区的 Lag，将它们累加起来，合并成最终的 Lag 值。

对消费者而言，Lag 应该算是最最重要的监控指标了，它直接反映了一个消费者的运行情况。 一个正常工作的消费者，它的 Lag 值应该很小，甚至是接近于 0 的，这表示该消费者能够及时地消费生产者生产出来的消息，滞后程度很小。反之，如果一个消费者 Lag 值很大，通常就表明它无法跟上生产者的速度，最终 Lag 会越来越大，从而拖慢下游消息的处理速度。

由于消费者的速度无法匹及生产者的速度，极有可能导致它消费的数据已经不在操作系统的页缓存中了。这样的话，消费者就不得不从磁盘上读取它们，这就进一步拉大了与生产者的差距，进而出现马太效应，即那些 Lag 原本就很大的消费者会越来越慢，Lag 也会越来越大。

鉴于这些原因，在实际业务场景中必须时刻关注消费者的消费进度。一旦出现 Lag 逐步增加的趋势，一定要定位问题，及时处理，避免造成业务损失。

监控消费者进度有 3 种方法：

• 使用 Kafka 自带的命令行工具 kafka-consumer-groups 脚本。
• 使用 Kafka Java Consumer API 编程。
• 使用 Kafka 自带的 JMX 监控指标。

Kafka 自带命令

使用 Kafka 自带的命令行工具 bin/kafka-consumer-groups.sh(bat)。kafka-consumer-groups 脚本是 Kafka 提供的最直接的监控消费者消费进度的工具。

Kafka-consumer-groups 从表面上看，是操作和管理消费者组的。实际上，它也能够监控独立消费者（Standalone Consumer）的 Lag。

独立消费者就是没有使用消费者组机制的消费者程序。和消费者组相同的是，它们也要配置 group.id 参数值，但和消费者组调用 KafkaConsumer.subscribe() 不同的是，独立消费者调用 KafkaConsumer.assign() 方法直接消费指定分区。

使用 kafka-consumer-groups 脚本：

$ bin/kafka-consumer-groups.sh --bootstrap-server <Kafka broker连接信息> 
--describe --group <group名称>

Kafka 连接信息就是 < 主机名：端口 > 对，而 group 名称就是消费者程序中设置的 group.id 值。

CURRENT-OFFSET 值表示消费者组当前最新消费消息的位移值；LOG-END-OFFSET 列值表示每个分区当前最新生产的消息的位移值；LAG 值表示前两者的差值；HOST 表示消费者连接 Broker 的主机名。

有的时候，运行这个脚本可能会出现下面这种情况，如下图所示：

CONSUMER-ID、HOST 和 CLIENT-ID 列没有值！ 这是因为运行 kafka-consumer-groups 脚本时没有启动消费者程序。橙色的文字，表示当前消费者组没有任何 active 成员，即没有启动任何消费者实例。虽然这些列没有值，但 LAG 列依然是有效的，它依然能够正确地计算出此消费者组的 Lag 值。

除了上面的情形，还可能出现的一种情况是该命令压根不返回任何结果。这是因为使用的 Kafka 版本比较老，kafka-consumer-groups 脚本还不支持查询非 active 消费者组。

Kafka Java Consumer API

社区提供的 Java Consumer API 分别提供了查询当前分区最新消息位移和消费者组最新消费消息位移两组方法，使用它们就能计算出对应的 Lag。

public static Map<TopicPartition, Long> lagOf(String groupID, String bootstrapServers) throws TimeoutException {
        Properties props = new Properties();
        props.put(CommonClientConfigs.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
        try (AdminClient client = AdminClient.create(props)) {
        	// 获取给定消费者组的最新消费消息的位移
            ListConsumerGroupOffsetsResult result = client.listConsumerGroupOffsets(groupID); 
            try {
                Map<TopicPartition, OffsetAndMetadata> consumedOffsets = result.partitionsToOffsetAndMetadata().get(10, TimeUnit.SECONDS);
                // 禁止自动提交位移
                props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, false); 
                props.put(ConsumerConfig.GROUP_ID_CONFIG, groupID);
                props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
                props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
                try (final KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props)) {
                	// 获取订阅分区的最新消息位移
                    Map<TopicPartition, Long> endOffsets = consumer.endOffsets(consumedOffsets.keySet());
                    return endOffsets.entrySet().stream().collect(Collectors.toMap(entry -> entry.getKey(),
                            entry -> entry.getValue() - consumedOffsets.get(entry.getKey()).offset()));
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                // 处理中断异常
                return Collections.emptyMap();
            } catch (ExecutionException e) {
                // 处理ExecutionException
                return Collections.emptyMap();
            } catch (TimeoutException e) {
                throw new TimeoutException("Timed out when getting lag for consumer group " + groupID);
            }
        }
    }

这段代码只适用于 Kafka 2.0.0 及以上的版本，2.0.0 之前的版本中没 AdminClient.listConsumerGroupOffsets 方法。

Kafka JMX 监控指标

Kafka 消费者提供了一个名为 kafka.consumer:type=consumer-fetch-manager-metrics,client-id=“{client-id}”的 JMX 指标，其中有两组属性：records-lag-max 和 records-lead-min，它们分别表示此消费者在测试窗口时间内曾经达到的最大的 Lag 值和最小的 Lead 值。

Lead 值是指消费者最新消费消息的位移与分区当前第一条消息位移的差值。 Lag 越大，Lead 就越小，反之同理。

监控到 Lag 越来越大，可能只会有一个感受，那就是消费者程序变得越来越慢了，反应的只是追不上生产者程序了，有时候这也是能够接受的。但反过来，一旦监测到 Lead 越来越小，甚至是快接近于 0 了，这可能预示着消费者端要丢消息了。

Kafka 的消息是有留存时间设置的，默认是 1 周，也就是说 Kafka 默认删除 1 周前的数据。 倘若消费者程序足够慢，慢到它要消费的数据快被 Kafka 删除了，这时就必须立即处理，否则一定会出现消息被删除，从而导致消费者程序重新调整位移值的情形。这可能产生两个后果：一个是消费者从头消费一遍数据，另一个是消费者从最新的消息位移处开始消费，之前没来得及消费的消息全部被跳过了，从而造成丢消息的假象。

这两种情形都是不可忍受的，因此必须有一个 JMX 指标，清晰地表征这种情形，这就是引入 Lead 指标的原因。所以，Lag 值从 100 万增加到 200 万这件事情，远不如 Lead 值从 200 减少到 100 这件事来得重要。在实际生产环境中，一定要同时监控 Lag 值和 Lead 值。

Kafka 消费者还在分区级别提供了额外的 JMX 指标，用于单独监控分区级别的 Lag 和 Lead 值。 JMX 名称为：kafka.consumer:type=consumer-fetch-manager-metrics,partition=“{partition}”,topic=“{topic}”,client-id=“{client-id}”。