Kafka 灵魂伴侣之运维管控–集群运维.docxVIP

Kafka 灵魂伴侣之运维管控–集群运维 这个模块是用于自动化kafka集群升级用的,但是需要协作夜莺系统来使用(次要是在KM上将升级包发送到服务器上); 这个功能对应大集群来说格外好用,自动在线升级; 不需要手动去操作; 简约看一下使用图 版本管理 创建集群任务的时候, 需要上传 kafka升级包,和配置文件集 平台管理 应用管理 管理 全部使用Kafka的应用, Topic的创建需要管理到对应的系统(哪个系统); 这里呈现的是全部的应用；假如想看本人担任的应用;查看路径是 Topic管理 - 应用管理 应用申请 具有应用申请权限的用户可以申请新的应用 ; 然后由运维人员审批; 申请的地方在 Topic管理 - 应用管理 - 应用申请 应用担任人至少是两个 应用详情 呈现一些应用基本信息, 其中AppId和 密钥 在Topic鉴权的时候会使用到; 运维人员和应用责任人可以编辑信息,比如可以添加新的责任人; 申请下线 假如应用已经废弃不使用了,可以申请下线; 除了在这里运维管理人员可以申请下线; 应用担任人可以在 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的默认最大支持流量 系统每隔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的读写权限;