Kafka灵魂伴侣Logi-KafkaManger(5)之运维管控–平台管理(用户管理和平台配置)

网友投稿 746 2022-05-28

推荐一款非常好用的kafka管理平台,

kafka的灵魂伴侣

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

@[TOC]

项目地址: didi/Logi-KafkaManager: 一站式Apache Kafka集群指标监控与运维管控平台

运维管控

运维管控这个菜单栏目下面主要是供运维人员来管理所有集群的;

集群列表

Kafka的灵魂伴侣Logi-KafkaManger(3)之运维管控–集群列表

集群运维

Kafka的灵魂伴侣Logi-KafkaManger(4)之运维管控–集群运维(数据迁移和集群在线升级)

平台管理

应用管理

管理 所有使用Kafka的应用, Topic的创建需要管理到对应的系统(哪个系统); 这里展示的是所有的应用;如果想看自己负责的应用;查看路径是 Topic管理 -> 应用管理

具有应用申请权限的用户可以申请新的应用 ; 然后由运维人员审批;

申请的地方在 Topic管理 -> 应用管理 -> 应用申请

应用负责人至少是两个

展示一些应用基本信息, 其中AppId和 密钥 在Topic鉴权的时候会使用到;

Kafka的灵魂伴侣Logi-KafkaManger(5)之运维管控–平台管理(用户管理和平台配置)

运维人员和应用责任人可以编辑信息,比如可以添加新的责任人;

如果应用已经废弃不使用了,可以申请下线; 除了在这里运维管理人员可以申请下线; 应用负责人可以在 Topic管理->应用管理 那里申请下线;

这里的展示的 连接信息 是需要配置滴滴的kafka-gateway组件才会展示的; 否则是拿不到相应的信息的; kafka-gateway并未开源,如果需要请联系官方;

连接信息展示Demo TODO…

在申请应用下线之前, 需要先确认该应用下面创建的所有topic都下线,否则运维人员下线的时候会提示:先下线topic,才能下线应用~

还需要注意就是如果申请了其他topic的使用权限,需要先取消权限

应用负责人需要申请Topic下线地方在 Topic管理->我的Topic->更多->申请下线

注意只有 你是应用负责人才能申请下线; 如果只是有部分使用权限是不能申请下线的;

同样的,这里的展示的 连接信息 是需要配置滴滴的kafka-gateway组件才会展示的; 否则是拿不到相应的信息的; kafka-gateway并未开源,如果需要请联系官方;

用户管理

运维人员 管理用户

KafkaManager的用户角色分了3种:

运维人员: 拥有平台所有权限

研发人员: 除了专家服务等权限,其他都有

普通用户: 普通开发者, 只有Topic管理,集群管理,监控告警等等权限

其实这里的角色权限取名理解起来比较费解,一开始我也以为研发人员就是我们所理解的普通开发者;

但是实际上

普通用户: 这个角色才是我们写代码使用kafak的开发者; 只需要关心自己的Topic模块就行;

研发人员: 包含普通用户的权限,但是它又具备运维管控的权限,使用场景就是 可能该角色是一个小组的TeamLeader;或者技术专家,他在普通用户的基础上需要去了解一下整个物理集群的监控状态,和找一些问题;

KM的用户角色和权限这一块还比较粗糙,跟社区反馈过,社区回应的是 将来会大改这一块,做一套统一的权限资源管理;

平台配置

一些系统的内部配置

配置键: ADMIN_ORDER_HANDLER_CONFIG 指定账户拥有审批权限

配置值Demo: [ "shirc_10", "shirc1" ]

描述: 很多审批需要运维人员进行审批; 如果运维人员太忙,不想花费时间在审批上,则可以指定部分账户拥有 审批权限; 代替审批; 这时候运维人员就没有权限审批了,审批按钮被隐藏了

申请人通过详情这里可以看到哪些人可以审批; 就可以找到对应的人帮忙审批一下了;

配置键: REGION_CAPACITY_CONFIG 设置集群Broker的默认最大支持流量

具体详情: 在 Kafka的灵魂伴侣Logi-KafkaManger三之运维管控–集群列表 有详细描述

系统每隔2分钟就去尝试将未落盘(比如刚接入KM,已经存在的Topic都未落盘)的Topic刷新到DB中; 当前前提是配置打开了 task.op.sync-topic-enabled: true

但是默认情况下,topic这个时候虽然刷到DB中了,但是属于无主Topic.没有绑定到对应的应用中

如果你想在刷到DB中的时候让它默认就绑定到某个默认的应用上就可以用到下面的配置了;

SYNC_TOPIC_2_DB_CONFIG_KEY 定期将未落盘的Topic刷新到DB中的时候,是否绑定到具体的应用和权限;

[ { "clusterId": 4, "defaultAppId": "dkm_admin", "addAuthority": true }, { "clusterId": 5, "defaultAppId": "dkm_admin", "addAuthority": true } ]

clusterId: 物理集群id

defaultAppId:默认绑定到的应用id

addAuthority: 是否同时增加应用对该topic的读写权限;

使用场景: 感觉没啥大用,就算这个时候没有绑定到应用上,后面我们还是可以针对Topic一个个去绑定对应的应用的;

其他一些不是很重要的配置就不列举了,有兴趣可以直接看源码

网关配置

配合 滴滴的kafka-gateway 组件使用的; 开源版本不需要关注

网关配置详细TODO

专栏文章列表

Kafka的灵魂伴侣Logi-KafkaManger(1)之集群的接入及相关概念讲解

Kafka的灵魂伴侣Logi-KafkaManger(2)之kafka针对Topic粒度的配额管理(限流)

Kafka的灵魂伴侣Logi-KafkaManger(3)之运维管控–集群列表

Kafka的灵魂伴侣Logi-KafkaManger(4)之运维管控–集群运维(数据迁移和集群在线升级)

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

Kafka 运维

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:SQL中的五种数据类型
下一篇:MongoDB是什么?看完你就知道了!
相关文章