kafka管控推荐使用滴滴开源的 Kafka运维管控平台更符合国人的操作习惯 ,
更强大的管控能力 ,更高效的问题定位能力、更便捷的集群运维能力、更专业的资源治理、更友好的运维生态

运维管控

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

集群列表

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

集群运维

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

平台管理

588

应用管理

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

应用申请

具有应用申请权限的用户可以申请新的应用 ; 然后由运维人员审批;
申请的地方在 Topic管理 -> 应用管理 -> 应用申请
979
应用负责人至少是两个
1194

应用详情

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

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

申请下线

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

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

连接信息展示Demo TODO..

在申请应用下线之前, 需要先确认该应用下面创建的所有topic都下线,否则运维人员下线的时候会提示：先下线topic,才能下线应用~
还需要注意就是如果申请了其他topic的使用权限,需要先取消权限
2023

应用负责人需要申请Topic下线地方在 Topic管理->我的Topic->更多->申请下线
注意只有你是应用负责人才能申请下线; 如果只是有部分使用权限是不能申请下线的;
2321
同样的,这里的展示的 连接信息 是需要配置滴滴的kafka-gateway组件才会展示的; 否则是拿不到相应的信息的; kafka-gateway并未开源,如果需要请联系官方;

用户管理

运维人员管理用户
2649

用户角色

KafkaManager的用户角色分了3种:

运维人员： 拥有平台所有权限
研发人员： 除了专家服务等权限,其他都有
普通用户： 普通开发者, 只有Topic管理,集群管理,监控告警等等权限

其实这里的角色权限取名理解起来比较费解,一开始我也以为研发人员就是我们所理解的普通开发者;
但是实际上
普通用户: 这个角色才是我们写代码使用kafak的开发者; 只需要关心自己的Topic模块就行;
研发人员： 包含普通用户的权限,但是它又具备运维管控的权限,使用场景就是可能该角色是一个小组的TeamLeader;或者技术专家,他在普通用户的基础上需要去了解一下整个物理集群的监控状态,和找一些问题;

KM的用户角色和权限这一块还比较粗糙,将来会大改这一块,做一套统一的权限资源管理;

平台配置

一些系统的内部配置

配置键: ADMIN_ORDER_HANDLER_CONFIG 指定账户拥有审批权限
配置值Demo: [ "shirc_10", "shirc1" ]
描述: 很多审批需要运维人员进行审批; 如果运维人员太忙,不想花费时间在审批上,则可以指定部分账户拥有审批权限; 代替审批; 这时候运维人员就没有权限审批了,审批按钮被隐藏了
3491
申请人通过详情这里可以看到哪些人可以审批; 就可以找到对应的人帮忙审批一下了;

配置键: REGION_CAPACITY_CONFIG 设置集群Broker的默认最大支持流量
具体详情: 在 Kafka的灵魂伴侣Logi-KafkaManger(3)之运维管控--集群列表有详细描述

系统每隔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的读写权限;

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

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