kafka核心概念

Broker: 一个kafka服务端节点
cluseter: 集群,由多个Broker组合的集合
message:消息,也叫Record,kafka中信息传递的载体,对于kafka
Producer:生产者,向kafka发送消息的应用
Consumer:消费者,从kafka接收消息的应用
Consumer Group:消费者组,一组具有相同Group ID的Consumer,当一个topic被同一个group的多个consumer消费的时候,每条消息都只会投递到一个Consumer,实现消费的负载均衡,通过group,可以确保一个topic消息被并行消费,调高吞吐量
Topic:消费的主题,用于分类消息,在每个Broker上都可以创建多个topic
Replica:副本,每一个分区都有多个副本,当主分区故障的时候会选择一个备分区,成为leader,kafka中默认副本最大数量是10,副本的数量不能大于broker的数量
Partition:分区,一个有序不变的消息列队,用于存储消息,一个topic由一个或者多个分区组成,每个分区中的消息存储于一个或者多个broker上,在一个分区中消息的顺序就是producer发送消息的顺序。
offset: 分区中每条消息位置的信息,是一个单调递增且不变的值。
消费位点:分区被当前consumer消费了消息的最大位点
堆积量:当前分区下消息堆积的总量,即最大位点减去消费位点的值。堆积是一个关键指标,如果发现堆积量较大,则comsumer可能出现了阻塞,或者消费速度更不上生产的速度,此时需要分析consumer的运行状况,尽力提升消费速度。可以清除所有的堆积消息,从最大位点开始消费,或者按照时间点进行点重置。
rebalance:重平衡,消费组内某个消费者实例挂掉后,其他消费者实例自动重新分配订阅的主题分区的过程,它是kafka消费者端实现高可用的重要手段。
zookeeper: kafka集群依赖zookeeper来保存集群的元信息,以保证系统的可用性。

kafka版本

  • 0.1x 早期孵化版本
  • 1.x 优化streams API,增强可观测性和可调试性,支持java9,优化SASL
  • 2.X 性能提升,增强acl支持
  • 3.x 去掉zookeeper依赖,支持java17,不再支持java8,不再支持v0和v1消息,性能大幅提升
推荐使用2,x和3.x版本

Kafka Metric监控

Producer指标

生产者将消息推送到Broker Topic的应用,如果生产者失败,消费者将得不到新的消息。

Broker指标

因为所有的消息必须通过kafka broker才能被使用,所以对集群中Broker的监控是最核心。

Consumer指标

consumer是kafka消息终点

zookeeper指标

zookeeper是kafka的一个关键组件(v3.0)之前,zookeeper停机将使kafka停止运行。

kafka典型问题和排查

topic消息发送慢,并发性能低

某个或者某几个Topic的消息并发发送性能低,在指标上体现为producer的平均请求延迟大,平均生产吞吐量小
通常消息发送慢如下几种典型原因:
  • 网络带宽不足,导致IO等待
  • 消息未压缩,导致网络流量超负荷
  • 消息未批量发送,或者批量阈值配置不恰当,导致发送速率慢
  • topic分区数量不足,导致broker接收消息积压
  • broker磁盘性能低,导致磁盘同步慢
  • broker分区总量过多,导致碎片化,磁盘读写过载‘
排查
  • 确认producer的平均IO等待时间指标是否符合预期或者陡增,以便producer到broker之间的网络带宽是否满足业务的流量要求
  • 确认producer的平均压缩率指标,确保要压缩率符合预期
  • 确认producer的平均请求包大小是否过小,如果是的化,需要考虑增大producer发送消息的batchsize,同时调整linger.ms的阈值
  • 查看topic分区数量,分区较小的时候,考虑增加分区数,以水平扩展broker的并发接收消息容量
  • 确认borker磁盘IO使用率是否在安全范围之内,如果使用率已经较高,则考虑垂直或者水平扩容Broker,同时考虑增加topic分区数,提升topic并接收消息能力
  • 查看集群的总分区数和单个boker的分区数量,确保在规划的容量范围之内。

topic消息堆积

某个或者几个topic的消息堆积持续增加,在指标上直接体现为group消费延迟数量持续增加
常见的消息堆积有如下几种原因:
  • producer生产消息流量增大
  • consumer由于业务变化导致消费延迟增加
  • consumer数量不足
  • consumer数量频繁变化,导致group不断做再平衡rebalance
  • broker未收到consumer消息确认消息
排查
  • 确认producer的消息生产量指标是否明显增加
  • 确认consumer的消息流量指标是否明显下降
  • 通过kafka broker提供的命令,确认topic对应consumer数量与实际的consumer数量是否一致,如果不一致,说明某些consumer未正确连接到broker,需要排查consumer是否正常运行
  • 观察consumer的数量是否频繁变化而触发犯法再平衡
  • 由于网络或者其他原因,可能导致consumer与boker之间的连接不稳定,consumer能持续消费消息,但是broker却始终认为消息未确认,导致消费位点不变,此时可能需要确认consumer与broker之间的网络稳定性,甚至重启consumer
链接:https://blog.51cto.com/u_11555417/6177911
(版权归原作者所有,侵删)
继续阅读
阅读原文