Kafka-exporter监控消费速度与生产速度差异规则

max by(topic, consumergroup) (sum by(topic, partition, consumergroup) (increase(kafka_consumergroup_current_offset{}[2m])) / on(topic, partition) group_left() sum by(topic, partition) (increase(kafka_topic_partition_current_offset[2m])) <= 0.8 and sum by(topic, partition, consumergroup) (kafka_consumergroup_current_offset{}) - on(topic, partition) group_left() sum by(topic, partition) (kafka_topic_partition_current_offset{}) != 0 and sum by(topic, partition, consumergroup) (kafka_consumergroup_current_offset{}) - on(topic, partition) group_left() sum by(topic, partition) (kafka_topic_partition_current_offset{}) < -200)

这个PromQL查询是Prometheus的查询语言,用于监控和警报。它主要用于监控Kafka消费者组的消费进度。

1.增加的消费量:
java 复制代码
sum by(topic, partition, consumergroup) (increase(kafka_consumergroup_current_offset{}[2m]))

这部分计算了过去2分钟内,每个topic、partition和consumergroup组合的消费量的增加。

2. 总的生产量:
java 复制代码
sum by(topic, partition) (increase(kafka_topic_partition_current_offset[2m]))

这部分计算了过去2分钟内,每个topic和partition组合的生产量的增加。

3. 消费进度比例:
java 复制代码
... / on(topic, partition) group_left() ... <= 0.8

这部分计算消费者组在过去2分钟内的消费量与生产量的比例,并检查这个比例是否小于或等于0.8。也就是说,消费者组是否消费了不到80%的生产量。

  1. 消费者组的偏移量与总偏移量的差异:
java 复制代码
sum by(topic, partition, consumergroup) (kafka_consumergroup_current_offset{}) - on(topic, partition) group_left() sum by(topic, partition) (kafka_topic_partition_current_offset{})

这部分计算了每个消费者组对于每个topic和partition的当前偏移量与总的当前偏移量的差异。

5. 检查差异:
  • != 0: 确保消费者组的偏移量与总偏移量有差异。
  • < -200: 确保这个差异小于-200,意味着消费者组落后了至少200个消息。
  1. 最终结果:
    查询的主要目的是找出那些在过去2分钟内消费量与生产量的比例低于80%,并且与总偏移量有显著差异(差异小于-200)的消费者组。

综上所述,这个PromQL查询是为了检测Kafka消费者组的消费进度,确保它们没有落后太多,并且在积极地消费消息。如果查询返回结果,那么可能意味着某些消费者组存在问题或瓶颈,需要进一步的调查和干预。

Prometheus告警规则配置:

java 复制代码
- alert: KafkaConsumersGroupDelay
  expr: max(sum(increase(kafka_consumergroup_current_offset[2m]))by(topic,partition,consumergroup) / on(topic,partition) group_left sum(increase(kafka_topic_partition_current_offset[2m]))by(topic,partition) <= 0.8 and sum(kafka_consumergroup_current_offset) by (topic,partition,consumergroup) -on(topic,partition)group_left sum(kafka_topic_partition_current_offset) by (topic,partition)!=0 and sum(kafka_consumergroup_current_offset) by (topic,partition,consumergroup) -on(topic,partition)group_left sum(kafka_topic_partition_current_offset) by (topic,partition)<-200) by(topic,consumergroup)
  for: 2m
  labels:
  	severity: warning
  	team: kafka
  annotations:
  	summary: 持续2分钟Topic的消费速度小于生产速度的百分之80

优化思路 (文心一言)

减少重复计算:

查询中有一些重复的计算,例如sum by(topic, partition) (increase(kafka_topic_partition_current_offset2m))被多次使用。你可以通过使用Prometheus的with子句或子查询来避免重复计算。

使用子查询:

对于复杂的计算,你可以使用子查询来先计算一部分结果,然后在外部查询中使用这些结果。这可以使查询更加模块化,并可能提高性能。

明确时间范围:

在increase函数中指明时间范围(如2m),确保你只在需要的时间范围内聚合数据。这有助于减少Prometheus需要处理的数据量。

利用Recording Rules:

如果某些计算是经常需要的,你可以考虑使用Prometheus的Recording Rules功能。Recording Rules允许你预先计算并存储复杂的查询结果,这样你就可以直接在告警规则或其他查询中引用这些结果,而无需每次都重新计算。

简化逻辑表达式:

尝试简化逻辑表达式,以减少Prometheus在评估查询时需要执行的运算量。例如,避免不必要的括号和复杂的布尔逻辑。

使用更高效的运算符:

有些PromQL运算符可能比其他运算符更高效。例如,使用==或!=运算符可能比使用<或>更高效,因为它们可以直接利用索引进行查询。

限制返回的数据量:

如果可能的话,尽量限制查询返回的数据量。例如,如果你只对特定的topic或consumergroup感兴趣,可以在查询中明确指定它们。

sql 复制代码
# 子查询1: 计算每个topic, partition的生产量增加  
production_increase = sum by(topic, partition) (increase(kafka_topic_partition_current_offset[2m]))  
  
# 子查询2: 计算每个topic, partition, consumergroup的消费量增加  
consumption_increase = sum by(topic, partition, consumergroup) (increase(kafka_consumergroup_current_offset{}[2m]))  
  
# 主查询: 使用子查询结果进行计算和比较  
(  
  (consumption_increase / on(topic, partition) group_left(consumergroup) production_increase <= 0.8)  
  and  
  (consumption_increase - on(topic, partition) group_left(consumergroup) production_increase != 0)  
  and  
  (consumption_increase - on(topic, partition) group_left(consumergroup) production_increase < -200)  
)

这个优化示例是为了说明如何重构查询以提高可读性和可能的性能。在实际应用中,你应该根据你的具体需求和Prometheus服务器的性能特点来调整查询。

另外,Prometheus的性能优化是一个复杂的话题,除了查询优化外,还需要考虑数据存储、索引、硬件配置等多个方面。如果查询仍然很慢,可能需要进一步深入分析和优化。

相关推荐
范什么特西15 小时前
关于kafka
分布式·kafka
Wang's Blog3 天前
Go-Zero 项目开发19:基于 Kafka 的异步消息存储与转发实战
golang·kafka
Devin~Y3 天前
互联网大厂 Java 面试实录:Spring Boot、MyBatis、Redis、Kafka、Spring Security、RAG 与 MCP 全链路问答
java·redis·kafka·mybatis·spring security·spring mvc·sprint boot
java1234_小锋4 天前
【免费】基于Spark实时电商用户行为分析与预测(Java版本+可视化大屏+Kafka+SpringBoot+Vue3) 锋哥原创出品,必属精品
java·spark·kafka·实时电商用户行为分析与预测系统
AI人工智能+电脑小能手5 天前
【大白话说Java面试题 第194题】【08_Kafka篇】第10题:简述 Kafka 的 Rebalance 机制?
java·kafka·消费者组·rebalance·分布式消息队列
AI人工智能+电脑小能手6 天前
【大白话说Java面试题 第192题】【08_Kafka篇】第8题:死信队列是什么?延时队列是什么?
java·kafka·消息队列·死信队列·延时队列
AI人工智能+电脑小能手6 天前
【大白话说Java面试题 第190题】【08_Kafka篇】第6题:消息队列有什么作用?
java·kafka·消息队列·系统设计·分布式架构
风中凌乱7 天前
kafka新版本集群的安装与部署
分布式·kafka
abcy0712137 天前
kafka消息丢失与消息重复消费
kafka
富士康质检员张全蛋7 天前
Kafka的操作-消费的详情
分布式·kafka