滴滴 Logi-KafkaManager 开源之路：一站式 Kafka 集群指标监控与运维管控平台

导读

从 2019 年 4 月份计划开源到 2021 月 1 月 14 号完成开源，历时 22 个月终于修成正果，一路走来实属不易，没有前端、设计、产品，我们找实习生、合作方、外部资源支持，滴滴 Kafka 服务团队人员也几经调整，内部迭代了 3 个大版本，我们最终还是克服重重困难做到了！一经开源获得了社区用户广泛的认可，截止当前 Star 达到 1150，钉钉用户突破 540 人，滴滴开源 Logi-KafkaManager 一站式 Kafka 监控与管控平台阅读 1W+UV。

01 滴滴 Logi-KafkaManager 简介

Kafka 作为滴滴大数据消息队列，每天承载万亿级消息的生产与消费，面对 100GB/S+峰值采集流量，服务了公司内近千 Kafka 用户，托管了数十 Kafka 集群，数万 Kafka Topic，单集群>300+Broker。历经四年打磨沉淀，围绕滴滴 Logi-KafkaManager 打造了滴滴 Kafka 平台服务体系，内部满意度达到 90 分。

滴滴 LogI-KafkaManager 是面向 Kafka 用户、Kafka 运维人员打造的共享多租户 Kafka 云平台，专注于 Kafka 资源申请、运维管控、监控告警、资源治理等核心场景。一经开源广受社区用户喜爱，免费体验地址：http://117.51.150.133:8080/kafka，账户 admin/admin，欢迎 Star。

02 为什么要开发滴滴 Logi-KafkaManager

滴滴内部有几十个 kafka 集群，450+的节点，每周 500+UV 用户，需要完成 topic 创建、申请、指标查看等操作；每天运维人员还有大量 topic 管控、治理、集群运维操作。因此我们需要构建一个 Kafka 的管控平台来承载这些需求。我们调研了社区同类产品，在监控指标的完善程度、运维管控的能力、服务运营的理念都无法很好的满足我们的需求。

03 滴滴 Logi-KafkaManager 功能亮点

>产品化设计之关注点分离

业界开源的 KafkaManager 定位是一个面向运维人员的监控工具，在滴滴我们定位是全托管 Kafka 服务工具型平台产品，针对的人群区分为 Kafka 用户、Kafka 运维。

• Kafka 用户：关注的是 Topic 相关的操作，Topic 资源申请与扩容、Topic 指标监控、Topic 消费告警、Topic 消息采样、Topic 消费重置等。

• Kafka 运维：关注的是 Kafka 集群相关的操作，集群监控、集群安装、集群升级、集群 Topic 迁移、集群容量规划等。

>Kafka 业务运行过程数据化

作为消息中间件，Kafka 最核心的能力就是消息的生产、消费，用户高频的问题都与此相关，作为服务提供方，我们需要详细的感知 Topic 的生产消费在服务端各个环节耗时，快速界定到底是服务端还是客户端问题，如果是服务端问题，出在哪个环节，如下图所示：

• 请求队列排队时间(RequestQueueTimeMs)

• Broker 本地处理时间(LocalTime)

• 请求等待远程完成时间(RemoteTimeMs)

• 请求限流时间(ThrottleTimeMs)

• 响应队列排队时间(ResponseQueueTimeMs)

• 响应返回客户端时间(ResponseSendTimeMs)

• 接收到请求到完成总时间(TotalTimeMs)

通过将这些服务端运行指标，以 Topic 粒度呈现，显著的提升了服务用户的效率，如下图所示：

>Kafka 服务保障强管控

Kafka 各语言客户端版本众多，官方也只有精力维护 Java 版的 SDK，滴滴受限于服务人力，没有进行客户端版语言与版本管控，服务端拓展实现强管控客户端元信息的能力。

• 拓展服务端能力，强感知客户端的链接地址，协议类型，方便后续引擎对用户行为的感知与强管控。

• 拓展实现 Kafka 服务端的安全认证能力，通过账号机制记录应用元信息，包括人员信息、业务信息、权限信息；通过 Topic 创建管控，记录压缩类型、Partiton、Quota 等元信息，在服务端实现了对客户生产、消费能的强管控。

>最佳实践之专家服务沉淀

多年 Kafka 服务运营经验，我们沉淀了大量的服务保障最佳实践，结合应用场景，截止目前构建了以下几项专家服务，后续我们会持续打磨与完善。

• Topic 集群分布不均迁移：不同 broker 上 leader 数目不均；同一个 broker 上不同磁盘 leader 分布不均；同一个 topic 在 broker 上不同磁盘分布不均。我们需要发现热点，给用户推荐迁移计划。

• Partitont 不足扩容提示：根据单 Partition 承载流量，按照业务场景与底层硬件资源进行主动扩容提示，扩容标准：滴滴的实践是 TPS 场景：单 Partition 3MB/S；IOPS 场景：单 Partition 10 条/S。

• Topic 无效资源下线：针对线上持续一个月 Topic 无流量，无生产消费链接的资源，通知用户进行主动资源释放。

04 滴滴 Logi-KafkaManager 架构

平台设计之初，我们就基于开源的理念进行平台建设，遵循了依赖精简、分层架构、能力 API 化、100%兼容历史开源版本的原则，整体架构如下：

• 资源层：滴滴 Kafka 引擎和 KafkaManager 除了 zookpeer 之外只依赖 msyql，依赖精简，部署方便；

• 引擎层：当前滴滴 kafka 引擎版本是 2.5，我们在此基础上开发了一些自己的特性，如磁盘过载保护、IO 线程池分离、Topic 创建资源分配优化等功能，并且完全兼容开源社区的 0.10.X kafka 版本；

• 网关层：引擎层之上滴滴设计了网关层，提供了安全管控、topic 限流、服务发现、降级能力；

• 服务层：基于 kafkaGateway 我们在滴滴 Logi-KafkaManager 上提供了丰富的功能，主要有：topic 管理、集群监控、集群管控能力；

• 平台层：分别针对普通用户和运维用户，提供不同的功能集合，尽可能的将一些日常使用中的高频操作在平台上进行承接，降低用户的使用成本，同时核心能力 API 化，方便用户生态对接。

写在最后

项目开源只是万里长征的第一步，产品还需要持续的打磨与建设，但行好事莫问前程，感谢那些曾经为这个项目付出努力的童鞋们，特别是当前团队的兄弟们，过去一年非常不容易，开源的技术梦想让我们紧密的团结在一起，以此文向开源的领路人章文嵩致敬！

滴滴 Logi-KafkaManager 是 2021 年团队开源梦想的一小步，是滴滴 Logi 日志服务套件整体开源计划的重要组成部分，欢迎关注 Obsuite 公众号或者加入 Logi 滴滴用户钉钉群，给我们的产品提出宝贵意见，也欢迎小桔子们推荐给有需要的技术童鞋！关注 Obsuite 公众号，获取更多信息。