• 资产管理总结


    一、设计初衷

      第一,传统的资产管理一般都是通过人为手动维护一个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插件

    五、设计难点

    1. 在采集资产的时候,是否应该把虚拟主机当作资产采集。如果当作资产,以何种标志作为采集的唯一标识符?  
    2. python事务+反射实现查看变更记录。
    3. 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.

     

  • 相关阅读:
    DeepEarth开发文章汇总
    让人期待的Visual Studio 2010
    Silverlight & Blend动画设计系列文章
    杜拉拉“植入式营销”魔法(为写植入式广告fxgj介绍)
    C++ String Split
    一个类似Java String[] split(String regex)的VC++函数
    MSChart控件的属性与属性对话框
    植入式广告介绍 撰写 素材
    植入式营销 为何不能植入顾客脑海
    PQA2000 地震应急救生器
  • 原文地址:https://www.cnblogs.com/vipchenwei/p/7686987.html
Copyright © 2020-2023  润新知