您好,欢迎访问代理记账网站
  • 价格透明
  • 信息保密
  • 进度掌控
  • 售后无忧

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

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


分享:

低价透明

统一报价,无隐形消费

金牌服务

一对一专属顾问7*24小时金牌服务

信息保密

个人信息安全有保障

售后无忧

服务出问题客服经理全程跟进