Kafka 监控
Broker JVM 进程默认用 G1 的 GC 算法,当 cleanup 结束后,堆上活跃对象大小从 827MB 缩减成 645MB。load average 的过去 1 分钟、过去 5 分钟、过去 15 分钟的 Load 平均值:4.85、2.76、1.26。例子 : Broker 进程进行 Full GC 后,堆上存活的活跃对象大小是 700MB。客户端与 Broker 的网络往返时延(Ro
·
Kafka 监控
主机监控
主机监控 : 监控 Kafka 集群 Broker 所在的节点机器的性能
主机监控指标 :
- 机器负载 (Load) , CPU 使用率
- 内存使用率 (空闲内存 , 已使用内存 (Used Memory) )
- 磁盘 I/O 使用率 (读使用率/ 写使用率) , 网络 I/O 使用率
- TCP 连接数 , 打开文件数 , inode 使用情况
top
load average 的过去 1 分钟、过去 5 分钟、过去 15 分钟的 Load 平均值:4.85、2.76、1.26
- 主机共 4 CPU 核,但 Load 有 4.85 : 有进程暂时抢不到任何 CPU 资源
CPU 使用率 (%CPU) :
- 进程使用的所有 CPU 的平均使用率
- 主机共 4 CPU 核 ,
%CPU
= 102.3 , 平均每 CPU 的使用率 = 25%
JVM 监控
例子 : Broker 进程进行 Full GC 后,堆上存活的活跃对象大小是 700MB
- 将老年代堆大小设置 = 该数值的 1.5 倍或 2 倍 = 1.4GB
JVM 进程指标监控:
- Full GC 发生频率和时长 : 评估 Full GC 对 Broker 进程的影响
- 活跃对象大小 : 设堆大小的依据,能调优 JVM 各个代的堆大小
- 应用线程总数 : 了解 Broker 进程对 CPU 的使用情况
2019-07-30T09:13:03.809+0800: 552.982: [GC cleanup 827M->645M(1024M), 0.0019078 secs]
Broker JVM 进程默认用 G1 的 GC 算法,当 cleanup 结束后,堆上活跃对象大小从 827MB 缩减成 645MB
- G1 的 Full GC 是单线程执行的,速度非常慢
- 一旦 Broker 进程频繁 Full GC,开启
-XX:+PrintAdaptiveSizePolicy
查看 Full GC 原因
集群监控
查看 Broker 进程是否启动,端口是否建立 :
- Docker 启动 Kafka 时,容器虽然成功启动了,但网络设置有误,会出现进程已经启动但端口未成功建立监听
查看 Broker 日志 :
- 服务器日志 : server.log
- 控制器日志 : controller.log
- 主题分区状态变更日志 : state-change.log
查看 Broker 线程的运行状态 :
kafka-log-cleaner-thread
:Log Compaction
日志 Compaction : 一旦挂了,所有 Compaction 都会中断ReplicaFetcherThread
: 副本拉取消息的线程 (Follower 副本向 Leader 副本拉取消息) : 一旦挂了,对应的 Follower 副本不会从 Leader 副本拉取消息,Follower 副本的 Lag 会越来越大
Broker JMX 指标 :
BytesIn
/BytesOut
: Broker 每秒入站和出站字节数。保证不要接近网络带宽,网卡打满 : 容易出现丢包NetworkProcessorAvgIdlePercent
: 网络线程池线程平均的空闲比例。确保该值 > 30%。当 < 30% : 网络线程池繁忙,要增加网络线程数或 负载转移,减轻 Broker 负载RequestHandlerAvgIdlePercent
: I/O 线程池线程平均的空闲比例。该值 < 30%,要调整 I/O 线程池数,减轻 Broker 负载UnderReplicatedPartitions
:未充分备份的分区数。该分区可能有数据丢失ISRShrink
/ISRExpand
:ISR 收缩和扩容的频次。当 ISR 中副本频繁进出,要判断副本频繁进出 ISR 的原因ActiveControllerCount
:激活状态的控制器数。正常 : Controller 所在 Broker 是 1,其他 Broker 是 0。当多台 Broker 是 1 :集群可能有脑裂 :排查网络连通性
监控 Kafka 客户端
客户端与 Broker 的网络往返时延(Round-Trip Time,RTT)
- 在客户端 ping 下 Broker ,查看 RTT
生产者 :
kafka-producer-network-thread
:负责实际消息发送的线程 。它挂了,Producer 将无法正常工作,但 Producer 进程不会挂request-latency
: 消息生产请求的延时 : Producer 程序的 TPS
消费者 :
kafka-coordinator-heartbeat-thread
: 心跳线程 , 关系到 Rebalancerecords-lag
,records-lead
: Consumer 消费进度join rate
,sync rate
: Rebalance 的频繁程度
更多推荐
已为社区贡献5条内容
所有评论(0)