写点什么

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

用户头像
Obsuite
关注
发布于: 2021 年 01 月 29 日
滴滴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 公众号,获取更多信息。




用户头像

Obsuite

关注

混合云可观测性中台 2021.01.19 加入

Obsuite是来自滴滴的可观测性智能中台。微信服务号/B站:Obsuite;Github:https://github.com/didi/nightingale(滴滴夜莺)、https://github.com/didi/Logi-KafkaManager(滴滴Logi-KafkaManager)。

评论

发布
暂无评论
滴滴Logi-KafkaManager开源之路:一站式Kafka集群指标监控与运维管控平台