一、前言

很多公司在做自动化运维平台前都会先做一个CMDB,做CMDB的第一步就是建模和采集数据。说到采集数据,为了避免过多人工介入导致数据准确率低,采集方法普遍分为两种:

1. 一小部分静态数据人工录入

2. 大部分数据用程序采集

第二部分,不同的公司有的用shell实现一套,有的公司拿脚本语言实现一套,有的公司在需要的时候主动收集一次,有的公司自动定期收集。

汽车之家的方法是“Puppet Facter脚本”+“定期自动收集”。并且我们已经将其开源在Github(Assets_Report)上跟大家分享。

下面我们详细解说一下原理和使用方法。

二、原理介绍

众所周知,Puppet是一套配置管理工具,是一个Client/Server模式的架构,可以用它来管理软件、配置文件和Service。然后,Puppet生态圈里有个叫Facter的工具,运行在Agent端,可以和Puppet紧密配合完成数据采集的工作。但是Facter提供采集的数据毕竟有限,一些更加底层的硬件数据就没有采集,而这些数据也是我们所需要的,这就是我们开发本工具的动机。

虽然Facter采集的数据有限,但是Facter本身是一个很好的框架,非常容易对其进行扩展,所以我们基于Facter进行了扩展,配合Puppet Master的Report Processor将采集的结果上报给AutoBank(这是汽车之家的CMDB代号,可以参考《运维的数据银行-构建CMDB方法》),由此来完成一个完整的采集逻辑。

这是Puppet的Server跟Agent之间的工作流程图

Agent在发送Request请求Catalog的阶段,会将自身的facts都上报给Master。而Master接到数据后可以利用自身的Report Processor对其进行二次处理,例如转发到别处。

正是基于上述的原理,我们开发了自己的Report Processor:assets_report,通过HTTP协议将facts post给AutoBank的http接口让其入库。

对开发custom facts感兴趣的同学可以参考 fact_overview 和 custom facts。

如上所述,我们的Assets_Report项目包含了如下两个组件来实现整个逻辑

1. assets_report模块:一个纯Puppet Module,内建了一个Report Processor和一些自定义Facter插件,部署在Master端。

1. Report Processor运行在Master端。

2. Facter插件会通过Master下发到Agent端并被运行以采集本机资产数据

2. api_server:负责接收资产数据并将其入库

三、采集插件的功能介绍

相对于Facter内建的facts,本插件提供了更多的硬件数据,例如

1. CPU个数,型号

2. 内存容量,序列号,厂商,插槽位置

3. 网卡上绑定的ip,掩码,mac,型号,且支持一个网卡上绑定多ip的场景

4. RAID卡个数,型号,内存容量,RAID Level

5. 磁盘个数,容量,序列号,厂商,所属RAID卡,插槽位置

6. 操作系统类型,版本

7. 服务器厂商,SN

高级特性:为了避免大段相同数据重复上报,减轻AutoBank的数据库压力,本插件具备Cache功能,即如果一台服务器的资产数据没有发生变更,那么只会汇报not_modify标记。

本插件支持的操作系统有(系统必须是64位的,因为本插件中的采集工具是64位的)

1. CentOS-6

2. CentOS-7

3. Windows 2008 R2

本插件支持的服务器有

1. HP

2. DELL

3. CISCO

四、采集插件的安装方法

安装操作在Puppet Master端进行。

假定你的模块目录为/etc/puppet/modules

cd ~
git clone git@github.com:AutohomeOps/Assets_Report.git
cp -r Assets_Report/assets_report /etc/puppet/modules/

在你自己的puppet.conf(假设默认路径是/etc/puppet/puppet.conf)中添加

reports = assets_report

然后在site.pp中添加如下配置,让所有Node都安装assets_report模块

node default {
  #  include assets_report
  class {'assets_report': }
}

配置完毕后,采集工具会被自动下发到Agent上进行安装。下一次Puppet Agent运行时本插件即可正常工作。

五、汇报组件的配置方法

配置操作在Puppet Master端进行。

配置文件为 assets_report/lib/puppet/reports/report_setting.yaml

参数

含义

示例

六、汇报接口服务的配置方法

配置操作在Puppet Master端进行。

本接口服务api_server基于一个Python编写的Web框架Django开发,该组件包含了数据库设计和http api的实现。因为各家公司的数据库设计均不一致,该项目仅实现了最简单的数据建模,所以该组件的存在仅作为Demo,不可用于生产环境,读者需注意。

首先,我们需要安装一些依赖。这里假定你的OS为CentOS/RedHat

$ cd ~/Assets_Report/api_server
安装pip,用它来安装python模块
$ sudo yum install python-pip
安装python模块依赖
$ pip install -r requirements.txt

初始化数据库,可以参考 Django用户手册

$ python manage.py makemigrations apis
$ python manage.py migrate
数据库为当前目录下的db.sqlite3

启动http api service

$ sudo python manage.py runserver 80
服务将监听localhost的80端口。
Django version 1.10.5, using settings 'api_server.settings'
Starting development server at http://127.0.0.1:80/
Quit the server with CONTROL-C.

七、使用

在Puppet Agent端手动触发

puppet agent -t

或者 puppet agent的daemon自动运行后,数据采集上报的流程就会触发,上面的api server的80端口就会收到一次post请求,数据库里将会看到本次采集的数据。

?  api_server git:(master) ? sqlite3 db.sqlite3
SQLite version 3.14.0 2016-07-26 15:17:14
Enter ".help" for usage hints.
sqlite> .tables
apis_asset                  auth_user_user_permissions
auth_group                  django_admin_log
auth_group_permissions      django_content_type
auth_permission             django_migrations
auth_user                   django_session
auth_user_groups
sqlite> select * from apis_asset;

八、数据格式详解

{
  'os_type' # 操作系统类型
  'os_distribution' # 操作系统发行版本
  'os_release' # 操作系统版本号
  'not_modify' # 本次数据跟上次比是否有变更
  'setuptime' # 系统安装时间
  'sn' # 序列号
  'manufactory' # 服务器制造商
  'productname' # 服务器产品名称 
  'model' # 服务器型号
  'cpu_count' # 物理CPU个数
  'cpu_core_count' # CPU逻辑核数
  'cpu_model' # CPU型号
  'nic_count' # 网卡个数
  'nic' # 网卡的详细参数
  'raid_adaptor_count' # raid卡控制器个数
  'raid_adaptor' # raid卡控制器详细参数
  'raid_type' # raid类型
  'physical_disk_driver' # 物理磁盘详细参数
  'ram_size' # 内存总容量
  'ram_slot' # 内存详细参数
  'certname' # Puppet的certname}

详情可以参考Github Assets_Report项目主页。

九、小结

每个公司在做资源管理系统的时候,都会开发一套这类采集工具,大家需要面对多种品牌多种型号的服务器、多种类型和版本的操作系统,使用不同的工具去解决这些复杂的问题,痛苦不堪。我们已经做过一遍这脏活累活,我们希望将其开源出来,减少一些大家的痛苦,并且希望集社区之力维护起一个通用的工具集,能够应付市面上绝大多数设备的配置自动采集需求。

另外,代码中可能有考虑不周的地方,还有一些没有考虑到的场景,还望大家不吝赐教,在Github以issue的形式指出不妥之处,欢迎提交PR。