CN105323111A - 一种运维自动化***及方法 - Google Patents

Abstract

本发明公开了一种运维自动化***及方法，它包括数据采集模块：用于通过网管协议或者日志文件获取运维***中各个被监控单元的关键性能指标和运行状态；预处理与存储模块：对数据采集模块采集得到的数据进行预处理工作和分类存储；预测模块：根据预处理与存储模块处理之后的数据进行预测，包括CPU负载预测和磁盘负载预测；算法评价模块：建立预测模块的预测算法的评价标准，将实际值与预测算法的预测值进行对比，建立自学习过程；运维监控管理模块：负责和运维管理人员按进行交互。本发明建立负载预测机制与算法预测模型，完成针对CPU、内存、磁盘等资源使用情况的预测，结合负载预测结果，分析告警信息给出相关辅助决策，使用脚本、API接口等方式实现资源扩容、故障处理。

Description

一种运维自动化***及方法

技术领域

本发明涉及一种监控分析***，尤其是涉及一种信息***运维自动化***及方法。

背景技术

现有技术目前对各信息***及网络情况有告警监控，集团信息***主要通过信息运维综合监管平台(IMS)监控告警，服务器主机通过主机监控***进行监控告警，数据中心机房环境通过环控***进行监控告警，网络通过告警***监控告警，SAP业务***通过OCC进行监控告警，但总体各监控***还比较分散，未进行集成整合，同时也缺乏自动化的故障分析定位，故障分析和形成知识库和自定义的数据分析模型，实现对隐患、性能瓶颈和可能事件的预警。同时，集团内服务器集群规模大、结构复杂，服务器负载随时间变化，并且存储数据量随时间而积累，一旦服务器某些节点负载过重或存储空间溢出，会为整个电力***造成巨大损失。

根据运维业务现状来看，目前服务器、存储、数据库等运维不仅耗费大量人力，而且运维效率底、成本高。现阶段，传统的、被动的、孤立的、半自动式的运维管理模式经常让运维部门疲惫不堪，其问题主要表现在以下几个方面：

1)无统一的运维平台

一方面，各个运维监控平台(如信息运维综合监管平台、主机监控***等)之间相互独立工作，运维信息分散、管理不集中，各类资源没有进行整合，运维管理人员往往需要对多个平台进行监管，不仅工作量大，而且效率低下；另一方面，服务器各节点、磁盘各个分区使用情况、数据库及表的使用率等分别使用不同的监控查询机制，可视化效果差，各个监控设备的状态信息显示形式互异，不能对查询结果进行对比，更不能在全局范围内统计整个集群设备状态信息，无法实现对集群状态信息的全局掌控。

2)缺乏危险预测机制

由于运维***缺乏危险预测功能，通常运维人员需要保持24小时开机，时刻要警惕服务器安全问题的发生。如果服务器出现故障，或磁盘、数据库空间写满，而运维人员不能立刻到达现场，会对集团造成重大损失。

3)缺乏辅助决策机制

当前运维监控***只是简单扮演“监控告警”角色，当各设备的实际监测值大于所设定阈值时，进行告警。现阶段运维监控***普遍缺乏辅助决策机制，当告警、故障出现时不能有效帮助运维人员进行事务处理，提供指导参考。同时由于运维自动化水平的低下，很多简单的故障都需要运维人员手动进行处理，加大了工作负担。所以，亟需建立辅助决策机制。

为推进运检自动化管理，提升运检人员工作效率，提升运维标准化和自动化水平，实现运维工作可靠、高效和信息***的“可控、能控、在控”，进行运维自动化应用势在必行。

发明内容

本发明的目的在于克服现有技术的不足，提供一种运维自动化***及方法，以服务器集群运维为中心，建设统一运维监控管理与负载预测***，管理监控CPU、内存、磁盘、数据库表运行、使用状态信息，并设计存储与预测模型，实现整个服务器运维集群中的存储资源预测管理与计算资源分配管理。

本发明的目的是通过以下技术方案来实现的：一种运维自动化***，它包括以下功能模块：

数据采集模块：用于通过网管协议或者日志文件获取运维***中各个被监控单元的关键性能指标和运行状态，为运维数据处理、分析以及预测提供数据基础。

预处理与存储模块：对数据采集模块采集得到的数据进行清洗、过滤、补缺失处理和自动删除预处理，同时对于结构化和非结构化的数据进行数据转化和元数据提取，对于不同类别的运维数据进行分类存储。

预测模块：根据预处理与存储模块处理之后的数据，针对不同的预测方式建立不同的预测模型并进行预测，所述的预测模块包括CPU负载预测模块和磁盘负载预测模块。

算法评价模块：建立预测模块的预测算法的评价标准，将实际值与预测算法的预测值进行对比，建立自学习过程：当预测算法的预测值不满足规定误差时，根据实际值修改预测模块的预测模型参数，保证在特定环境和特定时间内选择出合适的算法模型。

运维监控管理模块：负责和运维管理人员按进行交互，其包括以下子模块：

(1)数据展示单元：将数据采集模块采集到的监控单元的数据经过预处理与存储模块的分析和加工之后，向运维管理人员进行展示。

(2)预测信息展示单元：将预测模块预测得到的CPU负载和磁盘空间使用情况的预测信息展示给运维管理人员。

(3)告警单元：监听被监控设备的状态信息，包括当前状态信息和预测状态信息，当设备某一状态数据值超过所设置的阈值时，告警模块将按提前设置好的告警方式进行告警，并且根据常见运维故障构建知识库，在做出告警信息的同时并给出辅助决策。

所述的数据采集模块采集的数据来自于集群中主机服务器、数据库、存储设备和监控设备，包括非云环境下的数据采集和云环境下的数据采集，其中，对于非云环境下的数据采集，针对不同的数据采集环境，提供集中式数据采集和分层式数据采集的框架，并且采用SYSLOG、SNMP、WEBSERVICE、JMS协议的采集方式；对于云环境下的数据采集，提供多级多域的数据采集框架，直接对云环境下的中的管理节点进行数据采集。

所述的运维监控管理模块还包括一个用户管理单元，所述的用户管理单元用于权限管理、用户信息管理、用户注册和用户登录。

所述的告警单元还包括对于有相应权限的用户提供告警级别设置、告警方式设置和告警阈值设置子模块。

一种运维自动化的方法，它包括以下步骤：

S1：数据采集，用于通过网管协议或者日志文件获取运维***中各个被监控单元的关键性能指标和运行状态，为运维数据处理、分析以及预测提供数据基础；

S2：预处理与存储，对采集得到的数据进行清洗、过滤、补缺失处理和自动删除预处理，同时对于结构化和非结构化的数据进行数据转化和元数据提取，对于不同类别的运维数据进行分类存储；

S3：预测，利用预处理后的数据，根据不同的预测方式建立不同的预测模型并进行预测，所述的预测模型包括CPU负载预测模型和磁盘负载预测模型；

S4：模型评价，建立预测模型的评价标准，将实际值与预测模型的预测值进行对比，建立自学习过程：当预测模型的预测值不满足规定误差时，根据实际值修改预测模型的预测模型参数，保证在特定环境和特定时间内选择出合适的模型；

S5：运维监控管理，负责和运维管理人员按进行交互，其包括以下子步骤：

S51：数据展示，将采集到的监控单元的数据经过预处理与存储后，向运维管理人员进行展示；

S52：预测信息展示，将预测得到的CPU负载和磁盘空间使用情况展示给运维管理人员；

S53：告警，监听被监控设备的状态信息，包括当前状态信息和预测状态信息，当设备某一状态数据值超过所设置的阈值时，告警模块将按提前设置好的告警方式进行告警，并且根据常见运维故障构建知识库，在做出告警信息的同时并给出辅助决策。

所述的磁盘负载预测模型为磁盘使用空间增长随业务量与季节的变化而变化的规律模型，其建模过程包括以下子步骤：

S311：建立基于时间序列的线性季节性增长模型，公式如下：

y_t＝(a+bt)+S_t+I_t；

式中，y_t为磁盘空间使用量，t为时间，S_t为季节变化，I_t为新增业务上线，a与b均为常数；

S312：确定步骤S311中的模型的输入值，包括以下子步骤：

A：根据预处理与存储，获取服务器磁盘空间的已用空间、增长量、磁盘剩余空间；

B：通过增长量变化率即平均日增长量增量Δt'计算得出季节变化S_t：设日增长量为Δt，平均日增长量增量为Δt'＝Δt₁-Δt₂，S_t即为平均日增长量增量Δt'在[t₁,t₂]时间段内的积分值，即

$S_t={\∫}_{t_1}^{t_2}{\mathrm{\Δt}}^{\′}{\mathrm{d\Δt}}^{\′};$

C：新增业务上线I_t与用户使用量u相关，用户使用量u由每日业务点击量计量，经业务数据与磁盘存储之间的关系计算，获得新增业务上线I_t；

D：通过平均日增长量Δt'计算得出a与b，a与b的值为线性增长；

S313：根据步骤S312获得的磁盘空间使用量y_t的数据输入值带入步骤S311中的增长模型，经过计算得到磁盘使用空间值y_t；

S314：根据步骤S313得到的磁盘使用空间值y_t，进行反解获得告警时间，并发送至运维监控管理模块；当运维监控管理模块得到数据之后，通知运维监控人员进行磁盘容量扩充或磁盘信息整理。

所述的CPU负载预测模型包括基于模式的预测算法模型，其建模过程包括以下子步骤：

S321：获取经过预处理之后提取出来的CPU运行状态信息和CPU自身性能信息的CPU负载历史数据，并且计算出各个时间节点上的CPU负载Load_cpu，公式如下：

${\mathrm{Load}}_{cpu}=\frac{used\_cpu}{all\_cpu},$

式中，used_cpu表示已使用的CPU，all_cpu表示总共的CPU，二者均以百万条指令每秒MIPS为单位；

S322：对输入的CPU负载历史数据进行计算预处理，并计算CPU负载在每个时间节点上的变化率CR，公式如下：

$CR\left(t_i\right)=\frac{V_{t_i}-V_{t_{i-1}}}{V_{t_{i-1}}}*100\%;$

式中，为t_i时刻的CPU负载数值，i＝0,1,2,...，n；

S323：选取当前模式匹配长度L，构造CPU负载历史数据及当前负载模式、CPU负载的变化率及当前的变化率模式；

S324：对输入的CPU负载历史数据进行分段，段数为N，逐段计算相似性程度，包括以下子步骤：

S3241：令变量i的值为0；

S3242：判断i的值是否比N小的条件是否符合：

(1)如果条件不符合进入步骤S325；

(2)如果条件符合，包括以下子步骤：

A：计算SD_CR(t_i)和SD_CPU(t_i)，其中SD_CR(t_i)表示在CPU历史记录数据中从t_i-L到t_i这段时间中记录的CPU负载的标准差，SD_CPU(t_i)为当前模式记录的CPU负载的标准差；

B：判断以下两个条件中的至少一项是否成立，如果成立则进入步骤S3243，如果不成立则对i的值进行加1操作之后返回步骤S3242：

条件1：SD_CPU(t_i)≤SD_{CPU_THRESHOLD}；

条件2：SD_CPU(t_i)≤SD_{CPU_TOLERANCE}并且SD_CR(t_i)≤SD_{CR_THRESHOLD}

式中，SD_{CPU_THRESHOLD}表示相似模式标准的最大CPU负载标准方差，SD_{CPU_TOLERANCE}表示CPU负载标准方差的宽限值，SD_{CR_THRESHOLD}表示相似模式标准的最大CPU负载变化率标准方差；

S3243：将t_i处的SD_CR(t_i)和SD_CPU(t_i)加入相似模式集合Q中；

S325：将集合Q中的相似模式按距离当前模式时间的远近进行排序，并赋予不同权值；

S326：将不同权重的相似模式的截止时间点t_i点及其对应权重保存在集合P中，公式如下：

$P_{CPU}\left(t_0\right)=\underset{i=1}{\overset{n}{\Σ}}{\mathrm{\α}}_i*P_{CPU}\left(t_i\right),$

式中，P_CPU(t_i)表示距当前模式第i个CPU负载模式，i＝0,1,2,...，n；i越大表示离当前模式的时间越远，α_i表示相似模式i的权重；P_CPU(t₀)表示当前CPU负载模式；

S327：遍历集合P，计算各个预测值，比较得到最终预测值；

S328：将得到的一系列CPU负载预测值在运维监控管理模块上显示，以时间点为横坐标、负载百分比为纵坐标描绘CPU负载-时间预测图，将未来一段时间内CPU的负载趋势用曲线图来表示；同时将图中超过指定CPU负载阈值的信息(发生时间、负载值)以告警的方式发送给***和监控人员，提醒采取措施。

所述的辅助决策的具体过程是，综合负载预测的结果，对于低级别的故障及告警，采用默认处理方式或者采用用户自行选择的***提供的处理方式；对于高级别的故障及告警，直接通知用户，由用户决定处理方式。

所述的数据采集包括以下采集方式：

(1)周期性数据采集：是指主动节点简单地、周期性从网络设备中获取需要数据的方法，周期性数据采集针对不同的数据粒度设定相应的采集周期；

(2)异常数据采集：是指网络设备运行过程中某些运行状态指标出现异动或者是***出现异常时，主动节点将异常数据传送到网络监控中心；

(3)主动式数据采集：为了完成在网络管理的日常事务中管理员特定的网络监控任务，根据一定的数据采集目的直接对特定数据进行采集。

数据采集方式的转换包括以下子步骤：

S11：设定主动节点的采样周期t，即每隔t秒主动节点就会对网络运行状态进行采样；

S12：用批量设定的方式为每一个监控对象设定一个数据采集周期T，数据采集周期T应该大于主动节点的采样周期t，采集周期值等于采集周期内采样周期值的平均值；每隔T秒主动节点就将网络运行状态数据上报网络监控中；

S13：针对特定的网络性能数据设定监控规则和阈值，每隔一个采样周期t秒就会根据规则计算一次网络性能状态，若超过阈值主动节点就将网络运行状态数据上报网络监控中心；

S14：当网络特定性能的运行状态出现异常时，针对该特定性能的数据采集方式转变为主动数据采集方式，停止当前的周期性数据采集和异常数据采集，将网络特定性能的实时运行状态详细信息发送给监控中心；

S15：当网络监控人员主动观察某项网络性能指标时，针对该特定性能的数据采集方式转变为主动数据采集方式；当网络监控人员退出主动观察某项网络性能指标时，针对该特定性能的数据采集方式转变为周期性数据采集方式。

所述的数据采集模块采集的数据来自于集群中主机服务器、数据库、存储设备、监控设备；数据采集模块的采集包括非云环境下的数据采集和云环境下的数据采集；

其中，对于非云环境下的数据采集，针对不同的数据采集环境，提供集中式数据采集和分层式数据采集的框架，并且采用SYSLOG、SNMP、WEBSERVICE、JMS协议的采集方式；对于云环境下的数据采集，提供多级多域的数据采集框架，直接对云环境下的中的管理节点进行数据采集。

采用所述SYSLOG协议时，代理进程驻留在网络节点计算机上，当发现被管理设备的运行状态发生变化，主动及时向管理程序报告发生的事件。同时，UNIX/LINUX***的***日志通过syslogd进程来记录***相关的事件和应用程序的运行事件日志，通过分析所述运行事件日志，进行设备及网络的运行状况的监控。

本发明的有益效果是：

(1)统一化资源管理平台，多维度展示数据信息，便于运维人员查看设备、资源状态，改善运维难度。

(2)预测服务器运转高峰、磁盘、数据库写满，提前做好防范措施，降低运维服务器风险。

(3)规范化运维管理，运维人员任务分工明确，权限设置。

(4)实现运维自动巡检，减轻运维人员负担。

(5)建立负载预测机制与算法预测模型，完成针对CPU、内存、磁盘等资源使用情况的预测。

(6)辅助决策，结合负载预测结果，分析告警信息给出相关辅助决策，使用脚本、API接口等方式实现资源扩容、故障处理。通过与ITSM***集成，建立关联问题知识库，给运维人员提供解决方案。

附图说明

图1为本发明结构框图；

图2为磁盘监控输入字段示意图；

图3为时间序列季节型增长模型数据流程图；

图4为基于模式的CPU负载预测算法流程图。

具体实施方式

下面结合附图进一步详细描述本发明的技术方案：如图1所示，一种运维自动化***，它包括：

数据采集模块：用于通过网管协议或者日志文件获取运维***中各个被监控单元的关键性能指标和运行状态，为运维数据处理、分析以及预测提供数据基础；

运维***中，运维监控所需的数据主要来自于集群中主机服务器、数据库、存储设备、应用***以及其他相关网络设备及***。数据采集就是通过某种网管协议(Syslog、SNMP、Telnet等)或者日志文件获取运维***中各个被监控单元的KPI(关键性能指标)和运行状态信息，为运维数据处理、分析以及预测提供数据基础。此次实施会充分利用已有***采集数据进行预防管控。

监控的***主要包括OCC、主机监控***、IMS、环境监控***。

数据采集的环境既有云环境，也有非云环境。无论在哪种环境下，数据采集都需要实现主机服务器信息采集、数据库信息采集以及其他监控设备的采集功能。但是在云环境中，需要更加关注整个云集群的负载、用户使用空间、虚拟机配置等信息。

(1)非云环境下数据采集

数据采集将依据具体采集设备的特性而选择合适的采集方式。在本项目中，采集方式可以选择SNMP、JMX等协议，这样克服了传统的数据采集的缺点(如，许多传统数据采集多采用CentralServer+Agent的集中式体系结构，这种体系结构必须要在***中的每台设备上安装和部署Agent，当服务器较多时效率低下)。同时针对不同的数据采集环境，数据采集模块将提供集中式数据采集和分层式数据采集等框架，完成数据的高效采集。

(2)云环境下数据采集

针对云环境下数据分布式存储的特点以及集群中往往存在着一台或多台集中管理各个子节点的管理节点，云环境下数据采集将直接与管理节点进行数据传输。针对云集群中电力运维***具有树形、多级、分布等多种特点，采用多级多域的数据采集框架完成数据快速采集。

本发明中，网络设备分为主动网络设备和非主动网络设备。主动网络设备是指具有节点操作***和执行环境，并可以运行主动代码来完成监控任务的主动节点。传统的网络设备被动地接收信息轮询和管理，而是主动网络设备能够主动管理设备。例如，定期报告网络运行状态、主动监测网络异常事件、主动执行网络监控任务等等。

本发明在数据采集实现过程中将三种基本数据采集方法(周期性数据采集、异常数据采集、主动式数据采集)以主动服务的形式部署在主动节点中，通过执行主动代码来切换三种基本数据采集方法，从而实现一种高效策略的数据采集方法。

所述的数据采集模块的数据采集方法包括：

(1)周期性数据采集：是指主动节点简单地、周期性从网络设备中获取需要数据的方法，周期性数据采集针对不同的数据粒度设定相应的采集周期；

(2)异常数据采集：是指网络设备运行过程中某些运行状态指标出现异动或者是***出现异常时，主动节点将异常数据传送到网络监控中心；

(3)主动式数据采集：为了完成在网络管理的日常事务中管理员特定的网络监控任务，根据一定的数据采集目的直接对特定数据进行采集；

数据采集方法的转换包括以下子步骤：

S31：设定主动节点的采样周期t，即每隔t秒主动节点就会对网络运行状态进行采样；

S32：用批量设定的方式为每一个监控对象设定一个数据采集周期T，数据采集周期T应该大于主动节点的采样周期t，采集周期值等于采集周期内采样周期值的平均值；每隔T秒主动节点就将网络运行状态数据上报网络监控中；

S33：针对特定的网络性能数据设定监控规则和阈值，每隔一个采样周期t秒就会根据规则计算一次网络性能状态，若超过阈值主动节点就将网络运行状态数据上报网络监控中心；

S34：当网络特定性能的运行状态出现异常时，针对该特定性能的数据采集方式转变为主动数据采集方式，停止当前的周期性数据采集和异常数据采集，将网络特定性能的实时运行状态详细信息发送给监控中心；

S35：当网络监控人员主动观察某项网络性能指标时，针对该特定性能的数据采集方式转变为主动数据采集方式；当网络监控人员退出主动观察某项网络性能指标时，针对该特定性能的数据采集方式转变为周期性数据采集方式。

数据采集模块的接口包括：

主机性能指标数据同步接口，采用ActiveMQ中间件作为JMS消息机制的消息队列容器。主机监控***作为JMS消息机制的消息发送方向ActiveMQ中间件的IMS.RawFirmConf队列写入主机性能数据，运维自动化***作为JMS消息机制的消息消费方向ActiveMQ中间件的IMS.RawFirmConf队列取出主机性能数据。以此方式完成主机性能指标数据的同步。

数据库性能指标数据同步接口，采用ActiveMQ中间件作为JMS消息机制的消息队列容器。主机监控***作为JMS消息机制的消息发送方向ActiveMQ中间件的IMS.RawValuePerf队列写入数据库性能数据，运维自动化***作为JMS消息机制的消息消费方向ActiveMQ中间件的IMS.RawValuePerf队列取出数据库性能数据。以此方式完成数据库性能指标数据的同步。

主机配置数据同步接口，采用ActiveMQ中间件作为JMS消息机制的消息队列容器。主机监控***作为JMS消息机制的消息发送方对ActiveMQ中间件的IMS.RawConf队列写入主机配置数据，运维自动化***作为JMS消息机制的消息消费方向ActiveMQ中间件的IMS.RawConf队列取出主机配置性能数据。以此方式完成主机配置数据的同步。

数据库配置数据同步接口，采用ActiveMQ中间件作为JMS消息机制的消息队列容器。主机监控***作为JMS消息机制的消息发送方对ActiveMQ中间件的IMS.RawConf队列写入数据库配置数据，运维自动化***作为JMS消息机制的消息消费方向ActiveMQ中间件的IMS.RawConf队列取出数据库配置性能数据。以此方式完成数据库配置数据的同步。

环控指标数据同步接口，实现从运维自动化***向环境监控***获取环境指标数据功能。以此方式完成环控指标数据的同步。

环控配置数据同步接口，实现从运维自动化***向环境监控***获取环境配置数据功能。以此方式完成环控配置数据的同步。

预处理与存储模块：对数据采集模块采集得到的数据进行清洗、过滤、补缺失的预处理工作，同时对于各种结构化、非结构化的数据完成数据转化和元数据的提取，之后对于不同类别的运维数据进行分类存储。数据主要存储在MongoDb、Oracle、MySql里面。

来自于运维***中各个被监控设备的数据存在着数据格式不统一、数据冗余、信息不完整以及很多“垃圾”信息(与负载预测无关的数据)等问题。这些“问题”将给后续数据存储、分析以及预测带来严重的影响。所以在数据进行存储、分析之前需要对数据进行清洗、过滤、补缺失等预处理工作。同时，对于各种结构化、非结构数据需要采取XML等技术完成数据转化以及元数据的提取。

在负载预测过程中，分析数据主要来自于历史上各个时期负载使用情况信息，这些数据信息随着时间推移数据量越来越大，所以需要建立一个安全、稳定、高速存取、可扩展性强的存储机制，保证各类运维数据能够分类存储。

预测模块：根据预处理与存储模块处理之后的数据，针对不同的预测方式建立不同的预测模型，进行预测，包括CPU负载预测和磁盘负载预测。对于CPU包括趋势预测、AR和模式匹配。

预测模块为整个***的核心部分，预测算法的处理效率以及预测结果的正确率直接决定整个***的性能，并影响运维监控的辅助决策。本项目中处理的数据对象是整个电力运维中的服务器集群及集群中的计算资源和存储资源。整个运维***中资源(CPU、内存、磁盘空间等)使用情况的预测是基于运维统计数据，预测算法所处理的数据不仅是现阶段采集到的数据，还包括历史各个时刻的运维数据。

整个运维预测数据来源于***架构中的数据采集模块以及数据预处理与存储模块，数据经过预测算法处理后得到最终预测结果，该结果为后续辅助决策提供依据。

处理流程可以简单的描述为：***将采集到的各个多源异构资源经过数据预处理以及元数据提取、数据整合等处理将其传输至存储模块(该模块需要建立，具备分布式存储以及并行化运算特点)，然后该模块负责向CPU、内存负载预测模块以及磁盘空间预测模块提供输入数据，数据经过这两个预测模块处理后得到预测值，预测值以告警的方式发送给运维管理监控人员，指出***相关资源(内存、CPU、磁盘)将在何时超过危险阈值，同时为方便运维监控人员对CPU、内存的监控，还将对其提供CPU、内存的负载预测走势图。

为减轻运维人员故障处理频率，构建辅助决策机制，对运维预测结果进行分析，针对不同的故障、设备状况，***将使用脚本、API接口等方式自动完成事务处理，实现运维自动化处理流程。

随着服务器的运行，服务器磁盘空间使用率也在不断增长，特别是作为存储应用的服务器，比如数据库服务器或者文件服务器等，一旦磁盘写满，便会引起***功能失效，数据无法存储，从而造成严重的后果。虽然现有的运维监控***中已有查看磁盘使用率，并设置使用率阀值警告，但达到预设值发生告警通知运维***人员仍然会感到措手不及。因此本发明通过对运维历史信息、对磁盘使用量进行估算，预测磁盘空间达到阀值的时间并通知运维人员，利于运维人员提前采取措施，增加运维缓冲时间。

时间序列预测法通过编制和分析时间序列，根据时间序列反映出来的发展过程、方向和趋势，进行类推或延伸，借以预测下一段时间或以后若干时间内能够达到的水平。本模型则根据磁盘使用空间增长随业务量与季节的变化而变化的规律，得到一定模式，以此模式预测该磁盘空间将来时间内何时达到告警阈值。

时间序列预测法是根据过去的变化趋势预测未来的发展，它的前提是假定事物的过去会延续到未来。时间序列分析正是根据客观事物发展的连续规律性，运用过去的历史数据，通过统计分析，进一步推测未来的发展趋势。

磁盘预测包括一元线性拟合、一元非线性拟合、线性加权、二次拟合、三次拟合等算法，其中：

一元线性拟合：获取多个(时间t，使用率u)序列，根据最小二乘法计算线性回归方程的两个系数，得到线性回归方程，并依据此方程，对未来的使用率进行预测。注意到***输入的时间是日期格式，无法直接代入计算。因此将预测的起始时间设为0，后续的时间依据指定步长转换成整数。预测时也是将时间做同样的处理，输出的时候再还原。

一元非线性拟合：先对输入时间做6种不同的线性转换，把非线性的关系转换成线性关系，再调用线性计算方法，计算每种非线性函数的拟合精度，选择拟合效果最好的作为最终的拟合方程，进行预测。

如图3所示，所述的磁盘负载预测的预测模型包括根据磁盘使用空间增长随业务量与季节的变化而变化的规律得到的模型，得到模型的步骤具体包括：

S11：建立基于时间序列的线性季节性增长模型，公式如下：

y_t＝(a+bt)+S_t+I_t；

式中，y_t为磁盘空间使用量，t为时间，S_t为季节变化，I_t为新增业务上线，a与b均为常数；

磁盘使用空间为正增长趋势，并且无特殊情况，如季节变化、新业务上线等因素的影响，趋于线性增长。

但模型的关键在于S_t与I_t的变化。

S12：确定步骤S11中的模型的输入值，包括以下子步骤：

S121：根据预处理与存储模块，获取服务器磁盘空间的已用空间、增长量、磁盘剩余空间，如图2所示；

S122：通过增长量变化率即平均日增长量增量Δt'计算得出季节变化S_t：设日增长量为Δt，平均日增长量增量为Δt'＝Δt₁-Δt₂，S_t即为平均日增长量增量Δt'在[t₁,t₂]时间段内的积分值，即

$S_t={\∫}_{t_1}^{t_2}{\mathrm{\Δt}}^{\′}{\mathrm{d\Δt}}^{\′};$

S123：新增业务上线I_t与用户使用量u相关，用户使用量u由每日业务点击量计量，经业务数据与磁盘存储之间的关系计算，获得新增业务上线I_t；

S124：通过平均日增长量Δt'计算得出a与b，a与b的值为线性增长；

S13：根据步骤S12获得的磁盘空间使用量y_t的数据输入值带入步骤S11中的增长模型，经过计算得到磁盘使用空间值y_t；

S14：根据步骤S13得到的磁盘使用空间值y_t，进行反解获得告警时间，并发送至运维监控管理模块；当运维监控管理模块得到数据之后，通知运维监控人员进行磁盘容量扩充或磁盘信息整理。

具体地，清理数据库采用清理数据库数据模块：接受一个int型参数t，将当前时间减去t，获得时间点t1，删除指定表中TIME值小于t1的所有纪录。

CPU负载的预测模型往往是是基于如下假设：CPU负载的波形模式(Pattern)会重复出现。这些重复出现的模式分为周期性模式和非周期性模式：

(1)周期性模式：该模式会在CPU负载的波形中以一定的时间间隔重复出现。

(2)非周期性模式：非周期性模式的出现，没有一定的规律，即没有固定的时间间隔。但是如果CPU负载的某一段波形与该模式起始段的波形相似，那么接下来的CPU负载数值与该模式中接下来的数值也会同样相似。因此可根据该模式来预测接下来的CPU负载。

基于模式的预测算法也是基于同样的假设：CPU负载中出现过的模式会重复出现，即CPU负载当前的模式在过去时间里曾经出现过。而该算法就是找出这个曾出现过的模式，以此来预测接下来的数值。具体思路如下：

(1)构建当前的CPU负载匹配模式：假设当前时间为t0，那么从t0-L到t0时段内的数值构成当前的CPU负载匹配模式，其中L为当前匹配模式的长度。

(2)检测出之前的相似模式：将当前的CPU负载匹配模式与之前的CPU负载数值一一对比，在一定的误差允许范围内，若有某一段长度为L的CPU负载符合要求，即可认为该段CPU负载为曾出现过的相似模式。本算法中采用标准方差(StandardDeviation，SD)作为标准来判断两种模式是否相似。

(3)计算预测值：相似模式接下来的CPU负载数值就是要预测的数值，可以直接一一复制过去当作预测值，或者乘以一定的权重计算而得到预测值。在本算法，采取两种不同的方法来获取预测值，即基于最相似模式以及基于不同权重的模式的两种算法

如图4所示，所述的CPU负载预测的预测模型包括基于模式的预测算法模型，得到模型的步骤具体包括：

S21：获取预处理与存储模块中经过预处理之后提取出来的CPU运行状态信息、CPU自身性能信息的CPU负载历史数据，并且计算出各个时间节点上的CPU负载Load_cpu，公式如下：

${\mathrm{Load}}_{cpu}=\frac{used\_cpu}{all\_cpu},$

式中，used_cpu表示已使用的CPU，all_cpu表示总共的CPU，二者均以百万条指令每秒MIPS为单位；

S22：对输入的CPU负载历史数据进行计算预处理，并计算CPU负载在每个时间节点上的变化率CR，公式如下：

$CR\left(t_i\right)=\frac{V_{t_i}-V_{t_{i-1}}}{V_{t_{i-1}}}*100\%;$

式中，为t_i时刻的CPU负载数值，i＝0,1,2,...，n；

S23：选取当前模式匹配长度L，构造CPU负载历史数据及当前负载模式、CPU负载的变化率及当前的变化率模式；

S24：对输入的CPU负载历史数据进行分段，段数为N，逐段计算相似性程度，包括以下子步骤：

S241：令变量i的值为0；

S242：判断i的值是否比N小的条件是否符合：

(1)如果条件不符合进入步骤S25；

(2)如果条件符合，包括以下子步骤：

S2421：计算SD_CR(t_i)和SD_CPU(t_i)，其中SD_CR(t_i)表示在CPU历史记录数据中从t_i-L到t_i这段时间中记录的CPU负载的标准差，SD_CPU(t_i)为当前模式记录的CPU负载的标准差；

S2422：判断以下两个条件中的至少一项是否成立，如果成立则进入步骤S243，如果不成立则对i的值进行加1操作之后返回步骤S242：

条件1：SD_CPU(t_i)≤SD_{CPU_THRESHOLD}；

条件2：SD_CPU(t_i)≤SD_{CPU_TOLERANCE}并且SD_CR(t_i)≤SD_{CR_THRESHOLD}

式中，SD_{CPU_THRESHOLD}表示相似模式标准的最大CPU负载标准方差，SD_{CPU_TOLERANCE}表示CPU负载标准方差的宽限值，SD_{CR_THRESHOLD}表示相似模式标准的最大CPU负载变化率标准方差；

S243：将t_i处的SD_CR(t_i)和SD_CPU(t_i)加入相似模式集合Q中；

S25：将集合Q中的相似模式按距离当前模式时间的远近进行排序，并赋予不同权值；

S26：将不同权重的相似模式的截止时间点t_i点及其对应权重保存在集合P中，公式如下：

$P_{CPU}\left(t_0\right)=\underset{i=1}{\overset{n}{\Σ}}{\mathrm{\α}}_i*P_{CPU}\left(t_i\right),$

式中，P_CPU(t_i)表示距当前模式第i个CPU负载模式，i＝0,1,2,...，n；i越大表示离当前模式的时间越远，α_i表示相似模式i的权重；P_CPU(t₀)表示当前CPU负载模式；

S27：遍历集合P，计算各个预测值，比较得到最终预测值；

S28：将得到的一系列CPU负载预测值在运维监控管理模块上显示，以时间点为横坐标、负载百分比为纵坐标描绘CPU负载-时间预测图，将未来一段时间内CPU的负载趋势用曲线图来表示；同时将图中超过指定CPU负载阈值的信息(发生时间、负载值)以告警的方式发送给***和监控人员，提醒采取措施。

整个CPU负载预测模块从数据输入到输出一共包括5个部分：数据输入、构建匹配模式、查找相似模式、计算预测值以及输出处理。

算法设计中，通过对采集到的历史CPU数据进行挖掘分析，统计历史上一段时间中的CPU负载特征，并分析历史上隔段时间的CPU负载特征，在这些特征中找到和当前CPU模式相匹配的特征，并将这些特征所对应的历史时间点作为当前CPU负载的可能重现的时间点。然后采用不同权重的方式计算出最佳相似点，并以此作为当前的预测。

分析整个流程各部分功能为：

(1)数据输入：该部分数据主要来自本方案自行设计创建的分布式存储***，而存储在该***中的数据主要包括运维***的相关监控信息，这部分数据类型繁多且数据量巨大，存储采用增量的方式进行，需要保存的数据既有采集到的来自于各个主机服务器记录的***运行时的日志信息，也包括用户访问服务器的web记录等。该部分数据在进入CPU预测算法之前还需要进行预处理，提取出CPU运行状态信息以及CPU自身性能信息，并在此基础上得到各历史时间点上的CPU负载信息。如步骤S21。

(2)构建匹配模式：主要是对CPU负载历史信息进行相应预处理得到CPU负载的历史数据及其当前的负载模式、CPU负载的变化率及其当前的变化率模式，为后面查找相似模式奠定基础。如步骤S22。

(3)查找相似模式：创建于当前模式相似的集合，集合中的元素由相似模式的权重以及其对应的时间点组成。如步骤S23～S26。

(4)计算预测值：该部分得到当前阶段CPU的预测值。如步骤S27。

(5)输出处理：将得到的一系列CPU负载预测值以时间点为横坐标、负载百分比为纵坐标描绘CPU负载-时间预测图，将未来一段时间内CPU的负载趋势用曲线图来表示，这样方便运维监控人员对集群***的监控，同时将图中超过指定CPU负载阈值的信息(发生时间、负载值)以告警的方式发送给***和监控人员，提醒其实现采取措施。如步骤S28。

算法评价模块：建立预测模块的预测算法的评价标准，将实际值与预测算法的预测值进行对比，建立自学习过程：当预测算法的预测值不满足规定误差时，根据实际值修改预测模块的预测模型参数，保证在特定环境和特定时间内选择出合适的算法模型；

运维监控管理模块：负责和运维管理人员按进行交互，包括：

(1)数据展示单元：将数据采集模块采集到的监控单元的数据经过预处理与存储模块的分析和加工之后，向运维管理人员进行展示；

(2)预测信息展示单元：将预测模块预测得到的CPU、磁盘空间使用情况的预测信息展示给运维管理人员；

(3)告警单元：监听被监控设备的状态信息，包括当前状态信息和预测状态信息，当设备某一状态数据值超过所设置的阈值时，告警模块将按提前设置好的告警方式(短信、邮件、电话)进行告警；并且根据常见运维故障构建知识库，在做出告警信息的同时并给出辅助决策。

具体地，告警单元实现通过设置告警阈值以及告警方式向用户传递告警方式。告警方式包括：邮件、短信、电话。告警涵盖实时监控指标告警(实时监控的CPU、内存、磁盘以及环境监控和OCC监控信息)、预测监控信息告警(CPU、内存、磁盘信息)。当监控指标(实时值、预测值)大于所设置的阈值时，将进行告警，采用方式以用户配置为准(邮件、短信、电话)，会将告警信息发给当天值班人员。

告警单元的接口包括：

主机告警信息同步接口，采用ActiveMQ中间件作为JMS消息机制的消息队列容器。主机监控***作为JMS消息机制的消息发送方对ActiveMQ中间件的host_alert队列写入主机告警信息，运维自动化***作为JMS消息机制的消息消费方向ActiveMQ中间件的host_alert队列取出主机告警数据。以此方式完成主机告警信息的同步。

OCC告警信息同步接口，运维自动化***在服务启动的时候开启SNMPTrap服务，监听在指定主机A的2015号端口，等待OCC监控***向主机A的2015号端口发送告警信息。以此方式完成OCC告警信息的同步。

环控告警信息同步接口，实现从运维自动化***向环境监控***获取环境配置数据功能。以此方式完成环控告警信息的同步。

所述的运维监控管理模块还包括一个用户管理单元，所述的用户管理单元用于权限管理、用户信息管理、用户注册和用户登录。

用户管理主要包括：权限管理、用户信息管理以及用户注册、登陆等。

1)权限管理

针对管理员用户，对其他普通用户进行权限分配，通过权限设置，明确运维监管中不同人员的职责和操作功能以及运维管理中负责管理的设备对象，提高运维效率。

2)用户信息管理

一是允许用户对自身信息(如，用户名、密码等)进行查看、修改；二是允许管理员用户对普通用户的相关信息进行查看、修改，允许管理员用户对用户信息进行审核，防止出现错误、虚假信息。

3)用户日志管理

管理员可根据需要设置用户操作信息日志记录开关，并对日志进行查询和删除操作，便于查询故障和分析问题。通过对用户操作日志查看与检查，为事后故障分析，查处非法操作提供基础。

4)用户登录、注册

包括两方面功能：一是，管理员可以查看用户登录信息、状态信息(在线、审核、离线等)，审核用户注册信息。通过用户登录、注册管理实现对整个监控***中运维人员的运维状态进行管理。二是，普通用户和管理员用户均可以通过登录界面进行***，获取相关功能，同时新用户可以采用注册界面向管理员提交注册申请，当审批后即可获取相应权限与操作功能。

所述的告警单元对于有相应权限的用户提供告警级别设置、告警方式设置、告警阈值设置。

1)告警级别设置

针对于每一个被监控设备，***都具有相应的默认告警级别。同时，具有相应权限的用户可以通过运维监控展示平台软件设置所监控设备的告警级别。***将赋予用户更加灵活的告警级别设置功能。告警级别可以分为以下五个级别：

致命错误(FATAL)：严重的错误事件将会导致应用程序的退出。

错误异常(ERROR)：虽然发生错误事件，但仍然不影响***的继续运行。

警告(WARN)：会出现潜在错误的情形。

信息(INFO)：在粗粒度级别上突出强调应用程序的运行过程。

调试(DEBUG)：细粒度信息事件对调试应用程序有一定的帮助。

2)告警方式设置

***向用户提供邮件、***消息、短信等多种告警方式。***具有默认的告警方式，同样具有相应权限的用户也可以“定制”属于自己的告警方式。

3)告警阈值设置

针对每一个被监控设备，***都具有默认的参数阈值设定，同时，监控用户根据自己的权限可以对相应设备参数阈值进行设定。

数据展示单元主要实现CPU、内存、磁盘等设备的状态信息显示与统计，向用户展示整个运维监控管理***中所有设备的运行状态，方便运维人员实现监控管理。

1)磁盘分区查询

查看磁盘分区名、区空间、区可用空间、已用空间，并可用条状图、饼状图表示各数据。磁盘可用空间少于设定阈值的磁盘信息图形用红色进行区别。查询信息既可是当前磁盘分区信息，也可是历史上某一时刻磁盘分区信息。

2)磁盘容量查询

对磁盘分区的详细信息进行查看，可查看磁盘分区每天的使用量(即增长量)、日期、历史使用空间变化情况、文件***使用情况，并用图表展示，可宏观观测磁盘使用空间增长量、剩余空间大小等信息。既可对某一单独磁盘容量进行查询，也可以是对某一主机、服务器或是集群总体磁盘容量进行查询统计。

3)磁盘I/O统计

查看磁盘分区名称、磁盘读/写类型、当前流量，便于观察磁盘负荷状况。

4)数据库空间查询

通常数据库、数据表有空间限制，当数据表写满后，无法进行数据录入。***提供数据库接口，对后台数据库空间、数据表空间进行查看。并且可以通过告警模块设置容量阈值。

5)CPU、内存使用率查看

提供查看每个CPU使用率变化曲线功能，包括用户态、内核态、IOWait等，不同数据用不同颜色的线表示，当高于设定值时用颜色进行区别。查看时刻(时间段)既可是历史上的记录，也可以是当前时刻(时间段)。

6)CPU、内存状态查看

查看每个CPU、内存是否运转正常，是否发生错误等。查看时刻(时间段)既可是历史上的记录，也可以是当前时刻(时间段)。

7)统计与对比功能

统计功能：同一(类)设备某一时间段运行状态的统计，展现方式包括图形、表格等。

对比功能：同一设备不同时刻(时间段)运行状态对比，或同一类设备之间同一时刻(时间段)运行状态对比，展现方式包括图形、表格等。

所述的辅助决策与负载预测模块的预测结果进行结合，并且：(1)对于低级别的故障及告警，***自动采用默认处理方式或者采用用户自行选择的***提供的处理方式；(2)对于高级别的故障及告警，***直接通知用户，由用户决定处理方式；使用脚本或者API接口。

具体地：

1)针对运维监控常见故障及解决方法，构建运维监控问题知识库，当告警、故障发生时，向运维人员提供解决方法和建议。

2)构建辅助决策机制，与负载预测机制结合，分析负载预测结果、告警信息，针对不同故障、场景建立不同的辅助决策机制，使用脚本、API接口等方式故障处理。具体来说：

(1)针对每一种常见故障及报警，***有默认处理机制，如：

发现磁盘要满，***自动实现删除垃圾文件和扩容功能；

当CPU、内存利用率过高时，杀死“无效”进程；

当某一服务器节点剩余存储空间不足，而其他节点存储空间却充足时，实现资源迁移，达到存储负载平衡。

(2)针对每一种常见故障及报警，***向用户提供多种处理机制，用户可以选择默认处理机制。

(3)对于级别较高的报警及故障，***不会进入默认处理机制，将通知用户，由用户决定处理机制。

采用所述SNMP协议：代理进程驻留在网络节点计算机上，当发现被管理设备的运行状态发生变化，主动及时向管理程序报告发生的事件；采用所述SYSLOG协议：UNIX/LINUX***的***日志通过syslogd进程来记录***相关的事件和应用程序的运行事件日志，通过分析所述运行事件日志，进行设备及网络的运行状况的监控；采用所述WMI协议：访问、配置、管理和监视Windows资源，用于获取远程计算机的Window事件日志。

其中对于SYSLOG：

在服务器中的配置用于接收来自所有根据syslog协议传送***日志主机的***日志，并规定日志的格式，规定格式是为了方便自动化运维***进行日志解析入库。比如接收来自upd的模块和支持tcp的模块传来的日志。

在windows和lunux***下的syslog客户端，需要将windows日志和lunux日志转化为syslog协议支持的日志之后，再向服务器进行发送。

本发明的功能特点在于：

1)完成针对CPU、内存、磁盘的负载使用情况的预测，预测方式包括长期预测与短期预测；

2)构建预测算法库，库中包括多种预测算法，算法库具有以下特点：

(1)针对于每一种待预测设备(如CPU)有多种可供用户选择的预测算法，***同时具备默认预测算法。

(2)库中算法所涉及的相关参数(如阈值)可供用户进行实际选择调整，也可以采取自适应方法自动进行参数调整，或者采用默认值，至于采用何种方式，用户能进行选择。

3)构建算法评价模型，制定算法评价标准和策略，针对算法库中每一种算法都有相应算法准确率、速率的评价方法。通过算法评价模型向用户展示每一种算法实际准确率、速率，并统计其各个时间段的准确率和速率情况。采用图形、表格完成同一算法在不同时间段准确率和速率的对比展示，以及不同算法在同一时间段准确率和速率的对比展示。

4)向用户提供全方位的预测功能，用户可以“定制化”自己的监控设备、预测算法、评价模型等，极大的提供运维灵活性：

(1)用户可以手动添加或删除需要进行负载预测的设备，同一用户可以选择多个设备进行监控，观测其负载预测值。用户所监控的设备既可以是同一类型的多种设备，也可是不同类型的多种设备。

(2)对于每一个被监控设备用户可以：选择预测方式(长期预测、短期预测)，可以指定预测时间段(分、小时、天)，选取预测算法库中指定的预测算法，可以对所选择算法进行相关参数设置，可以设置告警方式和告警阈值，可以查看算法评价结果(可以指定与其他算法的预测准确率、速率对比)，可以选择结果展示方式(图形、表格)。

(3)用户可以设置对所监控设备的告警级别、告警方式。

5)实现告警模块，设置告警级别、告警方式。确保用户可以针对自己所监控的设备制定“定制化”的告警方式和级别。

6)增加辅助决策支持：一方面针对运维监控***中常见运维故障及处理方法构建问题知识库，为运维监控人员遇到故障时，为其提供解决方案支持；另一方面构建辅助决策机制，事先定义常见故障的自动处理方式，结合运维预测结果并分析告警信息给出相关辅助决策，使用脚本、API接口等方式自动实现资源扩容、故障处理，无需运维人员手动进行处理，实现运维自动化。

Claims (10)

1.一种运维自动化***，其特征在于：它包括以下功能模块：

数据采集模块：用于通过网管协议或者日志文件获取运维***中各个被监控单元的关键性能指标和运行状态，为运维数据处理、分析以及预测提供数据基础；

预处理与存储模块：对数据采集模块采集得到的数据进行清洗、过滤、补缺失处理和自动删除预处理，同时对于结构化和非结构化的数据进行数据转化和元数据提取，对于不同类别的运维数据进行分类存储；

预测模块：根据预处理与存储模块处理之后的数据，针对不同的预测方式建立不同的预测模型并进行预测，所述的预测模块包括CPU负载预测模块和磁盘负载预测模块；

算法评价模块：建立预测模块的预测算法的评价标准，将实际值与预测算法的预测值进行对比，建立自学习过程：当预测算法的预测值不满足规定误差时，根据实际值修改预测模块的预测模型参数，保证在特定环境和特定时间内选择出合适的算法模型；

运维监控管理模块：负责和运维管理人员按进行交互，其包括以下子模块：

(1)数据展示单元：将数据采集模块采集到的监控单元的数据经过预处理与存储模块的分析和加工之后，向运维管理人员进行展示；

(2)预测信息展示单元：将预测模块预测得到的CPU负载和磁盘空间使用情况的预测信息展示给运维管理人员；

(3)告警单元：监听被监控设备的状态信息，包括当前状态信息和预测状态信息，当设备某一状态数据值超过所设置的阈值时，告警模块将按提前设置好的告警方式进行告警，并且根据常见运维故障构建知识库，在做出告警信息的同时并给出辅助决策。

2.根据权利要求1所述的一种运维自动化***，其特征在于：所述的数据采集模块采集的数据来自于集群中主机服务器、数据库、存储设备和监控设备，包括非云环境下的数据采集和云环境下的数据采集，其中，对于非云环境下的数据采集，针对不同的数据采集环境，提供集中式数据采集和分层式数据采集的框架，并且采用SYSLOG、SNMP、WEBSERVICE、JMS协议的采集方式；对于云环境下的数据采集，提供多级多域的数据采集框架，直接对云环境下的中的管理节点进行数据采集。

3.根据权利要求1所述的一种运维自动化***，其特征在于：所述的运维监控管理模块还包括一个用户管理单元，所述的用户管理单元用于权限管理、用户信息管理、用户注册和用户登录。

4.根据权利要求1所述的一种运维自动化***，其特征在于：所述的告警单元还包括对于有相应权限的用户提供告警级别设置、告警方式设置和告警阈值设置子模块。

5.一种运维自动化的方法，其特征在于：它包括以下步骤：

S1：数据采集，用于通过网管协议或者日志文件获取运维***中各个被监控单元的关键性能指标和运行状态，为运维数据处理、分析以及预测提供数据基础；

S2：预处理与存储，对采集得到的数据进行清洗、过滤、补缺失处理和自动删除预处理，同时对于结构化和非结构化的数据进行数据转化和元数据提取，对于不同类别的运维数据进行分类存储；

S3：预测，利用预处理后的数据，根据不同的预测方式建立不同的预测模型并进行预测，所述的预测模型包括CPU负载预测模型和磁盘负载预测模型；

S4：模型评价，建立预测模型的评价标准，将实际值与预测模型的预测值进行对比，建立自学习过程：当预测模型的预测值不满足规定误差时，根据实际值修改预测模型的预测模型参数，保证在特定环境和特定时间内选择出合适的模型；

S5：运维监控管理，负责和运维管理人员按进行交互，其包括以下子步骤：

S51：数据展示，将采集到的监控单元的数据经过预处理与存储后，向运维管理人员进行展示；

S52：预测信息展示，将预测得到的CPU负载和磁盘空间使用情况展示给运维管理人员；

S53：告警，监听被监控设备的状态信息，包括当前状态信息和预测状态信息，当设备某一状态数据值超过所设置的阈值时，告警模块将按提前设置好的告警方式进行告警，并且根据常见运维故障构建知识库，在做出告警信息的同时并给出辅助决策。

6.根据权利要求5所述的一种运维自动化的方法，其特征在于：所述的磁盘负载预测模型为磁盘使用空间增长随业务量与季节的变化而变化的规律模型，其建模过程包括以下子步骤：

S311：建立基于时间序列的线性季节性增长模型，公式如下：

y_t＝(a+bt)+S_t+I_t；

式中，y_t为磁盘空间使用量，t为时间，S_t为季节变化，I_t为新增业务上线，a与b均为常数；

S312：确定步骤S311中的模型的输入值，包括以下子步骤：

A：根据预处理与存储，获取服务器磁盘空间的已用空间、增长量、磁盘剩余空间；

B：通过增长量变化率即平均日增长量增量Δt'计算得出季节变化S_t：设日增长量为Δt，平均日增长量增量为Δt'＝Δt₁-Δt₂，S_t即为平均日增长量增量Δt'在[t₁,t₂]时间段内的积分值，即

$S_t={\∫}_{t_1}^{t_2}{\mathrm{\Δt}}^{\′}{\mathrm{d\Δt}}^{\′};$

C：新增业务上线I_t与用户使用量u相关，用户使用量u由每日业务点击量计量，经业务数据与磁盘存储之间的关系计算，获得新增业务上线I_t；

D：通过平均日增长量Δt'计算得出a与b，a与b的值为线性增长；

S313：根据步骤S312获得的磁盘空间使用量y_t的数据输入值带入步骤S311中的增长模型，经过计算得到磁盘使用空间值y_t；

S314：根据步骤S313得到的磁盘使用空间值y_t，进行反解获得告警时间，并发送至运维监控管理模块；当运维监控管理模块得到数据之后，通知运维监控人员进行磁盘容量扩充或磁盘信息整理。

7.根据权利要求5所述的一种运维自动化的方法，其特征在于：所述的CPU负载预测模型包括基于模式的预测算法模型，其建模过程包括以下子步骤：

S321：获取经过预处理之后提取出来的CPU运行状态信息和CPU自身性能信息的CPU负载历史数据，并且计算出各个时间节点上的CPU负载Load_cpu，公式如下：

${\mathrm{Load}}_{cpu}=\frac{used\_cpu}{all\_cpu},$

式中，used_cpu表示已使用的CPU，all_cpu表示总共的CPU，二者均以百万条指令每秒MIPS为单位；

S322：对输入的CPU负载历史数据进行计算预处理，并计算CPU负载在每个时间节点上的变化率CR，公式如下：

$CR\left(t_i\right)=\frac{V_{t_i}-V_{t_{i-1}}}{V_{t_{i-1}}}*100\%;$

式中，为t_i时刻的CPU负载数值，i＝0,1,2,...，n；

S323：选取当前模式匹配长度L，构造CPU负载历史数据及当前负载模式、CPU负载的变化率及当前的变化率模式；

S324：对输入的CPU负载历史数据进行分段，段数为N，逐段计算相似性程度，包括以下子步骤：

S3241：令变量i的值为0；

S3242：判断i的值是否比N小的条件是否符合：

(1)如果条件不符合进入步骤S325；

(2)如果条件符合，包括以下子步骤：

A：计算SD_CR(t_i)和SD_CPU(t_i)，其中SD_CR(t_i)表示在CPU历史记录数据中从t_i-L到t_i这段时间中记录的CPU负载的标准差，SD_CPU(t_i)为当前模式记录的CPU负载的标准差；

B：判断以下两个条件中的至少一项是否成立，如果成立则进入步骤S3243，如果不成立则对i的值进行加1操作之后返回步骤S3242：

条件1：SD_CPU(t_i)≤SD_{CPU_THRESHOLD}；

条件2：SD_CPU(t_i)≤SD_{CPU_TOLERANCE}并且SD_CR(t_i)≤SD_{CR_THRESHOLD}

式中，SD_{CPU_THRESHOLD}表示相似模式标准的最大CPU负载标准方差，SD_{CPU_TOLERANCE}表示CPU负载标准方差的宽限值，SD_{CR_THRESHOLD}表示相似模式标准的最大CPU负载变化率标准方差；

S3243：将t_i处的SD_CR(t_i)和SD_CPU(t_i)加入相似模式集合Q中；

S325：将集合Q中的相似模式按距离当前模式时间的远近进行排序，并赋予不同权值；

S326：将不同权重的相似模式的截止时间点t_i点及其对应权重保存在集合P中，公式如下：

$P_{CPU}\left(t_0\right)=\underset{i=1}{\overset{n}{\Σ}}{\mathrm{\α}}_i*P_{CPU}\left(t_i\right),$

式中，P_CPU(t_i)表示距当前模式第i个CPU负载模式，i＝0,1,2,...，n；i越大表示离当前模式的时间越远，α_i表示相似模式i的权重；P_CPU(t₀)表示当前CPU负载模式；

S327：遍历集合P，计算各个预测值，比较得到最终预测值；

S328：将得到的一系列CPU负载预测值在运维监控管理模块上显示，以时间点为横坐标、负载百分比为纵坐标描绘CPU负载-时间预测图，将未来一段时间内CPU的负载趋势用曲线图来表示；同时将图中超过指定CPU负载阈值的信息(发生时间、负载值)以告警的方式发送给***和监控人员，提醒采取措施。

8.根据权利要求5所述的一种运维自动化的方法，其特征在于：所述的辅助决策的具体过程是，综合负载预测的结果，对于低级别的故障及告警，采用默认处理方式或者采用用户自行选择的***提供的处理方式；对于高级别的故障及告警，直接通知用户，由用户决定处理方式。

9.根据权利要求5所述的一种运维自动化的方法，其特征在于：所述的数据采集包括以下采集方式：

(1)周期性数据采集：是指主动节点简单地、周期性从网络设备中获取需要数据的方法，周期性数据采集针对不同的数据粒度设定相应的采集周期；

(2)异常数据采集：是指网络设备运行过程中某些运行状态指标出现异动或者是***出现异常时，主动节点将异常数据传送到网络监控中心；

(3)主动式数据采集：为了完成在网络管理的日常事务中管理员特定的网络监控任务，根据一定的数据采集目的直接对特定数据进行采集。

10.根据权利要求9所述的一种运维自动化的方法，其特征在于：数据采集方式的转换包括以下子步骤：

S11：设定主动节点的采样周期t，即每隔t秒主动节点就会对网络运行状态进行采样；

S12：用批量设定的方式为每一个监控对象设定一个数据采集周期T，数据采集周期T应该大于主动节点的采样周期t，采集周期值等于采集周期内采样周期值的平均值；每隔T秒主动节点就将网络运行状态数据上报网络监控中；

S13：针对特定的网络性能数据设定监控规则和阈值，每隔一个采样周期t秒就会根据规则计算一次网络性能状态，若超过阈值主动节点就将网络运行状态数据上报网络监控中心；

S14：当网络特定性能的运行状态出现异常时，针对该特定性能的数据采集方式转变为主动数据采集方式，停止当前的周期性数据采集和异常数据采集，将网络特定性能的实时运行状态详细信息发送给监控中心；

S15：当网络监控人员主动观察某项网络性能指标时，针对该特定性能的数据采集方式转变为主动数据采集方式；当网络监控人员退出主动观察某项网络性能指标时，针对该特定性能的数据采集方式转变为周期性数据采集方式。