Kafka 监控架构设计

作者 : 开心源码 本文共3889个字,预计阅读时间需要10分钟 发布时间: 2022-05-12 共159人阅读

目前的Kafka监控产品有很多,比方Kafka Manager、 Kafka Monitor、KafkaOffsetMonitor、Kafka Web Console、Burrow等,都有各自的优缺点,就个人而言用的最多的还是Kafka Manager,不过这些并不是十分的完美。假如有条件,自己设置实现一套符合自身公司业务特色与发展的监控系统尤为重要。本文主要讲述笔者个人对Kafka监控架构的认知与想法。

Kafka监控主要分为数据采集、数据存储以及数据展现3个部分。

  • 数据采集主要从各种数据源采集监控数据并做少量必要的运算而后发送给数据存储板块进行存储。数据源可以是kafka-zk、kafka自身(消费__consumer_offset)、JMX(主要是通过JMX来监控kafka的指标,故kafka启动的时候需要指定JMX_PORT)、zabbix(或者者其余相似的工具,主要用来监控集群硬件指标)。
  • 数据存储是指将采集的原始数据经过肯定的预解决后进行相应的存储,方便数据清洗(这个步骤可以省略)和数据展现。数据存储可以采用Opentsdb之类的基于时间序列的数据库,方便做少量聚合计算。
  • 数据展现,顾名思义是将经过预解决的、存储的数据展现到监控页面上,提供丰富的UI给客户使用。当然数据展现板块也可以绕过数据存储板块直接向数据采集板块,亦或者者是数据源直接拉取数据。至于数据是从存储板块拉取还是更底层的源头拉取,要看能否需要历史时间段的值或者者是能否需要最新值。

经过上面的分析整个监控系统可以大致概括为以下的模型:

不过上面的模型架构只是针对单一集群以及单机版的Collector,假如涉及到多个集群,就需要考虑均衡负载以及HA等方面的因素。我们针对这个模型做进一步的改进,主要是针对数据采集板块的改进,如下图所示:

每台数据采集物理机上都部署一个主进程的服务,主进程负责根据需要创立Collector子进程,每个Collector子进程对应采集一个Kafka集群的监控数据。当某个集群需要被监控时,通过监控页面设置或者者其余途径将集群的少量重要信息(比方kafka的地址、kafka-zk的地址、zabbix的地址、jmx端口号等)存储起来并在zookeeper中/monitor/clusters/路径下创立对应的子节点(实节点),当然为了方面也可以将这些重要信息作为data直接存储在这个子节点中。各个主进程监听/monitor/clusters/下的子节点的变化,假如发现有新的节点加入,就以抢占的方式创立Collector,并在/monitor/pids/路径下创立对应集群的虚节点。

这里有几点需要说明:

  1. 各个主进程的“抢占”可以通过zookeeper自身的功能实现,通过在/monitor/pids/路径下创立相应的虚节点,假如创立成功则说明抢占成功,反之则失败。
  2. 在/monitor/pids/路径下创立虚节点是在Collector中创立的而不是在主进程中创立的,也就是说主进程监听到新节点的加入首先是创立Collector的实例,而后Collector的实例再创立对应的虚节点,假如创立成功则告知主进程创立成功,假如创立失败则返回失败。
  3. Collector之后再初始化少量进行资源采集的资源,比方与kafka-zk、kafka等建立连接。假如初始化成功则可以进行数据采集;假如失败则关闭自身,对应的虚节点的session也随之结束,也就意味着对应虚节点的自动删除。
  4. 主进程也要监听/monitor/pids/路径下的节点变化,一旦监听到节点添加则说明某个本来自身要抢占创立的已被其余主进程抢占。在2中所说的Collector创立虚节点成功与否告知主进程,其实这里也可以省去这一步,主进程可以监听/monitor/pids/路径的变化来感知能否创立成功。主进程一旦监听到/monitor/pids/路径下的节点减少,则首先判断这个节点能否在/monitor/clusters/下存在,假如不存在则不做解决,假如存在则启动抢占任务。
  5. 主进程和子进程可以通过ProcessBuilder来实现。
  6. 主进程自身可以抢占创立/monitor/pids/路径下的虚节点,而后监控Collector进程状态。假如Collector进程假死,而主进程无法直观感知,所以就将创立虚节点并保持session的工作就留给了Collector子进程。
  7. 主进程和子进程的关系也可以演变为进程和线程的对应关系,但是这样改变之后对各个集群的日志存盘以及问题的追踪会增加不必要的麻烦。

下面我们再来讨论下数据存储和数据展现这两者之间的关系。正常逻辑下,监控页面通过调取数据存储板块的api来获取数据并展现在页面上。试想下假如一个监控页面需要调取几十个指标,而后还要经过肯定的计算之后才展现到页面之上,那么这个页面的渲染速度必然会受到肯定的限制。

就拿指标UnderReplicatedPartitions来说,假如只能用一个指标来监控Kafka,那么非它莫属。UnderReplicatedPartitions表示集群中副本处于同步失败或者失效状态的分区数,即ISR<AR。这个指标的获取也很简单,通过JMX调取kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions。UnderReplicatedPartitions的值为0则大吉大利,假如大于0则需要很多步骤来检测异常起因,比方:检测能否只发生在一个topic上;检测能否只发生在一个broker上;假如不是前两种,极可能是集群起因,那么集群起因又可能是因为负载不均衡导致的等等(UnderReplicatedPartitions的异常评估可以参考笔者下一篇文章)。
UnderReplicatedPartitions背后要伴随着一堆的指标来评估异常的缘由,就以负载不均衡来说,还涉及到复杂的计算:一个Broker的负载涉及其所承载的partitions的个数、leaders的个数、网络读写速度、IO读写速度、CPU使用率等,要评判一个集群中能否有负责不均衡的情况出现,就需要将这些指标进行归一化解决,而后再做均方差,假如超过设定的阈值就可评判集群发生了负载不均衡的现象。假如监控页面从opentsdb中发送多个请求获取原始数据,而后再内部进行复杂的计算之后再程序在页面上,这个过程的耗时可以想象。更令人忧伤的是这么多的过程只是用来展现了一个指标,而一个页面的呈现可能要涉及到很多个指标。

有了问题我们就需要处理它,这里笔者引入了一个新的板块ComputeServer来进行数据预解决,而后将解决后的数据以HTTP RESTful API接口的方式提供给下游。下游的监控页面和存储板块只要要通过这个接口读取数据就可,无需过多的计算,从而提升了效率。新的架构模型如下图所示:

上图还引入了一个kafka的板块,这个主要是用来将多个Collector与ComputeServer解耦,假如多个悬而未定Collector与ComputeServer直接交互必然是一个浩大工程。Kafka板块可以针对每个集群创立对应的topic;亦或者者是创立一个单独的topic,而后划分多个partition,每个集群的ID或者者名称作为消息的Key来进行区分。后者不必强求每个集群对应到独立的partition中,ComputeServer在消费的时候可以获取Key来辨别集群。而消息的Value就是Collector采集的原始数据,这里的消息的大小有可能超过Kafka Broker的默认单条消息的大小1000012B,不过笔者不建议调高这个值以及对应人max.request.size和max.partition.fetch.bytes参数的大小。可以开启压缩或者者在Collector拆包以及在ComputeServer端解包的方式来进一步的处理消息过大的问题。还有一个就是这里的Kafka不建议开启日志压缩的功能,由于Kafka不仅是一个功能稍弱的消息中间件,同时也是一个功能弱化的时间序列数据库,Kafka本身可以根据时间范围来拉取对应的消息。在opentsdb不可靠的时候,完全可以使用kafka替代,只不过kafka出来的数据需要多做有些聚类运算。

在上图中的①和②可以加入数据清洗逻辑亦或者者是告警逻辑,将异常数据阻拦出来,传入其余的告警系统等来做进一步的解决。

上图中的ComputeServer的HA可以简单的通过LVS+Keepalived实现。

至此,一个包含数据采集+计算+存储+展现的监控架构已经聊完。后面会另有文章来细说下Kafka中的监控指标以及其背后的含义。


本文的重点是你有没有收获与成长,其他的都不重要,希望读者们能谨记这一点。同时我经过多年的收藏目前也算收集到了一套完整的学习资料,包括但不限于:分布式架构、高可扩展、高性能、高并发、Jvm性能调优、Spring,MyBatis,Nginx源码分析,Redis,ActiveMQ、、Mycat、Netty、Kafka、Mysql、Zookeeper、Tomcat、Docker、Dubbo、Nginx等多个知识点高级进阶干货,希望对想成为架构师的朋友有肯定的参考和帮助

喜欢这篇文章的朋友可以点个喜欢,也可以关注一下我的个人专题:Java成长之路

需要更详细架构师技能思维导图和以下资料的可以加一下技术交流分享群:“708 701 457”免费获取




说明
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » Kafka 监控架构设计

发表回复