自动化运维系统具备的功能

一个成熟的自动化运维系统至少应该包括三个子系统:

      机房设备数据系统 (EMDB)

      1.录入机房服务器和网络设备的各种信息，比如机器型号，硬盘大小，OS类型，所属应用，运行状态，机房名称，所在房间，机架，位置等等各种信息，这是一个最基础的数据库，最主要的目的是给每个机器从多个维度统一打上各种标签，方便其他系统的使用。

      2.提供各种查询API接口，并做好权限控制。目的是能够被上层的各种系统调用，一般是rest接口，xml接口。然后基于各种语言做相应的封装库。

      应用监控系统(Appmonitor) 

      1.一个统一的数据采集模块，用于采集设备运行信息，包括磁盘IO，网络流量，CPU利用率，网络设备的Session数，PPS。这个采集模块在网络设备上一般可以通过snmp来实现，在服务器上一般通过一个定制化的Agent来实现，这个Agent最基础的能力是采集服务器运行数据，最重要的是能执行各种脚本语言并通过脚本语言实现对服务器的各种操作(如更改配置，分析应用日志并输出结果)。

      2.监控数据存储与可视化，数据采集模块采集到各种数据会很多，但对事务性没啥要求，可以用各种NoSQL数据库如Hbase,Cassandra等来实现。数据的可视化是一个可以做的很深且偏应用层面的东西，一般在监控系统上只实现最基本的曲线图展示，提供按时段选择和对比的功能，其他复杂的可视化操作通过各种API来实现。

      3.监控项添加和报警通知，监控项是一种层次结构，而不是列表结构。 上层节点的配置能够被下层节点的配置覆盖掉。对网络设备来说监控项就是一些不同的oid。借助于底层的数据采集模块，对服务器来说监控项基本上就是一个脚本。可以分为标准监控项和自定义监控项，标准监控项最大化的通用，实现cpu,内存，磁盘，网络等信息的监控。自定义监控项可以用多种系统管理脚本语言(shell,python,perl)等实现，脚本的输出符合一定规范即可,一般采用行结构或json串。每个监控项设定warn,crit报警阈值和若干报警联系人，阈值一般是数值型，特殊的可以是字符串。超过阈值的监控项会发送报警给联系人，报警可以通过短信，邮件，IM软件发出。报警发送要支持合并报警，频率控制，关闭报警。要不然可能一次小故障就能发出成千上万条报警，报警就失去效果了。

      4.监控Api接口，并做好权限控制。做法和目的与EMDB一样。开放监控数据获取，报警消息发送，配置推送的接口。主要目的是让监控系统里面的数据能够被外界利用，可以在这些数据基础上做更加绚丽复杂的数据可视化工作，或者做一些更加个性化的监控和报警。次要目的是支持对服务器的统一操作，比如公司所有机器统一升级系统软件的版本。建议统一操作的API接口仅对少数几个人开放，并且权限严格控制。

      发布和线上配置管理系统(ReleaseManager)

 

      1.应用发布和依赖库版本管理，应用发布是运维与开发对接的重要环节，一般发布系统会和svn系统紧密结合，svn系统里面会有线上应用的列表，EMDB里面会有各个机器所属的应用。发布系统会用到这些数据，将svn系统里面生成的应用包及其依赖包发布到线上，并且自身对这些应用包和依赖包进行版本管理和控制，在应用发布出现问题时可以回滚到上一个版本。

      2.线上配置管理，类似于linux下puppet的功能，主要用于应用服务器上关键配置文件的版本控制，分发，一致性维护工作。大应用一般是若干台服务器组成集群提供服务，要求这若干台服务器的应用配置是一致的，但有时候又存在应用的灰度发布操作，或者某人误更改配置。线上配置管理系统要求提供统一的配置修改入口，对灰度发布提供支持，同时对于误更改配置情况进行纠正。执行操作可以借助于Appmonitor的接口。

      

       以这三个系统为基础可以做更多的自动化工作，比如说财务人员可以用EMDB里面的数据准确的计算Capex&Opex，机房管理人员可以用EMDB通过OOB远程执行各种关机，重装系统，网络设备维护等工作，不在现场也能管理机器，现场工作可以外包完成。应用开发人员可以通过svn系统调用Releasemanager自主打包，发布，回滚应用。应用维护人员可以调用监控系统获取数据和报警信息，通过编写相关脚本，实现一些简单报警的自动化处理工作，提升效率。

 

转载于:https://www.cnblogs.com/muzinan110/p/5026663.html