Kafka 核心技术与实战
胡夕
Apache Kafka Committer,老虎证券技术总监
52815 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 47 讲
开篇词 (1讲)
结束语 (1讲)
Kafka 核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册

36 | 你应该怎么监控Kafka?

应用线程总数
活跃对象大小
Full GC发生频率和时长
inode使用情况
打开文件数
TCP连接数
网络I/O使用率
磁盘I/O使用率
内存使用率
CPU使用率
机器负载
监控Kafka客户端
查看Broker端的关键JMX指标
查看Broker端关键线程的运行状态
查看Broker端关键日志
查看Broker进程是否启动,端口是否建立
监控指标
监控Broker进程的JVM
主机监控指标
监控Kafka集群Broker所在的节点机器的性能
讨论监控Kafka的方法和工具
分享监控Kafka方面的心得和运维技巧
集群监控
JVM监控
主机监控
无论微信公众号还是Kafka QQ群,大家问得最多的问题都是Kafka的监控
监控Kafka历来都是老大难问题
开放讨论
监控维度
胡夕
监控Kafka

该思维导图由 AI 生成,仅供参考

你好,我是胡夕。今天我要和你分享的主题是:如何监控 Kafka。
监控 Kafka,历来都是个老大难的问题。无论是在我维护的微信公众号,还是 Kafka QQ 群里面,大家问得最多的问题,一定是 Kafka 的监控。大家提问的内容看似五花八门,但真正想了解的,其实都是监控这点事,也就是我应该监控什么,怎么监控。那么今天,我们就来详细聊聊这件事。
我个人认为,和头疼医头、脚疼医脚的问题类似,在监控 Kafka 时,如果我们只监控 Broker 的话,就难免以偏概全。单个 Broker 启动的进程虽然属于 Kafka 应用,但它也是一个普通的 Java 进程,更是一个操作系统进程。因此,我觉得有必要从 Kafka 主机、JVM 和 Kafka 集群本身这三个维度进行监控。

主机监控

主机级别的监控,往往是揭示线上问题的第一步。所谓主机监控,指的是监控 Kafka 集群 Broker 所在的节点机器的性能。通常来说,一台主机上运行着各种各样的应用进程,这些进程共同使用主机上的所有硬件资源,比如 CPU、内存或磁盘等。
常见的主机监控指标包括但不限于以下几种:
机器负载(Load)
CPU 使用率
内存使用率,包括空闲内存(Free Memory)和已使用内存(Used Memory)
磁盘 I/O 使用率,包括读使用率和写使用率
网络 I/O 使用率
TCP 连接数
打开文件数
inode 使用情况
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

Kafka监控一直是技术人员关注的难题。本文从主机监控和JVM监控两个维度详细介绍了如何监控Kafka。在主机监控方面,作者强调了监控Kafka集群Broker所在节点机器的性能,包括机器负载、CPU使用率、内存使用率、磁盘I/O使用率等指标。而在JVM监控方面,文章提到了全面了解Broker进程的重要性,包括堆大小、GC回收器、Full GC发生频率和时长、活跃对象大小等指标。此外,还介绍了如何通过GC日志来查看监控指标。文章还给出了监控Kafka集群的几个方法,包括查看Broker进程是否启动、查看关键日志和线程的运行状态,以及监控关键JMX指标。作者建议从主机和JVM的维度进行监控,并列举了一些重要的Kafka JMX指标。总之,本文通过实例和技术细节,为读者提供了全面了解Kafka监控的指导,对于需要监控Kafka的技术人员具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Kafka 核心技术与实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(25)

  • 最新
  • 精选
  • 我已经设置了昵称
    要怎么看到JMX指标呢,能否讲下

    作者回复: 无论是Broker端还是Clients端启动前要先设置JMX_PORT,然后使用任何能够连接JMX MBean Server的工具或框架连接(如JConsole)就能看到了

    2019-09-04
    15
  • r
    老师总结的真好。我有个疑问,没找到相关资料做支撑。就是一套kafka集群,最多能容纳多少个topic-partition,这个是集群规模有关吗,

    作者回复: 根据社区的报告,Kafka 1.1.0之后可以支持单集群20万个分区。和集群规模不能说没有关系,但其实和集群总的物理硬件资源有很大关系。

    2019-08-24
    8
  • ykkk88
    有什么好的开源的监控工具么

    作者回复: 我觉得Kafka Manager就挺不错的

    2019-08-25
    2
    5
  • 快跑
    请教老师一下 从监控上能看到读取kafka数据是从页缓存还是磁盘么,对应的指标有哪些?

    作者回复: 无法看出。不过你可以监控一下broker的磁盘IO,对于那些同步的consumer而言,磁盘IO读应该很少才对

    2020-03-14
    3
  • frenco
    老师好, 请教个问题: 按您之前有个推荐的配置kafka内存的说法,一般堆内存配置6G就好了。 那新生代和老年代默认2:1 分配。 如果只需要6G的内存, 我们生产的机器一般都是64G以上内存, 那机器是不是有很大浪费呢。

    作者回复: 那就单台多broker吧,不过网卡最好万兆

    2019-11-08
    2
    3
  • 谦寻
    请教下老师,我们最近遇到一个监控问题,监控各个topic的消息堆积,发现如果业务方由于服务下线,不使用某个consume group了,结果这个group的消息堆积会一直增加,运维就会收到监控告警,但是运维并不好判断哪个group已经不使用了,这个能有什么自动化的手段吗

    作者回复: 如果group不使用了,它的状态就是nonactive了,一段时间之后Kafka会自动删除的它数据。如果判断状态的话,新一点版本的Kafka可以使用kafka-consumer-groups --describe --group *** 来查看group状态。

    2019-08-29
    2
    3
  • wxr
    怎样比较好的监控消费延时呢

    作者回复: 这个取决于你对消费延时的定义。从Kafka的角度,当poll方法返回后,消息已经算是被消费了,但通常我们获取到消息后还要对消息进行处理,如果你认为处理完成后才算是消费就要加上这部分的时间,但处理逻辑、工具、方法都不尽相同,因此你需要自己来监控消息处理的总时间。

    2019-08-24
    6
    3
  • 风中花
    老师你的公众号怎么找到呢

    作者回复: 大数据Kafka技术分享

    2019-11-30
    2
  • Geek_72a3d3
    “同时,Load 值一直在增加,也说明这台主机上的负载越来越大。” 老师,您好,Load值好像是越来越小。??

    作者回复: 3个值的排序是过去1分钟,5分钟和15分钟,因此表明load越来越大

    2019-09-17
    4
    2
  • 外星人
    你好,单个topic可以支撑的最多partition个数多少啊?我们生产上有个topic超级大,占了整个集群的一半以上的流量,这种情况是需要拆分吗?

    作者回复: 如果性能okay而仅仅是你觉得不太好,那么我认为先不用拆分。单个topic最多能有多少partition没有定数,主要还是看底层物理资源。当然分区数过多,使得broker上平均分区数增加的确会降低Kafka的TPS。

    2019-08-24
    2
收起评论
显示
设置
留言
25
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部