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

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

在平台建设的初期,我们调研了社区同类产品的使用情况,在调研中发现,外部同类产品无论在监控指标的完善程度、运维管控的能力亦或是使用的体验、还是整体的安全管控上都无法很好的满足我们的需求,因此自建滴滴 kafka 云管控平台势在必行。

经过前期产品同学的反复调研和设计、中期研发同学高质量的实现、后期针对用户体验反馈的持续迭代,kafka 云平台上线后广受内部用户和运维人员的好评,使用满意度达到90分。与此同时,还进行了开源和商业化输出,并被多家企业用户成功采购。

免费体验地址:http://117.51.150.133:8080/kafka ,账户admin/admin。

需求分析

在 Kafka 云平台建设的初期,我们对之前所面临的问题和需求进行了归纳分析,主要有以下几点:

  • 数据安全性

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

  • 服务的稳定性

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

  • 用户使用友好性

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

  • 问题定位高效性

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

  • 运维管控便利性

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

整体设计

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

1. 核心设计原则

在平台的整体设计上,我们制定了“一点三化”的设计原则:

  • 一点:以安全和稳定为核心点,建设 kafka 的网关系统,针对 topic 的生产/消费提供安全校验,同时提供多租户的隔离方案解决共享集群下多 topic 相互影响的问题;

  • 平台化:着重建设 kafka 云平台,反复进行需求调研和产品设计,提炼用户和运维的高频操作,将这些操作都通过平台实现,降低用户的使用成本;

  • 可视化࿱

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值