Kafka监控与调优-文末思维导图

监控

主流监控方式

JMXTrans + InfluxDB + Grafana

主机监控

1. 机器负载：当前CPU工作量的度量，被定义为特定时间间隔内运行队列中的平均线程数，理论上接近0.7*cpu核数比较
2. CPU使用率= (1 - 空闲态运行时间/总运行时间) * 100%，建议生产系统的 CPU 总使用率不要超过 70%
3. 内存使用率
4. 磁盘I/O使用率
5. TCP连接数
6. 打开文件数 ulimit -a查看
7. node使用情况

7.1 inode说明

Linux/Unix like OS 的文件系统中每个目录树中的节点，只包含了文件名和 Inode number Inode number 所找到对应于文件名的Inode 节点 Inode 节点中才真正记录了文件的大小/物理地址/所有者/访问权限/时间戳/被硬链接的次数等实际的 metadata IO 操作的时候，需要的资源除了磁盘空间以外，还要有剩余的 Inode

JVM监控

Full GC发生频率，时长，活跃对象大小

应用线程数

集群监控

查看Broker进程是否启动，端口号是否建立

查看Broker端关键日志

server.log 是Broker端日志

controller.log主题分区

state-change.log 主题分区状态变更日志

查看Broker端关键线程的运行状态

kafka-log-cleaner-thread是Log Compaction 线程

ReplicaFetcherThread 是副本拉取消息的线程

查看Broker端的关键JMX指标

BytesIn/BytesOut : Broker端每秒入站和出站的字节数。

NetworkProcessorAvgIdlePercent： I/O线程池平均空闲比例。建议30%以上

UnderReplicatedPartitions： 未充分备份的分区数。

ISRShrink/ISRExpand ISR收缩和扩容的频次指标。

ActiveControllerCount ： 处于激活状态的控制器数，count 1，如果大于1 就出现脑裂了

监控Kafka客户端

ping Broker ip看下RTT

Producer 部分

JMX 指标：request-latency，即消息生产请求的延时

Kafka-producer-network-thread 开头的线程是你要实时监控的。它是负责实际消息发送的线程

Consumer 部分JMX指标

records-lag 消费者最小消费消息的位移与分区当前最新消息位移的差值。

records-lead-min 消费者最小消费消息的位移与分区当前第一条消息位移的差值。

调优

调优效果，应用程序层>框架层>JVM层>操作系统层

操作系统层调优

挂载文件系统时禁掉atime更新

选择ext4，XFS文件系统

swap空间设置（如果可以设置一个小值，可以看到变化）

页缓存大小

JVM 层

堆设置 建议6-8G

GC收集器 建议G1

Broker端调优的关键

保存服务器端与客户端版本一致。

应用层调优

不要频繁地创建Producer和Consumer对象实例

用完及时关闭

合理利用多线程

调优参数列表

调优吞吐

Broker端

适当增加num.replica.fetchers参数，但不超过CPU核数（follower从leader拉取消息进行同步数据，是由fetcher线程处理)

Producer端

适当增加Batch.size参数值，比默认的16kB增加到512KB或1MB

适当增加linger.ms 比如为10-100 （不足Batch.size大小的最大等待时间）

设置compression.type=lz4或zstd<

设置acks=0或1 (0 发送不管成功与否，1 发送后leader仅接收成功了,-1 ISR副本集合都接受成功)

设置retries=0

如果多线程共享一个Producer实例，增加buffer.memory

Consumer端

采用多Consumer进程或多线程同时消费数据

增加fetch.min.bytes参数，比如设置为1KB

调优时延

Broker端

适当增加num.replica.fetchers值

Producer端

设置linger.ms=0

设置acks=1

不启用压缩，即设置compression.type=none

Consumer端

fetch.min.bytes=1

常见错误

主题删除失败

可能原因

副本所在的 Broker 宕机了；

待删除主题的部分分区，依然在执行迁移过程

解决方式

1.删除Zookeeper节点， /admin/delete_topics 删除主题对应的znode

2.手动删除改主题在磁盘上的分区目录

3.谨慎执行，Zookeper中执行 rmr /controller 触发controller重新选举，刷新Controller缓存

__consumer_offsets占用的磁盘过多

可能原因

Kafka-log-cleaner-thread 前缀的线程挂掉了

解决办法

只能重启相应的 Broker

特殊主题

__consumer_offsets

__transaction_state

如无必要，请使用默认配置