Kafka的灵魂伴侣Logi-KafkaManger集群介入及相关概念

今天给大家介绍一下，由滴滴开源的kafka的管理运维平台——Kafka的灵魂伴侣Logi-KafkaManger。

经过博主一番体验下来，感觉相比之前用过的所有kafka管理平台都要出色，所以在此开设一个专栏给大家介绍。

对于这款kafka的灵魂伴侣Logi-KafkaManger，大家完全可以顺着我的专栏文章顺序一篇一篇的阅读，看完全部专栏保准你对整个平台的应用炉火纯青 😋 ~ 

如果有疑问可以在评论区留言或者看本文最下方加官方小助手微信进官方群提问！

文章中如有错误❎ ~ 烦请提醒博主纠正✅ ,谢谢~~~~

有兴趣也可以一起参与该项目的开源 Biu~Biu~Biu~~ 

在阅读此文前，您可以先按照Github Logi-KafkaManager文档中介绍的进行部署，自己搭建一下项目。

那在运维管理人员搭建好了平台之后，接下来要做什么呢？

 

1、接入集群

首先是接入现有kafka集群

a.接入集群

b.参数描述

参数	描述
数据中心	默认国内，这个也只是一个划分数据的维度,这个应该是滴滴内部有多个数据中心的缘故。
集群类型	无效,后续会去掉
安全协议	TODO
JMX认证	JMX的认证鉴权, 如果kafka没有开认证的话就不需要填写。

注：

JMX端口记得要开起来,不然很多数据会没有 

附：

JMX-连接失败问题解决

解决方法 —— 认证的JMX

以上问题请点击github Logi-KafkaManager/docs/dev_guide/connect_jmx_failed.md查看

Github地址：https://z.didi.cn/4newP

接入成功之后可以看见接入的物理集群，列表中展示了一些基本信息 ，可能会有一分钟的延迟。

 

2、基本信息展示

点进刚刚接入的集群可以看到有很多集群信息的展示，这些我们放在后面去讲，我们现在着重讲解一下两个模块 1、Region信息  2、逻辑集群信息

在这之前，我们可以先去了解一下官方的相关概念——滴滴Logi-KafkaManager主要概念讲解。（点击蓝字即可查看）

面对大规模集群、业务场景复杂的情况，引入Region、逻辑集群的概念，这是滴滴在长期实践沉淀下来的经验。

Region: 划分部分Broker作为一个 Region，用Region作为定义资源划分的单位，提高扩展性和隔离性。这样即使部分Topic出现异常也不会影响大面积的Broker。比如下方右图中，将部分Broker划分为一个Region，当某个Topic发送异常时，影响范围就会被限制在它所属的Region里。

 

 

逻辑集群: 将部分Region划分为逻辑集群，便于对大规模集群按照业务、保障能力等进行划分。

 

三、创建Region和逻辑集群

下面我们来举几个显示场景的例子，来说明Region和逻辑集群的创建：

A. 小规模集群Region和逻辑集群划分

许多公司一般可能也就只部署了一套kafka的物理集群，一套kafka集群可能也就3~5个broker，所有业务公用一套集群。对于这样的应用场景来说，也就没有必要做那么复杂的Region 和逻辑集群划分。我们可以直接让 Region = 逻辑集群 = 物理集群。

a.创建Region

PS: 这里的状态栏中，下拉还有一个“磁盘已满” 的选项，这里先忽略它的作用，直接填写“正常”即可。

 

b.创建逻辑集群(逻辑集群需要先有配置Region)

逻辑集群标识：作为逻辑集群的唯一标识;

RegionIdList：选择Region列表，比如刚刚我们创建好的common_region 会出现在下拉框中，我们就可以选择这个Region；

 

c.集群类型

独享集群: 在物理集群中为某一应用单独划分部分Region作为独享集群。只能该应用使用。

独立集群: 为某一应用部署单独的物理集群。只能该应用使用。

共享集群: 划分部分Region作为共享集群。所有应用皆可使用。

对于小集群来说，我们选择共享集群就可以， 因为其他模式的话是需要绑定到具体应用的。

 

B.中、大规模集群Region和逻辑集群划分

我们假设这样一个场景：某个企业 kafka 有N个物理集群，其中有一个共享的物理集群 broker=20。

公司研发部门的所有应用都接入到了这个集群中 ，正常情况下他们是下图这样的。

那么在滴滴Logi-KafkaManager中增加了Region和逻辑集群的概念之后，就可以是下图这样子划分了。

这样划分好了之后，运维管理员在审核各个业务线中的Topic申请的时候，就可以根据研发人员所填信息，进行Region的分配。

所以这样划分之后有几个明显的好处：

a.隔离性：不同应用的Topic散落到的Broker更集中，同时也可以减少Broker之间的通信。假如一个应用App-1接入的所有Topic，都在这20个Broker中有分区（例如TopicA分区到了1、2、3，TopicB分区到了4、5、6…）， 在这种情况下，应用App-1在发送的时候是不是就需要跟这20个Broker都有通信？假如App-1中所有Topic的创建都只在Broker 1、2、3中，那么这个连接数就可以减少了。

b.集群稳定性：可以避免小部分异常扩散到更大范围的异常，比如某个Broker不可用，那么影响的范围就会被控制在这个Broker所属的Region中的系统。

c.运维友好性：根据业务划分、保障等级等来划分逻辑集群，运维会对于整个集群有更清晰的了解和更有力的掌控， 然后就可以有针对性的做一些伸缩、扩容等操作。

划分好Region和逻辑集群之后，接下来的操作就是用户管理、应用申请、Topic申请。

 

4、用户管理、应用申请、Topic申请

1、创建一个普通用户

运维管理员新建一个普通用户角色的用户，普通用户就可以登录系统做一下应用申请、Topic申请等操作。

 

2、普通用户申请应用

 

普通用户登录账户后, 申请一下自己的系统

 

下图是运维管理员审核通过之后

 

3、普通用户申请Topic

 

 

普通用户申请Topic的时候，会选择指定的逻辑集群和Topic归属于哪个应用。然后运维管理人员会根据逻辑集群和所属应用来帮你将Topic划分至某一个Region或者Broker中。

注：上图中峰值流量指的是Topic的最大生产/消费速率

 

 

其实这里只是一个展示项，普通用户创建Topic的时候可以自己评估最大的生产速率是多少, 然后运维人员根据这个速率对这个Topic进行分区，如果速率大一点分配的分区数也可以更多一点。

那么，填写的速率和分区数应该怎么对应起来呢？这就需要用户自身来评判了, 毕竟每台Broker的性能配置啥的都不一样。

比如: 普通用户创建Topic的时候预估了一下，这个topic一条消息102kb，最大峰值的时候可能每秒会产生10000条数据。那么峰值流量就是102kb*10000/s，约等于1000Mb/s了 。

假如运维人员根据自己的经验或者压测结果得知一台XX配置的服务器最大写入速率在300MB/s，那么运维人员审核的时候就知道该topic至少要4台这样配置的broker。

注意：这里并不是真正设置限流的地方，只是作为一个分配分区数的参考值; 并没有把配额信息写入到zk中。

 

4、运维人员审核Topic

运维人员可以根据自身对Kafka集群的划分，选择对应的Region或者Broker。

比如，这个topic是归属于系统a的，刚刚我们划分的时候把它划分给了Region 1 中，那么审核的时候就可以选择对应的Region，当然也可以直接指定Broker。

在Topic审核通过之后，就可以去选中的Broker中create对应的Topic。这样Topic的创建就被KM管理了，它就会被限定在指定的Region或者Broker之中。

PS：只有在平台创建Topic的时候，会被限制在指定的Broker中。如果你直接用kafka提供的工具去创建Topic或者开启了Broker的自动创建Topic功能， 那还是不会被限制在我们的Broker中的。 所以个人建议关闭Broker中的自动创建Topic功能。

滴滴云Obsuite混合云可观测性中台，包含滴滴夜莺（Nightingale) 、滴滴Logi，有开源、企业版，利用指标、日志分析手段，提供覆盖资源、应用、业务的多层次监控和分析服务，为业务稳定性建设和运营方向决策提供强力支持。

Obsuite从metrics、log、trace三个方向着手，由滴滴夜莺和滴滴Logi两个产品组成。

滴滴Logi

滴滴Logi日志服务套件在滴滴内部经过7年多的沉淀打磨，针对日志采集、日志存储、日志计算、日志检索、日志分析各个环节，在组件能力上PAAS化建设、在引擎稳定性与扩展性上进行了针对性的优化。

目前该套件已经开源了滴滴Logi-KafkaManager，后期还会陆续开源Logi-Agent、Logi-LogX、Logi-ElasticSearchManager各PAAS套件。

1、滴滴Logi-KafkaManager Github：https://z.didi.cn/4newP

2、快速体验地址：http://117.51.150.133:8080/kafka  账号密码 admin/admin

3、日常FAQ：https://github.com/didi/Logi-KafkaManager/blob/master/docs/user_guide/faq.md

4、升级手册：https://github.com/didi/Logi-KafkaManager/tree/master/docs/dev_guide/upgrade_manual

5、滴滴Logi-KafkaManager云平台建设总结：

https://mp.weixin.qq.com/s/9qSZIkqCnU6u9nLMvOOjIQ

6、系列视频教程：https://mp.weixin.qq.com/s/9X7gH0tptHPtfjPPSdGO8g

 

滴滴夜莺

滴滴夜莺是一套分布式高可用的运维监控系统，最大的特点是混合云支持，既可以支持传统物理机虚拟机的场景，也可以支持K8S容器的场景。同时，滴滴夜莺也不只是监控，还有一部分CMDB的能力、自动化运维的能力，很多公司都基于夜莺开发自己公司的运维平台。

Github：https://z.didi.cn/4WurZ

官方文档：https://n9e.didiyun.com

提问必读：https://gocn.vip/topics/10811

语音答疑：https://m.ximalaya.com/keji/45095827/

视频教程：https://m.bilibili.com/space/442531657

二次开发：https://xie.infoq.cn/article/30d37e98fbe52ff2a79fc04b4

如果大家在使用滴滴Logi-KafkaManager和夜莺的过程中出现问题，或者有疑问需要与开发者交流的，都可以扫描下方二维码进入滴滴Logi及夜莺的开源用户群，在群中提问。

群内有滴滴Logi-KafkaManager和夜莺项目负责人：滴滴高级专家工程师—张亮、秦晓辉等技术大咖，在线为大家解答问题，欢迎大家长按二维码加小助手进群。（需备注Kafka或夜莺）