使用度量 spring_cloud_stream_binder_kafka_offset 进行 kafka 滞后

Question

我有一个应用程序长时间使用 kafka 消息而没有重新启动。 我还有一个破折号，通过属性“spring_cloud_stream_binder_kafka_offset”监控消费者滞后。

当我最近不得不重新启动它时，我意识到一些我一个多月没有发送消息的主题，开始在同一指标上报告一些“奇怪的值”。 我运行了以下命令来检查主题的滞后，然后我意识到这个主题具有“奇怪的值”，当前偏移列是空的“-”，但我确信这些消息是在过去处理的。

kafka-consumer-groups --bootstrap-server <server> --group group-test --describe --offsets --command-config 

GROUP	TOPIC	PARTITION	CURRENT-OFFSET	LOG-END-OFFSET	LAG
group-test	TEST	1	6468	6468	0
group-test	TEST	2	6396	6396	0
group-test	TEST1	0	-	88	-
group-test	TEST1	1	-	78	-

据我所知，我可能错了，有关当前偏移量的信息存储在 kafka 主题中。 该主题也将在 7 天内过期，因为没有消耗任何内容。

我的疑问是：由于当前偏移量已被“清理”，属性“spring_cloud_stream_binder_kafka_offset”不应该以某种方式反映这一点吗？因为这会导致对指标的一些误解，因为我没有这种滞后。

**** 更新 ****

稍微描述一下情况。

当 MS 再次启动，并且消费者的名称相同时，它不处理此消息，其理解为滞后。 我的意思是，MS 已启动并正在运行，具有相同的消费者名称，主题配置为被监控，并且没有任何消费。我在同一个 MS 中有其他主题正在正确处理。 额外的一点是，我使用融合云来检查这个滞后，那里的信息显示没有滞后，正如我所料。

我意识到，对于接收到另一条消息的某些特定分区，当前偏移量会使用 LOG-END-OFFSET 更新其值，并且一切正常。

我真的怀疑这个指标在这种情况下是如何工作的，它似乎失去了参考，表明一切都是滞后的。

Answer 1

见offset.retention.minutes。 https://kafka.apache.org/documentation/#brokerconfigs_offsets.retention.minutes

默认为 7 天，这意味着在最后一个消费者离开组后，偏移量将保留 7 天（使用最近的代理版本 - 如果我没记错的话，从 2.1 开始）。

当偏移量被删除时，就好像该组从未消耗过主题/分区中的任何内容，如果再次启动，它将接收主题/分区中的所有记录。