引言在Kafka的消息流转链接里, 有着这样一种情况, 消费者的消费进度, 也就是Lag, 它是用来衡量系统健康度的关键指标。曾经在工作期间经历过宛如这般的一个场景, 实时订单处理系统产生了突发状况, 支付结果出现延迟现象。经过仔细排查以后发现, Kafka消费者的Lag值, 由原本正常的0, 一下子飙升到了50万条, 在分区里头贮存着数量繁多的订单消息。进一步深入分析表明, 是因为在消费者处理逻辑里添加了一个耗时颇长的数据库查询操作。这一操作使得单条消息处理时间, 从起初的10ms, 增长到了500ms, 最终造成Lag持续不断增长。所以在生产实践中消费进度监控是预防系统雪崩的第一道防线。什么是 LagLag消费者滞后量所指的是, 消费者当前消费的位移, 跟分区最新消息位移, 这两者之间存在的差值。举例来说, 有某分区最新消息位移呈1000, 而消费者当前把消费进行到了800, 这种情况下Lag就是为200。Lag的单位是消息数, 它的本质是生产者与消费者之间出现的“速度差”, 即Lag为0表明消费实时性处于最佳状态, Lag要是持续增大那就意味着消费能力存在不足。需留意的是, Lag归属分区层面的指标。主题的总体Lag得经由汇总全部分区的Lag予以计算, 进而得出结果, 而这亦是监控工具常常同时给出分区级以及主题级Lag视图的缘由所在。Lag过大的连锁反应Lag并非只是一个数字其背后隐藏着系统性能的连锁反应消费进度监控当属颇为关键的环节范畴, 处于Kafka运维之内必不可少且回避不掉, 而致使这般状况出现的因素是这些风险。方法一命令行工具——最直接的快速检查手段Kafka自身所带的kafka--.sh脚本, 是用于监控消费进度的那般如同“瑞士军刀”一样的工具, 它不需要进行额外的配置, 就能够快速地去查询Lag值, 这种情况适合于临时检查或者是那种简单的场景。基本用法与参数解析此脚本处在Kafka安装目录当中的bin文件夹里, 核心命令格式是这样的:$ bin/kafka-consumer-groups.sh \ --bootstrap-server \ --describe \ --group 消费者组名示例输出解读TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID test-topic 0 800 1000 200 consumer-1-xxx /192.168.1.100 consumer-1 test-topic 1 750 950 200 consumer-1-xxx /192.168.1.100 consumer-1特殊场景的输出说明 场景1无活跃消费者成员当消费者组之内没有启动任何一个实例的时候,输出之中的-ID列会呈现为空的状态,HOST列同样会呈现为空的状态,-ID列也会呈现为空的状态,然而LAG值却依旧是有效的:TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID test-topic 0 800 1000 200 - - -这是由于, Kafka把消费位移存储于主题里, 即便消费者处于离线状态, 位移数据仍旧是存在的。场景2旧版本Kafka的兼容性问题在Kafka 0.10.2.0以前的版本当中, kafka--.sh并不支持去查询并非活跃状态的消费者组的Lag, 有可能会返回空的结果。在这样的情形下, 就需要去升级版本或者改换成其他的方法像是Java API。独立消费者的Lag查询身为独立消费者并非运用消费者组模式, 当采用一种特定的方法时, 必须另外去指定分区参数。$ bin/kafka-consumer-groups.sh \ --bootstrap-server localhost:9092 \ --describe \ --group standalone-group \ --partition 0 \ --topic test-topic其中--和--topic用于定位独立消费者消费的具体分区。