又到年底，总结一下：先抛出一个问题，超过1000台机器，到底应该怎样管理？

先计算下，1000台机器（这里指的是虚拟机，反正我们运维都要管理，不可能只管物理机）都有啥。按现在比较典型的案例举个例子：

1、包含托管IDC机房利用vm或KVM做虚拟化、公有云上的云主机、公司内部的一些服务器和PC、一些网络设备、甚至是一些打印机，门禁。这是肉眼看得见的设备。

2、运行的组件服务、容器、定时任务、脚本、日志等等

3、用户接入的前端代理、网络出口、网络专线等等

这些全部加起来总数又是多少？运行状态是怎样？资源配置是否合理？是否需要扩容？

第一个问题：现有的资产管理是否能覆盖全

第二个问题：怎样管理这个设备的连接方式，比如：jumpserver

第三个问题：监控如何保证

资产管理：我司是自己开发一套，能录入服务器、虚拟机、公共服务组件、K8S容器这些信息。

服务器登陆方式：使用的是2次开发过的jumpserver

监控系统：使用的2次开发过的Open-Falcon（去年写过了哈，今天不啰嗦）

3套完全独立的系统，资产管理信息最全，也最准。通过脚本调用公有云API、ESXI命令，能定时同步现有主机数量，容器也是类似。jumpserver也有自身的数据库记录配置的服务器信息。Open-Falcon也会记录一下监控的服务器数据。这一下就乱套了。公司临时增加一个服务器，用于临时做展示系统。理论上需要录入3个系统，但由于各种原因，可能只会存在于监控系统中。这就混乱了，资产管理中不存在的机器，在falcon中却能查询到是用于特殊任务的。现在有用还是没有用？找研发找测试，问了一圈没人知道。每隔3个月到半年都要进行一次资产盘点。另一个问题：如何确定这个机器或者这个容器是干什么的？给服务器或应用打标签是最好的解决办法。（思想来自夜莺--falcon的一群大神研发的监控系统）。

想到的解决方案：

资产管理系统增加覆盖面，不应只包含物理层的东西，尽可能覆盖全。最重要的一点，资产信息的入口只能有一个。主机信息列表共享给jumpserver使用，需要监控的信息可以打上一个专属tag，共享给监控使用。把整个资源管理作为整个运维的最底层基础架构。资产管理的里调整信息后最终都会传递给堡垒机和监控。

目前这只是想法，会花时间去把它落地。最终效果也可能会不尽人意，whatever。活着就得折腾。

牛B要吹大，小的放口袋：如果效果还行，会把它开源在github。