监控
主流监控方式
JMXTrans + InfluxDB + Grafana
主机监控
- 机器负载：当前CPU工作量的度量，被定义为特定时间间隔内运行队列中的平均线程数，理论上接近0.7*cpu核数比较
- CPU使用率= (1 - 空闲态运行时间/总运行时间) * 100%，建议生产系统的 CPU 总使用率不要超过 70%
- 内存使用率
- 磁盘I/O使用率
- TCP连接数
- 打开文件数 ulimit -a查看
- 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
如无必要，请使用默认配置
