元数据看板的初步设计思路

这是学习笔记的第 1784篇文章

今天在飞机上整理了一个初版的元数据看板接口的设计需求，然后又以设计图表的形式补充了一版，整体来说，这个元数据库看板的接口逻辑就梳理差不多了。

做这个接口有什么意义，或者是对标什么场景，其实主要考虑的是面向业务和面向运维自身的需求，一般我们去查看某个实例，大多数情况下都是基于IP的方式去查看的，整个数据库层的元数据我们规划为几个维度，但是鲜有人能够把这几个维度的信息都看个完整，需要在不同的维度信息中跳转才可以。如果我们能够简化到不需要再去寻找多个维度的入口，干脆一点，给我一个全景图，我们需要的其实就是这个信息，另外一点，如果我们设定了基本的粒度是IP+端口，那么我们输入的时候，需要明确IP和端口才能搞定，那么这个操作体验和使用效率是不大好的，只需要一个输入，就绝不输入多个条件。

元数据看板接口的初步需求整理如下：

根据IP信息查询

• 实例维度:

服务器有多少个实例

实例明细信息

• 主机维度：对应的虚拟机，宿主机基础信息
• 集群维度： 主从映射关系 对应的集群个数，集群明细
• 应用维度：关联应用维度的属性信息，业务简称，业务描述，归属部门等
• 备份维度：相关的实例备份记录信息，显示近3天的
• 工单维度：相关的工单信息
• 报警维度：抽取接口得到报警的相关信息
• 监控维度：得到概览的监控信息
• 如果IP为主库信息，能够定位到从库及集群信息
• 如果IP为从库信息，能够定位到主库及集群相关信息
• 如果IP为中间件IP，能够定位到集群信息
• 如果IP为VIP,能够定位到实例信息
• 如果IP为多网卡附加IP，能够定位到实例信息
• 如果IP对应的业务已下线，要明确提示出来
• 如果IP对应的业务有主机故障，实例故障，要明确给出提示信息
• 根据用户组来鉴别权限，如果不属于这个组，可以提示数据库类型，但是不显示明细信息

注：

MySQL中间件信息不属于实例，实例信息在其他主机和集群信息中维护

通过图表的方式来补充完善，就会看到有很多考量的维度和策略。

通过这些维度的数据梳理关系和映射，对于后期的元数据生命周期管理和流程化对接都是大有帮助。

你们的元数据实现流程化操作了吗，你怎么看？