Kafka常遇问题及其JMX监控关键指标详解
最编程
2024-02-07 12:10:51
...
Error processing append operation on partition | 一个类型告警 | 配置了正则过滤了下面的一二情况,如果仍然告警需要留意,通知相关人员。 |
org.apache.kafka.common.errors.UnknownProducerIdException: Found no record of producerId | 幂等性问题 | 有一些一天可能只发送一条消息的,如果partition数超过7,比如设成8,设成7天的保留时间就有可能出现上面的问题,像这种消息的保留时间可以设成一个月甚至更长都没问题 |
org.apache.kafka.common.errors.OutOfOrderSequenceException: Out of order sequence number for producerId | 幂等性问题 | 有一些一天可能只发送一条消息的,如果partition数超过7,比如设成8,设成7天的保留时间就有可能出现上面的问题,像这种消息的保留时间可以设成一个月甚至更长都没问题 |
org.apache.kafka.common.errors.NotEnoughReplicas: Number of insync replicas for partition | partition在ISR中的副本,少于配置文件中要求的min.insync.replica=$ | 配置副本同步成功最小数告警,发生此告警需要留意联系一下相关人员。 |
Broker may not be available | kafka broker 不可用监控 | 需要留意集群健康情况,联系一下相关人员确认。 |
WARN Attempting to send response via channel for which there is no open connection | 5595这个报错的issue在1.0.0版本也就是我们在用的版本已经修复了 | 不影响业务,可调源码需要留意连接zk过多情况 |
NotLeaderForPartionException:This server is not the leader for that topic-partition | 发生了leader切换就有可能报NotLeaderForPartionException | broker切换是这样的,因为partiton是均衡分布在各个broker的,所以不管是预期的还是非预期的broker切换,一般都会发生一些topic partition的leader切换,如果此时在完成切换前有读写请求,就会发现短时间的报错现象,切换完就恢复了 |
WARN Client session timed out, have not heard from server in 4002ms for sessionid 0x100b72efc7c0006 (org.apache.zookeeper.ClientCnxn) | 客户端连接出现会话超时情况 | zk会话超时出现的原因可能有多方面,比如网络问题如流量风暴,broker本身性能如full gc影响,zk性能原因等 |
INFO re-registering broker info in ZK for broker 0 (kafka.server.KafkaHealthcheck$SessionExpireListener) | 发生了broker重连的情况 | zk会话超时出现的原因可能有多方面,比如网络问题如流量风暴,broker本身性能如full gc影响,zk性能原因等 |
Shrinking ISR from 2,0,1 to 0 | 发生了ISR伸缩 | isr伸缩的原因一般有两种,一种是真的有broker出现了问题下线了,会导致isr缩容,还有一种是复制原因,从节点来不及复制副本数据,这个有可能是发送的数据太大太多 |
This error can be ignored if the cluster is starting up and not all brokers are up yet | 集群可能在重启中 | 集群重启时可忽略 |
UnknownTopicOrPartitionException: This server does not host this topic-partition | 搜查可能bug | https://issues.apache.org/jira/browse/KAFKA-6221 从issue讨论来看是偶发的,且一段时间会恢复,不会影响集群的,可以忽略 |
上一篇: 如何使用Prometheus监控Tomcat (通过JMX)
下一篇: 深入浅出-Zabbix 5.0最新稳定版解析8:玩转Zabbix监控Java应用实战(包括JMX与Zabbix-Java-Gateway实操、详析Java项目监控流程及Tomcat部署启动指南)
推荐阅读
-
玩转Java底层:JMX详解 - jconsole与自定义MBean监控工具的实际应用与区别" 在日常JVM调优中,我们熟知的jconsole工具通过JMX包装的bean以图形化形式展示管理数据,而像jstat和jmap这类内建监控工具则由JVM直接支持。本文将以jconsole为例,深入讲解其实质——基于JMX的MBean功能,包括可视化界面上的bean属性查看和操作调用。 MBeans在jconsole中的体现是那些可观察的组件属性和方法,如上图所示,通过名为"Verbose"的属性能看到其值为false,同时还能直接操作该bean的方法,例如"closeJerryMBean"。 尽管jconsole给我们提供了直观的可视化界面,但请注意,这里的MBean并非固定不变,开发者可根据JMX提供的接口将自己的自定义bean展示到jconsole。以下步骤展示了如何创建并注册一个名为"StudyJavaMBean"的自定义MBean: 1. 首先定义接口`StudyJavaMBean`,接口需遵循MBean规范,即后缀为"MBean"且包含getter方法代表属性,如`getApplicationName`,和无返回值的setter方法代表操作,如`closeJerryMBean`。 ```java public interface StudyJavaMBean { String getApplicationName(); void closeJerryMBean(); } ``` 2. 编写接口的实现类`StudyJavaMBeanImpl`,实现接口中的方法: ```java public class StudyJavaMBeanImpl implements StudyJavaMBean { @Override public String getApplicationName() { return "每天学Java"; } @Override public void closeJerryMBean() { System.out.println("关闭Jerry应用"); } } ``` 3. 在代码中注册自定义MBean,涉及的关键步骤包括: - 获取平台MBeanServer - 定义ObjectName,指定唯一的MBean标识符 - 注册MBean到服务器 - 启动RMI连接器服务,以便jconsole能够访问 ```java public void registerMBean() throws Exception { // ... 具体实现省略 ... } ``` 实际运行注册后的MBean,您将在jconsole中发现并查看自定义bean的属性和调用相关方法。然而,这种方式相较于传统的属性/日志查看和HTTP接口,实用性相对有限,可能存在潜在的安全风险。但不可否认的是,JMX及其MBean机制对于获取操作系统信息、内存状态等关键性能指标仍然具有重要价值。例如: 1. **获取操作系统信息**:通过JMX MBean,可以直接获取到诸如CPU使用率、操作系统版本等系统级信息,这对于资源管理和优化工作具有显著帮助。
-
Kafka常遇问题及其JMX监控关键指标详解