运维平台的建设思考-元数据管理(二)(r8笔记第11天)

之前分享过一篇元数据管理的文章 运维平台的建设思考-元数据管理，如果服务器不多，或者人也不多，基本都是按照下面的方式来管理。 比如下面是14台服务器，会在特定的服务器（比如中控）设置一个专门的路径来存放一个文件，即服务器列表信息，然后把对应的责任人都划分出来。

当然这种方式是比较简单，也看起来确实很清晰，对于基本的管理应该是没有问题，但是一旦发生了信息的变化，这部分信息就比较容易出现遗漏，比如服务器2出 现了问题，做了故障退还，那么就需要张三在服务器列表中标注为故障退还，可能后面给他新分配了一台服务器，他也可能没有记录新的服务器到这个文件里面，或 者没有标注故障归还的服务器。 如果李四来帮助张三临时处理问题，那么这个时候这些信息就无从知晓，也不好跟进。或者张三把某台服务器的归属列为李四，也没有通知李四，没有问题大家都相安无事，但是一旦出现问题，这种责任归属和问题的划分就会比较松散。 那么一种改进思路就是需要有一个专员来协调负责这些元数据的管理。机器的申请，退还肯定要有流程，那么这些流程的一个触发器就是资产信息的变更，这些都需 要跟随资产信息变更来在列表中得到体现。但是张三李四王五没有直接的权限来修改这些信息，可以提出申请修改，需要有一个审核的过程。

无规矩不成方圆，如果有成千上万台，那么这种集中-分布式的管理就尤为重要。 这些服务器信息终归还是需要放到一个共享的目录中，大家都可以查看。从这个演变来看就是excel和数据库中存储信息的差别了。 那么对于每个负责来说都是关注自己的那一亩三分地为主，所以需要从这个共享的文件中得到属于自己的那一部分信息来。 然后在这个基础上进行针对性的检查和问题处理，比如硬件监控，比如oracle数据库监控，MySQL监控等。 一种方式就是采用本地发送脚本的方式，这种方式有点类似JDBC的感觉，就是通过ssh能够连接到远程服务器，然后把需要发送的脚本内容一并发送过去，这种方法的有点狠明显，就是依赖性很小。而且可扩展性强。如果脚本不大不多的情况下还是优选。

还有一种是类似agent的方式，就是在每台服务器端都部署一个类似的agent,每个agent中都包含有这些相关的脚本内容。直接通过远程调用的方式就可以得到结果。 这种方式对于大批量的脚本，复杂的功能需求还是比较通用。

需要说明的是，这些共享的服务器资产信息是放在了数据库中。 从目前的元数据管理的情况来看，其实对于每个人来说，还是主要关心自己负责的服务器，就需要从共享文件中生成属于自己的服务器列表信息，而且这些服务器信息还可以随着资产信息变化而变化，不要求实时，但是要求这些变化能够体现出来。然后基于此来实现特定的业务管理需求。 后续来分享一个比较奇怪的元数据抽取的案例。