赞
踩
最近有点不走运,老是遇到基础服务的问题,还是记着点儿解决方法,以后再遇到快速解决吧,今天遇到这个问题倒不算紧急,但也能通过这个问题熟悉一下Kafka的配置。
正在开会的时候突然收到一连串的报警,赶忙看看是为啥
没过一会儿基础服务报警也来了
告警名称:Kafka-topic consume exception
识别号:xxxxx
状态:firing
开始时间:2023-08-09 19:28:05
当前时间:2023-08-09 19:28:05
Summary:Kafka Cluster: common-xxxx-xx Topic: { xxxxxxx-prod } Group:xxxxxxx-prod Status: STALL
Description: 诊断报告
Kafka 自身的异常状态的枚举:
这些异常状态可以在 Kafka 的客户端和服务端之间的交互中出现,通常会在日志或异常堆栈跟踪中得到体现
基于Kafka-topic_consume_exception策略,一般对于分区状态的依据kafka的报警状态枚举:
ok,Stall状态结合监控异常,我们发现应该是一批次提交的数量太多处理不完了,可以通过增加批次处理间隔或减少批次数量避免延迟消费
配置举例: max.poll.records = 20
,而 max.poll.interval.ms = 1000
,也就是说consumer一次最多拉取 20 条消息,两次拉取的最长时间间隔为 1 秒。也就是说消费者拉取的20条消息必须在1秒内处理完成,紧接着拉取下一批消息。否则,超过1秒后,kafka broker会认为该消费者处理太缓慢而将他踢出消费组,从而导致消费组rebalance。根据kafka机制,消费组rebalance过程中是不会消费消息的。所以看到三台机器轮流拉取消息,又轮流被踢出消费组,消费组循环进行rebalance,消费就堆积了
生产者的一些参数指标
消费者的一些参数指标
明确问题原因后,很好解决,把一批的最大拉取数量调小即可:spring.kafka.consumer.max-poll-records
,比默认值500多小一点,调整完配置上线后就解决了,消费延迟很快降低到0了
照例总结一下,虽然基础服务的一些中间件一般都由基础架构部门维护,但还是要对这些中间件的配置和使用要有所了解,这样出了问题才能快速定位问题、解决问题,避免影响线上稳定性
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。