为什么大网站的百度快照更新速度慢还排第一,如何做谷歌优化,一建论坛建工教育网,仿唯品会wordpress商城主题最近有点不走运#xff0c;老是遇到基础服务的问题#xff0c;还是记着点儿解决方法#xff0c;以后再遇到快速解决吧#xff0c;今天遇到这个问题倒不算紧急#xff0c;但也能通过这个问题熟悉一下Kafka的配置。
问题背景
正在开会的时候突然收到一连串的报警#xff…最近有点不走运老是遇到基础服务的问题还是记着点儿解决方法以后再遇到快速解决吧今天遇到这个问题倒不算紧急但也能通过这个问题熟悉一下Kafka的配置。
问题背景
正在开会的时候突然收到一连串的报警赶忙看看是为啥 没过一会儿基础服务报警也来了
告警名称Kafka-topic consume exception
识别号xxxxx
状态firing
开始时间2023-08-09 19:28:05
当前时间2023-08-09 19:28:05
SummaryKafka Cluster: common-xxxx-xx Topic: { xxxxxxx-prod } Group:xxxxxxx-prod Status: STALL
Description 诊断报告报警标识
Kafka 自身的异常状态的枚举
Leader Not Available (LEADER_NOT_AVAILABLE): 当尝试读取或写入一个分区时分区的 Leader 副本不可用。Replica Not Available (REPLICA_NOT_AVAILABLE): 当尝试读取或写入一个分区时分区的副本不可用。Request Timeout (REQUEST_TIMED_OUT): 请求在指定的时间内没有得到响应可能是因为网络延迟、负载过重等原因。Offset Out of Range (OFFSET_OUT_OF_RANGE): 尝试读取一个不存在的偏移量。Invalid Offset (INVALID_OFFSET): 提供了无效的偏移量。Unknown Topic or Partition (UNKNOWN_TOPIC_OR_PARTITION): 尝试访问不存在的主题或分区。Record Too Large (RECORD_TOO_LARGE): 尝试写入的记录大小超过了 broker 配置的最大记录大小。Not Enough Replicas (NOT_ENOUGH_REPLICAS): 写入操作无法满足分区的最小副本数配置。Message Size Too Large (MESSAGE_TOO_LARGE): 尝试写入的消息大小超过了 broker 配置的最大消息大小。Topic Authorization Failed (TOPIC_AUTHORIZATION_FAILED): 消费者或生产者没有足够的权限来访问指定的主题。Group Authorization Failed (GROUP_AUTHORIZATION_FAILED): 消费者群组没有足够的权限来访问指定的群组。Offset Metadata Too Large (OFFSET_METADATA_TOO_LARGE): 提供的偏移量元数据超过了 broker 配置的最大大小。Connection Error (CONNECTION_ERROR): 与 broker 的连接遇到问题可能是网络故障或 broker 宕机等原因。Unknown Error (UNKNOWN_ERROR): 未知的错误可能是由于 Kafka 内部问题引起的。
这些异常状态可以在 Kafka 的客户端和服务端之间的交互中出现通常会在日志或异常堆栈跟踪中得到体现
基于Kafka-topic_consume_exception策略一般对于分区状态的依据kafka的报警状态枚举
NotFound 状态这个consumer group 不存在OK 状态正常消费Warning 状态有一个或多个分区正在延迟当前在消费但是消费延迟越来越大Error 状态有一个或多个分区已经处于STOPSTALLRewind等几种状态之一Stop 状态消费者已经有一段时间没有提交offset了并且消费延迟非0Stall 状态消费者正在提交offset但是offset没有增加并且消费延迟非0Rewind 状态消费者提交了一个比之前还早的offset
okStall状态结合监控异常我们发现应该是一批次提交的数量太多处理不完了可以通过增加批次处理间隔或减少批次数量避免延迟消费
问题原因
配置举例 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了
总结一下
照例总结一下虽然基础服务的一些中间件一般都由基础架构部门维护但还是要对这些中间件的配置和使用要有所了解这样出了问题才能快速定位问题、解决问题避免影响线上稳定性
