滴滴开源Logi-KafkaManager 一站式Kafka监控与管控平台

导读： LogI-KafkaManager脱胎于滴滴内部多年的Kafka运营实践经验，是面向Kafka用户、Kafka运维人员打造的共享多租户Kafka云平台。专一于Kafka运维管控、监控告警、资源治理等核心场景，经历过大规模集群、海量大数据的考验。内部满意度高达90%的同时，还与多家知名企业达成商业化合做。

滴滴内部统一使用 kafka 做为大数据的数据通道，当前滴滴共有几十个 kafka 集群，450+ 的节点，20k+ 的 kafka topic，天天2w亿+的消息量；每周500+UV用户，须要完成 topic 建立、申请、指标查看等操做；天天运维人员还有大量集群、topic运维操做。所以咱们须要构建一个Kafka的管控平台来承载这些需求。

在平台建设的初期，咱们调研了社区同类产品的使用状况，在调研中发现，外部同类产品不管在监控指标的完善程度、运维管控的能力亦或是使用的体验、仍是总体的安全管控上都没法很好的知足咱们的需求，所以自建滴滴 kafka 云管控平台势在必行。

通过前期产品同窗的反复调研和设计、中期研发同窗高质量的实现、后期针对用户体验反馈的持续迭代，kafka 云平台上线后广受内部用户和运维人员的好评，使用满意度达到90分。与此同时，还进行了开源(https://github.com/didi/Logi-KafkaManager)和商业化输出，并被多家企业用户成功采购。 免费体验地址：http://117.51.150.133:8080/kafka ，帐户admin/admin。

1.需求分析

在 Kafka 云平台建设的初期，咱们对以前所面临的问题和需求进行了概括分析，主要有如下几点：

数据安全性

因为绝大多数用户使用的kafka topic 都会由公共集群来承载数据的生产和消费，而当前 kafka 引擎在 topic 级别的安全管控手段较为薄弱，任何人只要知道kafka集群地址和相应的topic即可进行消费。这无疑会形成数据泄漏的安全风险，所以数据的安全性成首要被解决的问题。

服务的稳定性

滴滴内部绝大部分的 topic 是在共享集群上，共享集群下多 topic 之间存在着相互影响的问题。如某个 topic 的流量突增可能会大面积地影响其余 topic ，从而致使业务的抖动和集群的不稳定。所以在共享集群下，kafka 服务的稳定性也成为了一个必须被解决的问题。

用户使用友好性

滴滴内部每周有大量的用户须要进行 topic 的建立、消费、扩partiton、指标查看等操做，用户高频使用的功能须要作的足够的友好和容易上手，这样才能最大的简化用户的操做和减低平常开发和运维人员的答疑成本。所以用户高频操做的平台化支撑，则成为接下来须要解决的问题。

问题定位高效性

在平常使用 kafka topic 的过程当中，会有大量的问题须要查看和定位，如：消息生产和消费的速度、消息堆积的程度、partition的均匀度、topic的分布信息、broker的负载信息、副本的同步信息等，如何使用户和运维人员快速高效的定位问题、处理问题，是重点须要解决的问题。

运维管控便利性

在平常的运维中，会存在着大量的集群、topic的运维操做，如：集群的部署、升级、扩缩容、topic的迁移、leader rebalance等高频高危的操做，怎么样在提高运维操做效率的同时，还要保证高危操做不会影响集群稳定性，这个也是须要去重点考虑。

2. 总体设计 

从以上的需求分析能够看出，滴滴 kafka 云平台建设须要解决的问题比较多元，所以在设计之初就须要对总体有一个清晰的思路和规划，为此咱们定义了一个核心设计原则，并对业务进行了合理的分层用以指导咱们后续的产品设计和代码开发。

▍1. 核心设计原则

在平台的总体设计上，咱们制定了“一点三化”的设计原则：

• 一点：以安全和稳定为核心点，建设 kafka 的网关系统，针对 topic 的生产/消费提供安全校验，同时提供多租户的隔离方案解决共享集群下多 topic 相互影响的问题；
• 平台化：着重建设 kafka 云平台，反复进行需求调研和产品设计，提炼用户和运维的高频操做，将这些操做都经过平台实现，下降用户的使用成本；
• 可视化：提高topic/集群监控、运维过程当中指标的可观察性，全部指标尽可能能在平台上能够直观体现，方便使用者及时感知集群运行状态，快速定位问题；
• 专家化：将平常集群运维的经验沉淀在平台上，造成专家服务能力和智能化能力，进一步下降 kafka 集群的维护成本，提高总体稳定性。

▍2. 业务分层架构

在滴滴 kafka manager 具体的业务设计上，咱们采起分层设计，从下至上分为如下几层：

• 资源层：滴滴 kafka 引擎和 kafka manager 除了 zookpeer 以外只依赖 msyql，依赖精简，部署方便；
• 引擎层：当前滴滴 kafka 引擎版本是2.5，咱们在此基础上开发了一些本身的特性，如磁盘过载保护，而且彻底兼容开源社区的 kafka；
• 网关层：引擎层之上咱们设计了网关层，网关层的设计很是巧妙，主要提供：安全管控、topic 限流、服务发现、降级能力，具体详见后文“安全性”的内容；
• 服务层：基于kafka gateway 咱们在 kafka manager 上提供了丰富的功能，主要有：topic 管理、监控管理、集群管理等；
• 平台层：对外提供了一套 web 平台，分别针对普通用户和运维用户，提供不一样的功能页面，尽量的将一些平常使用中的高频操做在平台上进行承接，下降用户的使用成本。

 

▍3. 应用逻辑架构

在实际的应用部署和关联上，总体的 kafka manager 和 kafka 引擎、kafka gateway 之间的逻辑关系比较简单，具体以下图所示：

• kafka gateway 包括两大块功能：服务发现、元数据网关，详细介绍见后面的元数据网关设计一节。
• kafka manager 提供咱们开发的特点功能，如：topic管理、监控管理、集群管理，以及相应的 web 平台，普通用户和研发运维人员平常操做接触最多，最高频的操做都将这上面完成。

 

3. 安全性

以kafka 数据的安全性和集群使用过程当中的稳定性保障是咱们在构思和设计整个 kafka 云平台时首要考虑的问题，为此咱们设计了一套 kafka 元数据网关和多租户的隔离模型来解决这些问题。

▍1. 元数据网关设计

用户在接入原始的 kafka 集群时没有安全管控，没法有效的管理用户的使用行为，对数据安全和集群稳定性形成严重的风险，所以咱们设计了一套 kafka 集群元数据网关系统来解决安全问题。

kafka gateway 系统除了解决数据的安全风险还附带了如下做用：

• 提供 kafka 集群的服务发现服务节点，这样用户在使用 kafka 集群服务时，当 kafka cluster boostrap 地址变动时，则不须要用户改动 kafka 的链接地址，不用重启 kafka client，保障集群的变动对用户透明；
• 提供 kafka topic 生产和消费的限流能力，避免用户无限制的使用集群的流量，流量大的用户会耗尽系统资源从而影响其余用户的使用，形成集群的节点故障；

须要注明说明一点，kafka gateway 的设计很巧妙的将这些功能实如今 kafka 引擎内部。由于 kafka 做为一个消息系统，其自己流量是很是的巨大，若是 kafka gateway 做为一个单独应用存在，全部流量都先经过 gateway 再进入 kafka 引擎，则对 kafka gateway 机器资源的消耗是很是巨大的，基本等同于须要增长一倍的机器资源，而且整个流程的耗时也会增长。因此在设计之初，就把 kafka gateway 和 kafka 引擎合在一块儿，这即是滴滴 kafka 引擎的特点能力所在。

搭建好 kafka gateway 系统以后，用户使用 kafka topic 的流程变为以下：

• 在 kafka manager 上申请租户(appid)，获取到对应的租户密码(app-password)；
• 利用 appid 申请建立新的 topic，或者申请已存在的 topic 的生产和消费权限；
• 使用 kafka client 时设置好对应的 appid 和 app-password，相应的 topic 鉴权，限流都在 kafka broker 端完成。

▍2. 多租户隔离模型

在滴滴内部，绝大部分的 topic 是在共享集群上的，在没有管控的状况下，topic 的各个分区是随机的分布在不一样的 broker 上，随着集群中 topic 数量的增长，topic 流量的变大，某个具体 topic 的抖动有可能会影响到其余的 topic，所以共享集群下的 topic 隔离就是很是必要的，为此咱们结合 kafka gateway 在 kafka manager 上设计了一套多租户隔离模型来解决这个问题，具体操做以下：

• 对将kafka 集群中的各个 broker 进行划分，一组 broker 被分红一个 region，这个 region 在业务上被抽象为一个逻辑集群；
• 用户在申请建立新的 topic 时须要选择一个逻辑集群，这样 topic 的分区只能建立在一个逻辑集群上，也就是一组 broker 上；
• 具体 topic 消息的生产和消费就只会和一组 broker 发生关系，若是某个 topic 的抖动也只会影响特定 broker 上的其余 topic，从而将影响限定在必定的范围内。

4. 平台化

滴滴 kafka manager 平台建设之初就把易用性做为主要目标，所以在产品设计上很是注重用户的使用体验，前期经过反复的用户调研和内部讨论，最终提炼出普通用户和运维用户的高频操做，将这些操做都经过平台实现，下降用户的使用成本。

• 方便的平常用户使用

用户只关注本身的Topic的信息(默认)，以减小没必要要信息的干扰；

足够的指标信息，以保证用户能自助解决问题的同时减小没必要要信息的干扰；

• 高效的运维操做

提炼用户、运维人员建立Topic、调整配额、扩展分区、集群迁移、集群重启等高频运维操做，将高频操做平台化，简化用户操做，大大下降运维成本。

提供总体集群直观的全局视角，以提升排查问题的效率以及对集群规模的直观感知，并提供详尽的局部视角，以提升排查问题的效率；

• 友好的生态

内部版本与滴滴监控系统打通，开源版本与滴滴开源的夜莺监控告警系统打通，集成监控告警、集群部署、集群升级等能力，造成运维生态，凝练专家服务，使运维更高效。

• 体贴的细节

kafka 云平台的建设，它有着本身的设计理念，如：应用、权限、限流等；kafka 集群的 broker 和 topic 的上也存在着各类指标，操做任务，审批流程等，这些都会对用户的使用形成困惑。虽然产品同窗在反复的体验和持续的优化迭代，可是为了进一步的方便用户使用，咱们在各类用户可能感受到困惑指标含义的地方，设置了大量的提示说明，让用户不用出页面就能够基本解决问题，整个使用过程力争如丝般顺滑。

• 出众的颜值

常见的内部工具型产品每每都是以知足功能和需求为主，不少都是功能在页面上的堆砌，kafka 云平台在建设之初，在产品设计和前端开发上也力求更高的标准，最终总体的风格相比以往提高巨大，一上线就被用户称赞为 “大厂出品” ，相比目前几款主流开源的 kafka 管理平台，在页面美观程度上大大超出其余同类产品，能够说是“我花开后百花杀”。

5. 可视化

运维人员在平常进行kafka 集群维护和稳定性保障过程当中，对集群和 topic 的各项指标都很是关注，所以指标采集展现的准确性和及时性变得很是重要。为此咱们将指标的可视化也做为 kafka manager 建设的核心目标。

• 黄金指标定义

针对 broker 和 topic 平常监控和诊断问题过程当中最主要的指标进行筛选，这些指标被定义为黄金指标，如：topic 的 messageIn、byteIn等，并在平台的相关页面上进行高优高亮展现，便于用户在平常使用过程当中，快速诊断和定位集群可能存在的问题。同时咱们还根据 broker 和 topic 的指标监控，制定了一套用于快速识别其运行状态的健康分算法，将多个指标进行加权计算，最终获得一个健康分数值，健康分的高低则直观的展现了 broker 和 topic 实际运行过程当中的状态，便于用户和运维快速从多个 broker 和 topic 中识别。

• 业务过程数据化

增长基于 topic 生产消费各环节的耗时统计，支持动态开启与关闭，帮助用户自助排查问题；关键指标业务运行过程化，不一样分位数性能指标的监控，方便历史问题回溯诊断。

• 服务端强管控

服务端记录客户端链接版本和类型，链接强感知，集群强管控，元信息的基石；controller 强管控，指定的主机列表，记录 controller 历史运行节点；记录 topic 的压缩格式，应用与业务元信息，业务强感知。

6. 专家化 

基于以前全面的kafka数据采集，和运维同窗在平常操做过程当中的一些经验总结，咱们将高频的问题和操做沉淀造成特有的专家服务，来智能诊断 kafka 集群和 topic 的健康状态，并提供对应的处理方案。

kafka manager 的专家服务能提供了如下功能：

• 分区热点迁移

a.背景：Kafka只具有Topic迁移的能力，可是不具有自动均衡的能力，Region内部分Broker压力很是大，可是部分Broker压力又很低，高低不均。若是不当即处理，轻则没法继续承接用户的需求，重则因为部分Broker压力过大致使集群出现稳定性问题。

b.解决方案：

i. 在滴滴 kafka 引擎上增长 topic 在不一样磁盘上分布的指标；

ii. kafka manager 经过定时采集的 topic 指标来分析 topic在不一样磁盘上的分布均匀度；

iii. 针对不均匀的 topic 发起迁移操做，并在迁移时进行流量控制，保证迁移不会影响集群的稳定性。

• 分区不足扩容

a.背景：kafka 集群的 topic 相关的元信息存储在 zookpeer 上，最终由 controller 将其同步到各个broker。若是元信息过大，controller 同步的压力就会随之上升成为整个集群的瓶颈点，若是遇到某台 broker 出现问题，整个集群的数据同步就很是慢，从而影响稳定性。

b.解决方案：

i. 在用户申请建立 topic 的时候，平台进行分区数的管控，分区数不能设置的特别大，然而随着 topic 流量的上升，topic 分区可能不足。若是遇到 topic 流量突增，超过了单分区能承载的能力，会致使分区所在的Broker出现压力，如cpu和load升高等问题，客户端也会出现发送堆积的状况。

ii. 基于现有的机型以及客户端的消费发送能力的压测，咱们定义了单分区的承载流量，同时咱们实时对每一个 topic 的流量进行监控，当某个 topic 的峰值流量持续的达到和超过阈值以后，会对该 topic 进行标记或者告警，定义为分区不足的 topic。

iii. 针对监控发现出来的分区不足的 topic，由运维人员手动进行扩分区，或者 kafka manager 根据当前集群整个容量状况自动进行扩分区。

• topic资源治理

a.背景：公共集群中用户申请建立的 topic，它们的使用状况是各不相同的，还存在着部分 topic 根本不使用还占据集群元数据的状况，这对原本就十分拥挤的公共集群形成很大的资源浪费和稳定性风险，所以针对集群中的不使用的 topic进行治理就很是必要。

b.解决方案：

i. 实时对集群中全部 topic 的流量进行采集监控，智能的分析 topic 的流量趋势，若是发现 topic 的流量持续在一段时间内为0，则进行标记或者告警。

ii. 针对监控发现的必定周期无流量、无生产消费连接的topic，进行通知和下线清理操做。

7. 同类对比

咱们来和外部相似的产品进行一个简要的功能对好比下：

通过简单的对比，咱们能够看到，通过平台化、可视化、智能化、安全建设以后，滴滴kafka manager在安全性、用户体验、监控、运维管控上都有着显著的优点，也提供了不少特点的功能，极大的方便了用户和运维人员的平常使用，欢迎你们Star和体验https://www.didiyun.com/production/logi-KafkaManager.html

8. 展望 

Logi-Kafka-Manager 已在滴滴内部上线使用，将来咱们除了在平台化、可视化、智能化基础上持续改进，还会在如下几个方面持续努力：

• 平滑的跨集群迁移

咱们将基于 MirrorMaker + KafkaGateWay 打造一套 kafka Topic 跨集群平滑迁移能力，在 kafka manager 平台上为 kafka topic 运维管控提供更为高效的迁移能力，进一步提高运维效率。

• 更多的指标监控

进一步的支持 kafka 2.5+ 最新版本的管控，而且新增更多的关键指标的监控，从而让 kafka manager 指标展现和问题定位的能力更强大。

• 持续回馈开源社区

做为在滴滴内部通过大量复杂场景验证过的 kafka 管控平台，咱们会持续对其进行核心业务抽象，剥离滴滴内部依赖，回馈社区，咱们也但愿热心的社区同窗和咱们交流想法，共同提高滴滴 Logi-KafkaManager 的功能和体验。

开源团队