Kafka常用JMX监控指标整理
调优
技术实战 |《Apache Kafka实战》作者胡夕：Apache Kafka监控与调优
千亿级数据量kafka集群性能调优实战总结
kafka生产者Producer参数设置及参数调优建议
参考价值很大
kafka生产者Producer参数设置及参数调优建议-商业环境实战系列
1.kafka某节点kafka数据磁盘被写满
现象：磁盘被写满后kafk挂掉无法启动。
解决办法：如果有过期日志删除过去日志，再重启。如果没有过期日志，缩短此节点日志保存时间，删除不在保留时间内的日志。
2.客户端连接超时
1.根据异常内容定位客户端源码，分析客户端代码
2.抓包分析
kafka 通过tcp/ip协议建立链接，在linux使用tcpdump命令抓包然后用抓包工具(Wireshark）在windos上分析抓到的数据。
3.close wait过多导致broker网络不通，从而Kafka产生问题
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
4.kafka 坏盘导致leader不存在问题分析
文档：kafka 坏盘导致leader不存在问题分析…
链接：http://note.youdao.com/noteshare?id=bdc2978c3b5148059f3067201085c8e4&sub=1D34AD65F05E40A4AABA5C2C75B44633
5.动态增加副本
Kafka动态增加Topic的副本
前提：acks=all，副本数=3
保证数据可靠性
生产者设置
acks=all
retries=2147483647
delivery.timeout.ms=2147483647
集群设定
unclean.leader.election.enable=false
default.replication.factor=3 # 默认创建topic的副本数
min.insync.replicas=2 #最小可是使用的isr数
offsets.topic.replication.factor=3 #内部topic __consumer_offsets 的副本数（默认50个分区，3个副本）
transaction.state.log.replication.factor=3
transaction.state.log.min.isr>=2
如果要提高数据的可靠性，在设置request.required.acks=-1的同时，也要min.insync.replicas这个参数(可以在broker或者topic层面进行设置)的配合，这样才能发挥最大的功效。min.insync.replicas这个参数设定ISR中的最小副本数是多少，默认值为1，当且仅当request.required.acks参数设置为-1时，此参数才生效。如果ISR中的副本数少于min.insync.replicas配置的数量时，客户端会返回异常：org.apache.kafka.common.errors.NotEnoughReplicasExceptoin: Messages are rejected since there are fewer in-sync replicas than required。
消费者设置
enable.auto.commit=false
6.kafka的broker id改变导致的问题
如果你想改kafka的broker id，比如第一遍写错了，应该遵循两个步骤：
- 改server.prorperties文件配置；
broker.id=121
log.dirs=/root/kafka-acl/kafka/data
- 改meta.properties，默认情况下，应该在/tmp/kafka-logs目录下；
同时需注意数据存在多个目录时，需要修改多个目录的meta.propertie。
vi /root/kafka-acl/kafka/data/meta.propertie
#Tue Dec 29 14:36:11 CST 2020
version=0
broker.id=121
7.kafka producer写入超时
现象：
kafka producer一开始写入正常，慢慢的会大量超时异常，偶尔正常写入；在callback函数打印异常信息为
org.apache.kafka.common.errors.TimeoutException: Expiring 2 record(s) for testTopic-0 due to 64534 ms has passed since batch creation plus linger time
原因：
producer send方法的callback函数执行缓慢导致；
producer往broker发送数据时是串行的，只有上次batch全部写入broker，并且全部callback函数执行完毕后，才会继续下一次发送。如果上一次发送全部callback函数执行时间超过了request.timeout.ms(30s)，就会导致后续batch的message发送时间大于创建时间30s以上，然后被producer丢弃并抛出异常；
方法：
1.加大request.timeout.ms值；
2.调整callback，使得batch的callback执行时间在request.timeout.ms之内；
8.ISR抖动
现象:
无法消费kafka。
中往kafka写消息报错
查看集群：
ISR缺失严重
bin/kafka-topics.sh --zookeeper hdp1:2181/kafka --describe --under-replicated-partitions
2.0版本
bin/kafka-run-class.sh kafka.tools.JmxTool --jmx-url service:jmx:rmi:///jndi/rmi://hdp1:9999/jmxrmi --object-name kafka.server:type=ReplicaManager,name=IsrShrinksPerSec
调整副本同步leader数据的线程数
num.replica.fetchers #leader中进行复制的线程数，增大这个数值会增加relipca的IO
默认是单线程，当时增加到2或者4…
由于数据量比较庞大，且此broker正在重启，kafka server.log报错如下,属于正常
9.消费异常
现象：
在生产端割接后，数据量增大20%，消费速度直降，consumer.group脚本查询不出，无法得知lag等偏移量信息
jmx中指标中kafka空闲度低于30%，基本都在10%以下，更甚2%,1%，，证明kafka内部非常繁忙，调大JVM参数至40G依旧不见好转
排查集群：
网络空闲度：
查看平均网络处理空闲时间低于0.3
0.10版本
bin/kafka-run-class.sh kafka.tools.JmxTool --jmx-url service:jmx:rmi:///jndi/rmi://hdp1:9999/jmxrmi --object kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent
2.0版本
bin/kafka-run-class.sh kafka.tools.JmxTool --jmx-url service:jmx:rmi:///jndi/rmi://hdp1:9999/jmxrmi --object-name kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent
磁盘IO空闲度
2.0版本
bin/kafka-run-class.sh kafka.tools.JmxTool --jmx-url service:jmx:rmi:///jndi/rmi://hdp1:9999/jmxrmi --object-name kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent
调整参数：
num.network.threads：(网络i/o)
server用来处理网络请求的网络线程数目。增大能够增加处理网络io请求，但不读写具体数据，基本没有io等待。过大，会带来线程切换的开销
用于接收并处理网络请求的线程数，默认为3。其内部实现是采用Selector模型。启动一个线程作为Acceptor来负责建立连接，再配合启动num.network.threads个线程来轮流负责从Sockets里读取请求，一般无需改动，除非上下游并发请求量过大。
num.io.threads：(文件i/o)
server用来处理请求的磁盘文件I/O线程的数目。这个线程数目至少要等于硬盘的个数。过大，会带来线程切换的开销
经过参数的加大，发现生产端与消费端都可以正常运行了
10.producer发送失败
producer参数 buffer.memory 设置（吞吐量）
该参数用于指定Producer端用于缓存消息的缓冲区大小，单位为字节，默认值为：33554432合计为32M。kafka采用的是异步发送的消息架构，prducer启动时会首先创建一块内存缓冲区用于保存待发送的消息，然后由一个专属线程负责从缓冲区读取消息进行真正的发送。
商业环境推荐：
消息持续发送过程中，当缓冲区被填满后，producer立即进入阻塞状态直到空闲内存被释放出来，这段时间不能超过max.blocks.ms设置的值，一旦超过，producer则会抛出TimeoutException 异常，因为Producer是线程安全的，若一直报TimeoutException，需要考虑调高buffer.memory 了。
用户在使用多个线程共享kafka producer时，很容易把 buffer.memory 打满。