189 8069 5689
目前的Kafka监控产品有很多，比如Kafka Manager、 Kafka Monitor、KafkaOffsetMonitor、Kafka Web Console、Burrow等，都有各自的优缺点，就个人而言用的最多的还是Kafka Manager，不过这些并不是十分的完美。如果有条件，自定义实现一套符合自身公司业务特色与发展的监控系统尤为重要。本文主要讲述笔者个人对Kafka监控架构的认知与想法。
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名注册、网络空间、营销软件、网站建设、张店网站维护、网站推广。
Kafka监控主要分为数据采集、数据存储以及数据展示3个部分。
经过上面的分析整个监控系统可以大致概括为以下的模型：
不过上面的模型架构只是针对单一集群以及单机版的Collector，如果涉及到多个集群，就需要考虑均衡负载以及HA等方面的因素。我们针对这个模型做进一步的改进，主要是针对数据采集模块的改进，如下图所示：
每台数据采集物理机上都部署一个主进程的服务，主进程负责根据需要创建Collector子进程，每个Collector子进程对应采集一个Kafka集群的监控数据。当某个集群需要被监控时，通过监控页面设置或者其他途径将集群的一些重要信息（比如kafka的地址、kafka-zk的地址、zabbix的地址、jmx端口号等）存储起来并在zookeeper中/monitor/clusters/路径下创建对应的子节点（实节点），当然为了方面也可以将这些重要信息作为data直接存储在这个子节点中。各个主进程监听/monitor/clusters/下的子节点的变化，如果发现有新的节点加入，就以抢占的方式创建Collector，并在/monitor/pids/路径下创建对应集群的虚节点。
这里有几点需要说明：
下面我们再来探讨下数据存储和数据展示这两者之间的关系。正常逻辑下，监控页面通过调取数据存储模块的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等多个知识点高级进阶干货，希望对想成为架构师的朋友有一定的参考和帮助
