网元故障质检方法、装置、设备及介质与流程

本发明涉及通信技术领域，尤其涉及一种网元故障质检方法、装置、设备及介质。

背景技术：

在移动通信网络的日常运维中，依赖网元告警进行网元设备的监控，运维人员面对的是一个由多种制式、数十万个网元构成的通信网络。同时由于网元设备的告警往往存在失真，经常会出现漏告警、关键信息缺失、告警被人为关闭等问题，不能反映网络的真实状态，因此需要进行网元告警的质检。

传统的网元故障质检的方法有：根据告警质检的业务特征，人工登录相关网元通过网元状态查询指令进行网元状态的获取，从而进行网元故障的质检。

然而，依赖人工对网元故障进行质检、定位耗时长工作量大，运维效率无法满足生产要求。若能针对故障质检场景实现网元指令的自动化操作，可减少人工登录网元进行告警质检工作，从而实现网元故障质检的运维自动化、保证网络监控无遗漏、提升网元抢修效率。

综上所述，传统的自动化网元故障质检的方法主要采用人工的方式获取网元状态，实现网元故障质检。当面对数十万计的移动通信网络的时候，传统的人工质检方式工作量大、效率低、时效性差，无法实现网元的全覆盖式的状态质检。

技术实现要素：

本发明实施例提供了一种网元故障质检方法、装置、设备及介质，通过选取性能最优代理机执行任务，获得网元状态数据，并与故障数据对比，实现网元故障质检自动化。

第一方面，本发明实施例提供了一种网元故障质检方法，方法包括：

实施任务接收服务，以接收网元告警信息；

将所述网元告警信息转化为可执行指令；

根据所述网元告警信息，获取待查询网元；

采集多个代理机的服务器性能指标；

预测接收到的任务所需消耗的服务器资源；

匹配所述多个代理机的服务器性能指标和所述接收到的任务所需消耗的服务器资源，从所述多个代理机中选取性能最优代理机执行所述接收到的任务；

所述最优代理机连接所述待查询网元，执行所述可执行指令，获得网元状态数据；

将所述网元状态数据与所述网元告警信息进行对比，完成所述网元故障质检。

根据本发明所述的网元故障质检方法，所述网元告警信息包括如下项中的至少一种：

告警标识码、告警时间、告警地点、告警设备类型、网元名称、网元厂家、小区名称、位置区码、和小区识别码。

根据本发明所述的网元故障质检方法，所述采集多个代理机的服务器性能指标，包括：

所述多个代理机基于分布式协调服务形成采集集群；

其中，所述分布式协调服务监控所述多个代理机中的每一个的存活状态，并且基于预设周期，周期性上报所述多个代理机的服务器性能指标，以采集所述多个代理机的服务器性能指标。

根据本发明所述的网元故障质检方法，所述实施任务接收服务，包括：

基于反向代理服务，实施任务接收服务。

根据本发明所述的网元故障质检方法，所述基于反向代理服务，实施任务接收服务，包括：

新增网元告警信息服务节点；

将所述新增网元告警信息服务节点添加至所述反向代理服务中，实施任务接收服务。

根据本发明所述的网元故障质检方法，所述将所述网元告警信息转化为可执行指令，包括：

基于所述网元告警信息，通过指令配置库，获取指令执行模板；

基于所述指令执行模板，将所述网元告警信息转化为可执行指令。

根据本发明所述的网元故障质检方法，所述预测接收到的任务所需消耗的服务器资源，包括：

通过岭回归算法，预测接收到的任务所需消耗的服务器资源。

根据本发明所述的网元故障质检方法，所述通过岭回归算法，预测接收到的任务所需消耗的服务器资源，包括：

通过对以往执行任务的历史平均所耗资源进行分析，基于岭回归算法，预测接收到的任务所需消耗的服务器资源。

根据本发明所述的网元故障质检方法，所述匹配所述多个代理机的服务器性能指标和所述接收到的任务所需消耗的服务器资源，从所述多个代理机中选取最优代理机执行所述接收到的任务，包括：

根据排序算法，对所述多个代理机的服务器性能指标进行排序；

基于排序结果，匹配所述多个代理机的服务器性能指标和所述接收到的任务所需消耗的服务器资源，从所述多个代理机中选取最优代理机执行所述接收到的任务。

根据本发明所述的网元故障质检方法，所述执行所述可执行指令，包括：

通过指令引擎，执行所述可执行指令。

第二方面，本发明实施例提供了一种网元故障质检装置，装置包括：

接收模块，用于实施任务接收服务，以接收网元告警信息；

转化模块，用于将所述告警信息转化为可执行指令；

获取模块，用于根据所述告警信息，获取待查询网元；

采集模块，用于采集多个代理机的服务器性能指标；

预测模块，用于预测接收到的任务所需消耗的服务器资源；

匹配模块，用于匹配所述多个代理机的服务器性能指标和所述接收到的任务所需消耗的服务器资源，从所述多个代理机中选取最优代理机执行所述接收到的任务；

执行模块，用于所述最优代理机连接所述待查询网元，执行所述可执行指令，获得网元状态数据；

对比模块，用于将所述网元状态数据与所述网元告警信息进行对比，完成所述网元故障质检。

根据本发明所述的网元故障质检装置，所述网元告警信息包括如下项中的至少一种：

告警标识码、告警时间、告警地点、告警设备类型、网元名称、网元厂家、小区名称、位置区码、和小区识别码。

根据本发明所述的网元故障质检装置，采集模块具体用于：

所述多个代理机基于分布式协调服务形成采集集群；

其中，所述分布式协调服务用于监控所述多个代理机中的每一个的存活状态，并且基于预设周期，周期性上报所述多个代理机的服务器性能指标，以采集所述多个代理机的服务器性能指标。

根据本发明所述的网元故障质检装置，接收模块具体用于：

基于反向代理服务，实施任务接收服务。

根据本发明所述的网元故障质检装置，接收模块具体用于：

新增网元告警信息服务节点；

将所述新增网元告警信息服务节点添加至所述反向代理服务中，实施任务接收服务。

根据本发明所述的网元故障质检装置，转化模块具体用于：

基于所述网元告警信息，通过指令配置库，获取指令执行模板；

基于所述指令执行模板，将所述网元告警信息转化为可执行指令。

根据本发明所述的网元故障质检装置，预测模块具体用于：

通过岭回归算法，预测接收到的任务所需消耗的服务器资源。

根据本发明所述的网元故障质检装置，预测模块具体用于：

通过对以往执行任务的历史平均所耗资源进行分析，基于岭回归算法，预测接收到的任务所需消耗的服务器资源。

根据本发明所述的网元故障质检装置，匹配模块具体用于：

根据排序算法，对所述多个代理机的服务器性能指标进行排序；

基于排序结果，匹配所述多个代理机的服务器性能指标和所述接收到的任务所需消耗的服务器资源，从所述多个代理机中选取最优代理机执行所述接收到的任务。

根据本发明所述的网元故障质检装置，执行模块具体用于：

通过指令引擎，执行所述可执行指令。

本发明实施例提供了一种网元故障质检设备，包括：至少一个处理器、至少一个存储器以及存储在存储器中的计算机程序指令，当计算机程序指令被处理器执行时实现如上述实施方式中第一方面的方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，其上存储有计算机程序指令，当计算机程序指令被处理器执行时实现如上述实施方式中第一方面的方法。

本发明实施例提供的网元故障质检方法、装置、设备及介质，，通过选取性能最优代理机执行任务，获得网元状态数据，并与故障数据对比，实现网元故障质检自动化。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了本发明一实施例的网元故障质检方法的流程示意图；

图2示出了本发明实施例的网元故障质检装置的结构示意图；

图3示出了本发明另一实施例的网元故障质检方法的流程示意图；

图4示出了本发明实施例的任务接收的架构示意图；

图5示出了本发明实施例的任务调度的流程示意图；

图6示出了本发明实施例的网元故障质检设备的示例性硬件架构的结构图。

具体实施方式

下面将详细描述本发明的各个方面的特征和示例性实施例，为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细描述。应理解，此处所描述的具体实施例仅被配置为解释本发明，并不被配置为限定本发明。对于本领域技术人员来说，本发明可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本发明的示例来提供对本发明更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

传统的人工网元故障质检，主要有以下几个缺点：

首先，一张通信网络的网元是数以十万计的，人工质检往往只能采用抽样的方式进行网元质检或指定某些特定(告警)状态的网元进行质检，无法实现全网全覆盖式的网元质检，无法发现网元的状态隐患，无法识别被认为屏蔽的告警。

其次，人工方式质检步骤较多，人员工作量比较大，对技能也有一定的要求，总体上体现为质检效率低、时效性差，无非满足质检实时性要求；

再次，对于网元的交互指令、结果解析规则、执行规则缺乏可视化的管理方式，不够直观，对员工的技能要求较高，培训成本高。

本发明实施例的技术方案可以有效解决上述问题，具体如下：

本发明实施例提供了一种基于实时指令的自动化网元故障质检方法。该方法基于机器学习(例如，岭回归算法)的最优任务调度流程实现网元故障质检自动化。

其中，最优任务调度流程主要包含两个重要环节。首先，通过回归算法预测出当前任务所需消耗的服务器资源；其次，采集代理机(agent)上报服务器性能指标到zookeeper分布式协调服务用于对比，选择最优代理机执行任务。

通过该最优适配器算法，采用并行采集的方式向网元自动下发指令；通过解析指令返回结果实现对于网元状态的质检。解决了以往依赖人工对网元故障进行质检、定位耗时长工作量大，运维效率无法满足生产要求的问题。

本发明实施例可提供一种网元故障质检方法，参考图1，图1示出了本发明实施例的网元故障质检方法100的流程示意图，该方法包括：

s110，实施任务接收服务，以接收网元告警信息；

s120，将网元告警信息转化为可执行指令；

s130，根据网元告警信息，获取待查询网元；

s140，采集多个代理机的服务器性能指标；

s150，预测接收到的任务所需消耗的服务器资源；

s160，匹配多个代理机的服务器性能指标和接收到的任务所需消耗的服务器资源，从多个代理机中选取性能最优代理机执行接收到的任务；

s170，最优代理机连接待查询网元，执行可执行指令，获得网元状态数据；

s180，将网元状态数据与网元告警信息进行对比，完成网元故障质检。

利用本发明提供的上述方案，通过选取性能最优代理机执行任务，获得网元状态数据，并与故障数据对比，实现网元故障质检自动化。

本发明实施例可提供一种网元故障质检装置，参考图2，图2示出了本发明实施例的网元故障质检装置200的结构示意图，该装置包括：

接收模块210，用于实施任务接收服务，以接收网元告警信息；

转化模块220，用于将告警信息转化为可执行指令；

获取模块230，用于根据告警信息，获取待查询网元；

采集模块240，用于采集多个代理机的服务器性能指标；

预测模块250，用于预测接收到的任务所需消耗的服务器资源；

匹配模块260，用于匹配多个代理机的服务器性能指标和接收到的任务所需消耗的服务器资源，从多个代理机中选取性能最优代理机执行接收到的任务；

执行模块270，用于最优代理机连接待查询网元，执行可执行指令，获得网元状态数据；

对比模块280，用于将网元状态数据与网元告警信息进行对比，完成网元故障质检。

利用本发明提供的上述方案，通过利用匹配模块匹配多个代理机的服务器性能指标和接收到的任务所需消耗的服务器资源，从多个代理机中选取性能最优代理机执行任务，获得网元状态数据，并与故障数据对比，实现网元故障质检自动化。

以下通过具体的实例，描述本发明实施例的可选的具体处理过程。需要说明的是，本发明的方案并不依赖于具体的算法，在实际应用中，可选用任何已知或未知的硬件、软件、算法、程序或其任意组合等来实现本发明的方案，只要是采用了本发明方案的实质思想，均落入本发明的保护范围。

参考图3，图3示出了本发明另一实施例的网元故障质检方法300的流程示意图，该方法包括：

s310，任务接收：nginx(反向代理服务)负载均衡、指令任务标准化。

作为一个示例，参考图4，图4示出了本发明实施例的任务接收的架构示意图。

具体地，任务接收通过socket传输控制协议(sockettransmissioncontrolprotocol，sockettcp)对外提供任务接收服务，以提供告警接收能力。基于nginx搭建分布式告警接收体系并统一对外提供告警接收服务。其中，nginx是一个高性能的反向代理服务自带了多种负载均衡方案，集群的扩展通过简单的配置结合热部署能力可以无感知的进行集群的扩展。

对于告警接收服务扩展只需新增告警服务节点，将告警服务节点动态添加到nginx中，即可实现服务横向扩展，提高告警接收并发能力快速响应业务增长需求。

任务接收服务可以接收网元告警信息，在一个实施例中，网元告警信息包括告警标识码、告警时间、告警地点、告警设备类型(2g小区：cell，4g小区：entrancell，4g基站：enodeb)、网元名称、网元厂家、小区名称、位置区码(locationareacode，lac)、小区识别码(cellid，ci)等告警信息。

通过告警信息获取所需查询的网元(待查询网元)设备并通过指令配置库获取指令执行模板，将网元告警信息转化为可执行指令实例，初始化任务模块并将任务放到任务队列中。

其中，如图4所示，java消息服务(javamessageservice，jms)是一个java平台中关于面向消息中间件(message-orientedmiddleware，mom)的应用程序编程接口(applicationprogramminginterface，api)，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。

s320，任务调度：执行策略、基于岭回归最优调度算法。

作为一个示例，参考图5，图5示出了本发明实施例的任务调度的流程示意图。

首先，采集代理机(agent)上报服务器性能指标到zookeeper(分布式协调服务)。

多个agent基于zookeeper形成采集集群，zookeeper负责监控所有agent的存活状态，并且基于预设周期，周期性(例如，每隔3秒)上报一次代理机的服务器性能指标。

其次，调度框架通过岭回归算法，预测接收到的任务(当前待执行任务)所需消耗的服务器资源。

再次，将agent上报的多个代理机的服务器性能指标与预测接收到的任务所需消耗的服务器资源进行匹配，并从多个代理机中选择性能最优agent执行接收到的任务。

其中，zookeeper是一个分布式的，开放源码的分布式应用程序协调服务。

并且最优任务调度算法是机器通过以往执行任务的历史平均所耗资源进行分析，基于岭回归算法，预测接收到的任务所需消耗的服务器资源。

作为一个示例，最优任务调度算法是机器通过对以往执行任务进行分析，并结合岭回归算法计算出待调度任务的执行所需要占用的服务器资源；获取当前所有采集机的性能指标通过排序算法将采集机空闲资源从优到劣进行排序；对比执行待调度任务所需的资源与采集机空闲资源，以选择最优方案派发任务。

调度框架从zookeeper中获取待执行任务和agent性能指标。最优调度算法模块从redis(数据库)中获取待执行任务的历史平均所消耗资源，通过岭回归算法预测出待执行任务所需服务器资源；并根据排序算法对agent上报的当前服务器的性能指标进行排序；匹配待执行任务所需资源与agent空闲资源选择最优agent派发任务，实现最优任务调度算法。

其中，redis是一个高性能的分布式存储系统(key-value)数据库。

s330，执行指令：指令自动采集、分析。

性能最优代理机连接待查询网元，执行可执行指令，获得网元状态数据。

作为一个示例，通过指令引擎，执行可执行指令，实现指令的自动化执行。

其中，指令引擎通过微服务对上层应用提供指令执行服务。

在一个实施例中，微服务架构可以进行横向添加微服务节点来提高服务并发能力，满足更多的告警质检要求。

指令引擎接收到指令任务后连接网元、执行指令，并通过解析适配器解析指令执行结果，标准化网元状态数据便于结果对比。

s340，故障结果比对、告警清除。

作为一个示例，将标准化网元状态数据与网元告警信息按照配置的规则进行对比。指令平台为了加快比对效率，将规则库信息同步到内存库中，在对比时与内存库数据进行对比；通过对比结果对告警进行清除，完成网故障质检。

为了便于理解，下面对基于岭回归算法的最优任务调度算法进行详细介绍：

首先，对最优任务调度算法原理进行详细介绍，具体如下：

作为一个示例，最优任务调度算法是机器通过对以往执行任务进行分析，并结合岭回归算法计算出待调度任务执行所需要占用的服务器资源；获取当前所有采集机的性能指标通过排序算法将采集机空闲资源从优到劣进行排序；对比实施待执行任务所需资源与采集机空闲资源，选择最优方案派发任务。

其次，对岭回归算法原理进行详细介绍，具体如下：

岭回归(ridgeregression，tikhonovregularization)是一种专用于共线性数据分析的有偏估计回归方法，实质上是一种改良的最小二乘估计法，通过放弃最小二乘法的无偏性，以损失部分信息、降低精度为代价获得回归系数更为符合实际、更可靠的回归方法，对病态数据的拟合要强于最小二乘法。在进行特征选择时，一般有三种方式：

第一种：子集选择。

第二种：收缩方式(shrinkagemethod)，又称为正则化(regularization))。主要包括岭回归和lasso(套索)回归。

第三种：维数缩减。

岭回归是在平方误差的基础上增加正则项，公式如下：

通过确定λ的值可以使得在方差和偏差之间达到平衡：随着λ的增大，模型方差减小而偏差增大。对ω求导，结果如公式(2)所示：

2x^t(y-xw)-2λw(2)

令其为0，可求得ω的值，如公式(3)所示：

其次，对基于岭回归算法实现资源预测原理进行详细介绍，具体如下：

在一个实施例中，一个任务所需资源包括cpu、内存、io、线程等。假定执行任务所需资源为y。所需cpu资源为e1、所需内存资源为e2、所需io资源为e3、所需线程资源为e4。得出公式(4)：

y＝e1+e2+e3+e4(4)

执行待调度任务所需各项资源，因为对各指项指标要求不同存在差异。假定a任务的cpu权重比为a、内存权重比为b、io权重比为c、线程权限比为d，则根据公式(4)进行列式联立，得到公式(5)：

y＝e1*a+e2*b+e3*c+e4*d(5)

输入已知历史任务消耗资源的样本。建立多元一次方程写成矩阵形式，以简化回归公式和对回归问题的描述，如公式(6)所示。

其中，n个样本p个变量x、y已知。对数据中心化、标准化处理后可以去掉截距项。矩阵形式的多元线性模型如下所示：

y＝xβ+ξ(7)

求解β，使得误差项ε能达到较低。

通过输入样本使用岭回归算法对应的a、b、c、d的系数，取出的数据系数能够满足绝大多数据样本。

分析历史任务执行所需资源的平均值，将计算出e1、e2、e3、e4值。代入历史任务执行所需资源的平均值，算出待执行任务预计消耗的服务器资源。

综上，本发明实施例要解决的技术问题主要包括以下几个：

第一，通过最优适配器算法，实现指令的自动化并行采集，能够在10分钟内完成省移动数十万个网元状态的自动化采集、解析、比对，解决提升网元故障质检效率

第二，对于移动通信网元状态的的采集方法、解析规则、比对规则统一进行管理，解决网元故障质检流程自动化管理问题；

本发明实施例为解决上述问题采取的技术手段主要如下所示：

第一、通过标准化流程方式实现自动化网元故障质检工作。

第二、基于机器学习(例如，岭回归算法等)的最优任务调度流程实现网元故障质检自动化。

其中，最优任务调度流程主要包含两个重要环节。首先，通过回归算法预测出当前任务所需消耗的服务器资源；其次，采集代理机(agent)上报服务器性能指标到zookeeper分布式协调服务用于对比，选择性能最优代理机执行任务。

第三、在任务编排过程中，提供可视化的界面配置网元指令、登录信息、比对规则、结果解析等内容，最终实现网元故障质检的流程自动化。

另外，结合图1描述的本发明实施例的网元故障质检方法可以由网元故障质检设备来实现。图6示出了本发明实施例提供的网元故障质检设备的硬件结构示意图。

网元故障质检设备可以包括处理器1003以及存储有计算机程序指令的存储器1004。

图6是示出能够实现根据本发明实施例的通信方法和网络服务器的计算设备的示例性硬件架构的结构图。如图6所示，计算设备1000包括输入设备1001、输入接口1002、处理器1003、存储器1004、输出接口1005、以及输出设备1006。

其中，输入接口1002、处理器1003、存储器1004、以及输出接口1005通过总线1010相互连接，输入设备1001和输出设备1006分别通过输入接口1002和输出接口1005与总线1010连接，进而与计算设备1000的其他组件连接。

具体地，输入设备1001接收来自外部的输入信息，并通过输入接口1002将输入信息传送到处理器1003；处理器1003基于存储器1004中存储的计算机可执行指令对输入信息进行处理以生成输出信息，将输出信息临时或者永久地存储在存储器1004中，然后通过输出接口1005将输出信息传送到输出设备1006；输出设备1006将输出信息输出到计算设备1000的外部供用户使用。

计算设备1000可以执行本申请上述的通信方法中的各步骤。

处理器1003可以是一个或多个中央处理器(英文：centralprocessingunit，cpu)。在处理器1003是一个cpu的情况下，该cpu可以是单核cpu，也可以是多核cpu。

存储器1004可以是但不限于随机存储存储器(ram)、只读存储器(rom)，可擦除可编程只读存储器(eprom)、光盘只读存储器(cd-rom)、硬盘等中的一种或多种。存储器1004用于存储程序代码。

可以理解的是，在本申请实施例中，图2提供的第一处理模块至第七处理模块中任一模块或全部模块的功能可以用图6所示的中央处理器1003实现。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用全部或部分地以计算机程序产品的形式实现，所述计算机程序产品包括一个或多个计算机指令。在计算机上加载或执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输)。所述计算机可读取存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。

本说明书的各个部分均采用递进的方式进行描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点介绍的都是与其他实施例不同之处。尤其，对于装置和系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例部分的说明即可。