一、设计初衷
第一,传统的资产管理一般都是通过人为手动维护一个excel表,这样,当一台服务器的任何资产出现了变更,都需要人力去记录一下。而且,有时候容易忘记自己到底是否已经做了变更记录,这样就使得变更记录表信息越来越不准确,统计资产就变得相当的麻烦,这是设计初衷其一。
第二,随着公司部门的增多,每个部分都有自己消费情况,如果人为的统计,难免也会出现上述的错误,为了解决上述的问题,我们也需要这样一个资产管理来实时更新各个部门的日常开销,這是设计初衷其二。
第三,日常生产过程中,各个部分有时候会进行数据的交互。如果每个部分都以自己的方式将数据传递给开发人员,这样无疑是增大了他们的工作压力,因此,设计一个资产管理系统,是一个不错的选择。
基于上述三点,我们讨论出了一套解决上述问题的方案。即,设计一个管理资产的系统,所有需要录入的数据,都传递到该系统中,进入保存,一旦需要使用,我们可以通过接口,能够迅速的调用数据,也能实时观测各个数据的变化。
二、设计目标
1.实现自动采集服务器资产信息
2.实现报表功能
3.统一API接口,便于给其他部门提供数据
三、项目架构
整个项目分为三个部分:
资产采集部分、API接口部分、后台管理部分。
项目大致示意图如下:
通过API接口获取服务器传来的资产信息,然后保存入库。后台从数据库中取出数据,然后展示到页面上,便于统计与分析。
整个项目共由三人完成,1个运维人员,负责提供运维方面的知识以及提供需求;2个开发人员,负责数据录入以及后台页面数据的展示。
整个项目数据设计如下:
其中关系:
Disk,NIC,Memory与Server是FK关系
IDC,BusinessUnit与Server是FK关系,Tags与Server是M2M关系
UserGroup与BusinessUnit是FK关系,UserGroup与UserProfile是M2M关系,AdminInfo与UserProfile是o2o关系。
其中还有记录变更信息表和错误日志表。
四、涉及技术点
资产采集部分
- 复用Django-middleware实现高扩展性,可插拔式的配置文件。
- 复用Django用户配置与默认配置实现思路
- 兼容三种采集方式
- Agent代理方式(原理:在每一台服务器中都会存在一份脚本文件,在该服务器端执行了命令以后,将数据进行处理以后,然后通过requests.post发送到API接口,该接口将数据保存至数据库,供后台管理人员进行动态维护。)
- SSH方式(脚本文件存放在中控机上,由中控机来控制哪台机器应该采集信息.如果中控机发送了一个采集命令,然后命令到达目标主机,该主机执行该命令,然后将结果返回给中控机,最后由中控机将数据返回给api进行保存入库.)
- SaltStack(在master主机上执行salt 'c1.com' cmd.run '命令',然后master主机会自动连入对应的主机,然后目标主机执行该命令,将命令的结果返回给master.)
- requests发送客户端采集数据
- 使用线程池,实现多线程采集
- traceback记录采集错误日志
- paramiko模块-基于SSH链接远程主机并执行命令
API部分
- 获取今日未采集主机 自定义api验证机制(基于tornado签名cookie实现)
- 时间规则
- 加密字符串规则
- 访问次数规则
- 实现允许临时修改主机名
- 针对物理机(sn,物理机唯一,以此作为统计唯一)
- 针对物理机+虚拟机(hostname,前提先定义规则,主机名不允许重复)
- 日志变更记录
后台管理
- 自定义CURD插件
五、设计难点
- 在采集资产的时候,是否应该把虚拟主机当作资产采集。如果当作资产,以何种标志作为采集的唯一标识符?
- python事务+反射实现查看变更记录。
- API认证
六、补充
1.三种采集方式流程叙述
Agent代理模式
流程图:
叙述:
在每一台服务器中都会存在一份脚本文件,在该服务器端执行了命令以后,将数据进行处理以后,然后通过requests.post发送到API接口,该接口将数据保存至数据库,供后台管理人员进行动态维护。
模式优点:速度快
模式缺点:agent太多,影响系统性能
使用范围:大型公司
SSH模式(Ansible或Fabric)
流程图
叙述
脚本文件存放在中控机上,由中控机来控制哪台机器应该采集信息.如果中控机发送了一个采集命令(通过ssh远程链接),然后命令到达目标主机,该主机执行该命令,然后将结果返回给中控机,最后由中控机将数据返回给api进行保存入库。
优点:无agent代理,提高了系统性能
缺点:速度慢
适用范围:小型公司
基于第三方工具(SALT-STACK)
流程
叙述
在master主机上执行salt 'c1.com' cmd.run '命令',然后master主机会自动连入对应的主机,然后目标主机执行该命令,将命令的结果返回给master.master内部维护两个队列,如果master需要某个主机执行命令,那么它会将命令放在执行命令队列中而slave主机则等待执行队列中的消息,一旦其中有命令,就取出命令看是不是自己要执行的.而执行的结果将会放入到返回消息队列中,然后Master再去消息队列中取出消息,返回给api.