CN104125085B - 一种基于esb的数据管控方法及装置 - Google Patents

Abstract

本发明公开了一种基于ESB的数据管控方法及装置，涉及网管技术领域，解决了现有技术中对ESB的管控效率低等技术问题，其中，该方法包括：采集网元设备的性能数据；根据预设的元数据模型确定采集到的性能数据属性是否存在异常；如果确定采集到的性能数据的属性存在异常，则将所述性能数据中的各项指标数据拆分成原始数据，并根据所述原始数据的资源关系定位与所述异常关联的异常点；将所述关联的异常点以多媒体的形式展示。本发明适用于ESB。

Description

一种基于ESB的数据管控方法及装置

技术领域

本发明涉及网管技术领域，特别涉及一种基于ESB（Enterprise Service Bus，企业服务总线）的数据管控方法及装置。

背景技术

随着3G全业务运营时代的到来，网管系统作为移动通信网络日常生产维护的支撑手段，其重要性越来越高。如何有效地对网管系统数据进行统一处理把控，全方位的为网络维护及指挥调度工作提供有力支撑，已成为网络维护发展的命题。

当前对网管系统数据管控方法一般会采用以下两种方式：一种方式是对数据接口进行采集监控，依据数据接口故障并结合系统维护经验对数据问题进行分析；另一种方式是通过上层应用数据缺失及异常情况进行监控，对发现的数据异常情况通过通知系统维护人员，然后再通过人工方式从采集层进行补采来修复。

但是，现有的网管系统的数据处理方式至少存在如下缺点：

1、现网管系统数据问题多是后知后觉，通常是影响到上层应用以后，才向下追溯问题的根因，而且多数问题还是只能监控而没有达到统一管控的水平，大部分还是需要人为进行修复。

2、数据处理都是在后台运行，数据问题很难被发现，并且数据处理后的状态也都要通过人为方式的进行二次核查，处理效率很低。

3、系统间的数据接口繁多、且多为私有接口，协议不规范，且接口出现问题后只能看到接口两侧系统的通信问题，仅能针对正在处理的数据进行分析，而无法判断到与之关联的其他系统的影响情况，导致无法对数据进行关联性预警。

发明内容

为了解决现有技术中无法对数据进行关联性预警、数据问题需要人为修复、管控效率低等技术问题，本发明提出一种基于ESB（Enterprise Service Bus，企业服务总线）的数据管控方法及装置。

一种基于ESB的数据管控方法，包括：

采集网元设备的性能数据；

根据预设的元数据模型确定采集到的性能数据属性是否存在异常；

如果确定采集到的性能数据的属性存在异常，则将所述性能数据中的各项指标数据拆分成原始数据，并根据所述原始数据的资源关系定位与所述异常关联的异常点；

将所述关联的异常点以多媒体的形式展示。

一种基于ESB的数据管控装置，包括：

采集模块，用于采集网元设备的性能数据；

异常确定模块，用于根据预设的元数据模型确定采集到的性能数据属性是否存在异常；

关联分析模块，用于当异常确定模块确定采集到的性能数据的属性存在异常时，将所述性能数据中的各项指标数据拆分成原始数据，并根据所述原始数据的资源关系定位与所述异常关联的异常点；

展示模块，用于将所述关联的异常点以多媒体的形式展示。

本实施例提供的方法可以对各专业网管系统平台的性能数据的属性进行实时监测处理，并具备性能数据问题影响范围的跨专业告警关联分析能力，实现了数据处理全流程的透明可视化展现，大幅提高了网络运维分析工作效率，有效降低数据问题对生产应用的影响，为全专业的网络运维指挥调度管控工作提供了有力支撑。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

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

图1为本发明实施例1提供的一种基于ESB的数据管控方法中关联预警方案的流程图；

图2为本发明实施例1提供的一种基于ESB的数据管控方法中故障修复方案的流程图；

图3为本发明实施例2提供的一种基于ESB的数据管控装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。并且，以下各实施例均为本发明的可选方案，实施例的排列顺序及实施例的编号与其优选执行的顺序无关。

实施例1

本实施例提供一种基于ESB的数据管控方法，该方法适合部署在运行有ESB数据管控系统的服务器上。其中，该方法主要关联预警方案和故障修复方案。关联预警方案用于根据故障数据进行关联故障定位以便对故障的影响范围进行预警；故障修复方案用于对定位的故障进行自动修复，以便减少,人为工作业量。

如图1所示，为本实施例提供的方法中关联预警方案的流程，包括：

步骤101，服务器采集网元设备的性能数据，该性能数据是所采集的网元设备的各项指标的性能数据，包括话务量、短信量、拥塞率等；

优选方案为：服务器通过corba（公共对象请求代理体系结构）、Q3等标准化协议对网元设备的性能数据进行实时采集。

步骤102，根据预设的元数据模型确定采集到的性能数据的属性（性能数据的属性实际上就是该性能数据的元数据，是对该性能数据的采集时间、大小和格式等的描述）是否存在异常；如果确定采集到的性能数据的属性存在异常，则执行步骤103；如果确定采集到的性能数据的属性无异常，则执行步骤105；

具体而言，为了保障性能数据源异常情况的预警快速发现，本实施例的元数据模型中包含了正常情况下采集到的性能数据应该具有的属性，如性能数据的采集时间、性能数据的大小、性能数据的格式、性能数据值的范围、数据类型（报警数据还是性能数据）和性能数据来自哪个网元设备等。服务器通过预设的元数据模型中正常情况下性能数据应该的属性对采集到的性能数据进行比对，从而查找出性能数据属性是否异常，若比对出异常之处，则需要确定该异常点的位置和影响范围，因此执行步骤103；否则代表性能数据的属性正常，但优选方案还需要检查一下该性能数据的中的各项指标是否正常，能否影响使用该各项指标的应用程序，因此执行步骤105。

步骤103，将性能数据中的各项指标数据（本实施例以及下述实施例中的各项指标数据包括步骤101中采集到的各种指标的性能数据和根据该采集到的各项指标的性能数据计算得到的各项指标的数据）拆分成原始数据（该原始数据即是步骤101中采集到的各项指标的性能数据），并根据原始数据的资源关系定位与异常关联的异常点；

具体而言，每项指标数据都是由多个原始数据计算后得到的，并且每项原始数据的属性都会包括用来说明该项指标数据来自哪一个网元设备的资源信息，通过对发现异常的指标数据进行拆分，并根据拆分后得到的原始数据的属性可关联定位到该异常具体出现在哪一个网元设备，如具体是哪一个基站控制器C、基站或小区；

步骤104，将关联的异常点以多媒体的形式展示，执行步骤108。

具体而言，服务器可将关联定位后的异常点的位置发送至服务器中的上层拓扑分析模块，拓扑分析模块接收到该位置后，在拓扑界面中以可视化的形式自动标注该数据出现异常的与之相关的所有异常点。

步骤105，根据预设的各项指标的基线范围对性能数据中的各项指标数据进行监控，并对监控到的超出对应基线范围的指标数据进行预警。

具体而言，服务器上针对各项指标预设有基线范围，用以判断指标数据是否会因为过大或过小而影响其他应用。因此服务器根据该基线范围对相应的指标数据的值进行监控，监测该指标数据的值是否超出基线范围，如果超出范围，则针对超出基线范围的指标数据进行预警。

步骤106，将超出对应基线范围的指标数据拆分成原始数据，并根据原始数据的资源关系定位与异常关联的异常点；

具体而言，仍旧可以将异常的指标数据拆分成原始数据，在根据该原始数据的属性进行定位，从而查找出与该超出基线范围的指标数据相关的各异常点。

步骤107，将关联的异常点以多媒体的形式展示。

将分析中发现的异常点的位置进行广播通知，并提交上传并以可视化的形式进行告警通知，实现关联影响范围的准确定位，通过上层应用对异常数据的剔除等操作处理，充分保证数据的有效性。

本实施例中的多媒体形式展示也可以是透明化的，类似于人体医疗摄影，能看到各个器官，以往数据处理都是在后台执行，看不到的，通过透明化展现，能够看到整个数据处理的过程和异常点，进行快捷直观的进行呈现，大幅提升了工作效率。

步骤108，流程结束。

现有技术中的ESB性能数据分析方法，是对转发处理的性能数据进行分析，只是对数据本身单点来进行分析，没有实现性能数据的关联性分析，而出现问题后无法判断数据的影响范围，更缺少预警处理，没有做到真正意义上的数据管控。但是，本实施例提供的上述方法与现有的ESB的数据分析方法有着本质上的不同。解决了数据管控只能进行单点分析的难题，首先从性能数据的属性来确定是否异常，在根据异常数据的原始数据定位与该异常关联的异常点，并进一步从性能数据的基线范围来定位数据异常，进而打破了现有技术中不同指标数据之间无法相互关联判断是否故障的壁垒，实现了具有预警处理的数据关联分析技术，并通过对运行状态实时透明化的拓扑展现，大幅提升了数据分析处理和预警快速定位的应用效率。

如图2所示，下面为本实施例提供的方法中故障修复方案的流程，包括：

步骤201，服务器根据巡检规则检查ESB的运行状态，当检查到运行状态异常时，发出告警；

具体而言，服务器调用预设的巡检规则（包括：按时间、按顺序、按类型）自动执行对整个ESB的各采集及分析功能的运行状态进行巡检，实时掌握系统的整体运行状态，并对巡检中发现的异常问题发出告警。

其中，异常问题包括发现的采集通道拥塞、网络故障、采集进程故障等。

步骤202，服务器根据通道阈值检查ESB各个采集通道的拥塞程度，当检查到采集通道拥塞时，暂停采集通道的采集任务，减轻采集通道上的负载并上报通知；

每个采集通道都有其对应的负载能力，当采集任务过多时会造成负载过高，采集通道拥塞，因此服务器可根据预设的各采集通道的阈值检查ESB各个采集通道的拥塞程度，即对通道通过时长进行深度监测（时长超过通道阀值则定为拥塞），如果发现通道拥塞则对该采集通道暂停其采集任务，则减轻该采集通道的负载，并控制该采集通道自动进行通道重启，通道重启恢复后继续打开采集任务，保障各通道能够正常执行所分配的采集任务。

步骤203，根据ESB的运行状态和各个采集通道的采集负载定位ESB运行过程中的故障类型；

具体而言，通过对ESB各个采集通道的运行状态进行巡查可以获知每个采集通道的负载和其通道编码，通过汇总该各个采集通道的负载可以计算出哪个采集通道故障，则根据该采集通道的通道编码可以定位具体的通道位置。例如：汇总后计算出某一采集通道的负载超过阈值，且该采集通道的编码为N，则定位采集通道N故障类型为负载过重。

步骤204，根据定位的故障类型和预设的故障类型与指令匹配表中确定用于解决该故障类型的修复指令；

本实施例的方法中预先制定了故障类型与指令匹配表，该表中包括故障类型以及相应的修复指令。当出现某一故障时，首先会在故障类型与指令匹配表中进行检索，判断该故障类型（如采集适配器发生采集失败或采集进程僵死等）是否属于自动指令修复范围，然后关联到相关的修复指令，实现修复指令适配。

步骤205，运行确定的修复指令修复该故障类型对应的故障。

服务器运调用并运行步骤204中适配的修复指令，并通过指令交互，并根据反馈的信息类型，判断引起该故障的是网元设备侧还是服务器侧上的采集功能，例如：首先同适配器进行指令交互，如心跳指令等，判断适配器是否可用，如果适配器不可用，如为反馈心跳响应，则判定为适配器问题；如果适配器可用，则再向网元设备侧发交互信息，如果不可连接则确定为网元问题。定位故障的位置后，如果为服务器上系统问题，则下发重新采集指令进行性能数据补采，并对僵死进程进行重启，通过自动化的方式快速准确的修复故障点，保障系统稳定可靠的运行。

步骤206，对修复后的采集通道验证该修复后的采集通道是否可用；若验证可用，则发送确认信息。否则返回步骤205重新执行。

具体而言，在完成故障修复后，系统会对所有指令修复后的各采集用的适配器运行情况及采集通道连接情况进行状态验证，对于验证未恢复的故障重新执行不足205进行指令修复处理。

优选方案中，修复指令涉及到主修复及备案修复，当主修复不成功发起二次修复时会采用备案修复，对于所有已修复并经过验证的故障，发送确认信息，通知上层应用该故障对应的功能的可用性，实现自动化的故障处理闭环处理。

本实施例的方法中，由于考虑到ESB里出现的问题故障会影响到上层应用，而类似于数据质量的问题（如数据是不准的）上层应用感知不到，所以采用对故障及故障恢复情况及时通知上层应用，使上层应用能够实时掌握问题的处理结果，以便于更好地进行系统应用；对于修复后的故障点（就是已经没有故障的功能所对应的模块），则依据实时状态对拓扑内容进行更新，便于维护人员及时直观的掌握故障恢复情况。本实施例对从故障点触发修复指令一刻起，对整个修复指令智能化修复过程进行透明可视化展现（类似于人体医疗摄影，能看到各个器官，以往指令处理都是在后台执行，看不到的），使维护人员能够全流程了解故障的修复状态，有效避免了由于故障点未及时修复带来的隐患，大幅提升了数据异常情况的修复处理效率，进一步保障了系统运行的稳定性。

本发明实施例提供的上述方法中，虽然给出了执行各步骤的先后顺序，但是该顺序仅为本发明的一个优选的实施方式。显然，本领域技术人员根据上述方法可以对该方法步骤的执行顺序进行多种多样的等效变换，也就是说本发明实施例方法中的上述各步骤或部分步骤完全可以按照其他顺序执行，或者同时执行。例如：先执行步骤202，再执行步骤201；或者同时执行步骤202和步骤201。因此上述方法描述的各步骤的执行顺序并仅限于实施例中所提供的一种方式。

实施例2

为了便于实施例1中的方法实现，本实施例提供一种基于ESB的数据管控装置，该装置可以部署在实施例1中的ESB数据管控系统上，也可以安装在实施例1的在运行有ESB数据管控系统的服务器。如图3所示，包括：采集模块31，异常确定模块32，关联分析模块33，展示模块34。

采集模块31，用于采集网元设备的性能数据；异常确定模块32，用于根据预设的元数据模型确定采集到的性能数据属性是否存在异常；关联分析模块33，用于当异常确定模块32确定采集到的性能数据的属性存在异常时，将性能数据中的各项指标数据拆分成原始数据，并根据原始数据的资源关系定位与异常关联的异常点；展示模块34，用于将关联的异常点以多媒体的形式展示。

其中，关联分析模块33，还用于当异常确定模块32确定采集到的性能数据不存在异常，则根据预设的各项指标的基线范围对性能数据中的各项指标数据进行监控；并对监控到的超出对应基线范围的指标数据进行预警。

进一步地，关联分析模块33，还用于将超出对应基线范围的指标数据拆分成原始数据，并根据原始数据的资源关系定位与异常关联的异常点；相应地，展示模块34，还用于将关联的异常点以多媒体的形式展示。

优选方案中，该装置还包括：

检查模块，用于根据巡检规则检查ESB的运行状态，当检查到运行状态异常时，发出告警；以及根据通道阈值检查ESB各个采集通道的拥塞程度，当检查到采集通道拥塞时，暂停采集通道的采集任务，减轻采集通道上的负载并上报通知。

修复模块，用于根据ESB的运行状态和各个采集通道的采集负载定位ESB运行过程中的故障类型；并根据定位的故障类型和预设的故障类型与指令匹配表中确定用于解决该故障类型的修复指令；再运行确定的修复指令修复该故障类型对应的故障。

验证模块，用于对修复后的采集通道验证该修复后的采集通道是否可用；若验证可用，则发送确认信息。

本实施例提供的装置可以对话音网、数据网、传输网、动力环境等各专业网管系统平台的性能数据的属性进行实时监测处理，并具备性能数据问题影响范围的跨专业告警关联分析能力，实现了数据处理全流程的透明可视化展现；并且该仅可以实现采集失败或采集进程僵死等问题的迅速定位，同时能够实现影响范围的快速分析，并通过故障智能修复功能，实现了快速启动恢复以及对数据异常情况的自动化诊断修复，并结合状态验证流程实现了自动化故障处理的闭环处理，进一步保障了系统稳定可靠的运行，并实现了指令修复全部环节的透明化直观展现，大幅提高了网络运维分析工作效率，有效降低数据问题对生产应用的影响，为全专业的网络运维指挥调度工作提供了有力支撑。

本发明实施例提供的上述设备或装置等产品是属于以计算机程序的流程方法为依据，并按照与方法实施例1和/或附图中方法流程的各步骤完全对应一致的方式，所提供的功能模块。并且由于这种功能模块是通过计算机程序的方式实现的软件装置，所以对于装置实施例2未具体提及的功能模块，由于考虑到根据上述方法实施例记载的内容已经足够使本领域技术人员从方法记录的各流程步骤直接地、毫无意外地确定实现所述步骤所必须建立的功能模块，所以在此不赘述。

本发明的技术方案本质上或者说对现有技术做出贡献的部分是以软件产品的形式体现出来的功能，也即是说：本发明的装置、设备或者组成系统的各个设备其所执行的方法或实现的功能主体即便为硬件，但是实际上实现本发明上述功能的部分却是计算机软件产品的模块或单元。并且该计算机软件产品可存储在可读取的存储介质中，如计算机的软盘，硬盘或光盘等，包括若干指令用以使得一台设备执行本发明各个实施例所述的方法。

以上所述，仅为本发明的具体实施方式，但本发明能有多种不同形式的具体实施方式，上文结合附图对本发明做举例说明，这并不意味着本发明所应用的具体实施方式只能局限在这些特定的具体实施方式中，本领域的技术人员应当了解，上文所提供的具体实施方式只是多种优选实施方式中的一些示例，任何体现本发明权利要求的具体实施方式均应在本发明权利要求所要求保护的范围之内；本领域的技术人员能够对上文各具体实施方式中所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换或者改进等，均应包含在本发明权利要求的保护范围之内。

Claims (12)

1.一种基于ESB的数据管控方法，其特征在于，包括：

采集网元设备的性能数据；

根据预设的元数据模型确定采集到的性能数据属性是否存在异常；

如果确定采集到的性能数据的属性存在异常，则将所述性能数据中的各项指标数据拆分成原始数据，并根据所述原始数据的资源关系定位与所述异常关联的异常点；

将所述关联的异常点以多媒体的形式展示；

其中，原始数据为服务器采集网元设备所获得的各项指标的性能数据；

性能数据中的各项指标数据包括服务器采集网元设备所获得的各种指标的性能数据和根据该采集到的各项指标的性能数据计算得到的各项指标的数据；

每项指标数据都是由多个原始数据计算后得到的，并且每项原始数据的属性都会包括用来说明该项指标数据来自哪一个网元设备的资源信息，通过对发现异常的指标数据进行拆分，并根据拆分后得到的原始数据的属性可关联定位到该异常具体出现在哪一个网元设备。

2.根据权利要求1所述的方法，其特征在于，该方法还包括：

如果确定采集到的性能数据不存在异常，则根据预设的各项指标的基线范围对所述性能数据中的各项指标数据进行监控，并对监控到的超出对应基线范围的指标数据进行预警。

3.根据权利要求2所述的方法，其特征在于，该方法还包括：

将超出对应基线范围的指标数据拆分成原始数据，并根据所述原始数据的资源关系定位与所述异常关联的异常点；

将所述关联的异常点以多媒体的形式展示。

4.根据权利要求1-3中任意一项所述的方法，其特征在于，该方法还包括：

根据巡检规则检查ESB的运行状态，当检查到运行状态异常时，发出告警；

根据通道阈值检查ESB各个采集通道的拥塞程度，当检查到采集通道拥塞时，暂停所述采集通道的采集任务，减轻所述采集通道上的负载并上报通知。

5.根据权利要求4所述的方法，其特征在于，该方法还包括：

根据ESB的运行状态和各个采集通道的采集负载定位ESB运行过程中的故障类型；

根据定位的故障类型和预设的故障类型与指令匹配表中确定用于解决该故障类型的修复指令；

运行所述确定的修复指令修复该故障类型对应的故障。

6.根据权利要求5所述的方法，其特征在于，该方法还包括：

对修复后的采集通道验证该修复后的采集通道是否可用；

若验证可用，则发送确认信息。

7.一种基于ESB的数据管控装置，其特征在于，包括：

采集模块，用于采集网元设备的性能数据；

异常确定模块，用于根据预设的元数据模型确定采集到的性能数据属性是否存在异常；

关联分析模块，用于当异常确定模块确定采集到的性能数据的属性存在异常时，将所述性能数据中的各项指标数据拆分成原始数据，并根据所述原始数据的资源关系定位与所述异常关联的异常点；

展示模块，用于将所述关联的异常点以多媒体的形式展示；

其中，原始数据为服务器采集网元设备所获得的各项指标的性能数据；

性能数据中的各项指标数据包括服务器采集网元设备所获得的各种指标的性能数据和根据该采集到的各项指标的性能数据计算得到的各项指标的数据；

每项指标数据都是由多个原始数据计算后得到的，并且每项原始数据的属性都会包括用来说明该项指标数据来自哪一个网元设备的资源信息，通过对发现异常的指标数据进行拆分，并根据拆分后得到的原始数据的属性可关联定位到该异常具体出现在哪一个网元设备。

8.根据权利要求7所述的装置，其特征在于，所述关联分析模块，还用于当异常确定模块确定采集到的性能数据不存在异常，则根据预设的各项指标的基线范围对所述性能数据中的各项指标数据进行监控；并对监控到的超出对应基线范围的指标数据进行预警。

9.根据权利要求8所述的装置，其特征在于，所述关联分析模块，还用于将超出对应基线范围的指标数据拆分成原始数据，并根据所述原始数据的资源关系定位与所述异常关联的异常点；

所述展示模块，还用于将所述关联的异常点以多媒体的形式展示。

10.根据权利要求7-9中任意一项所述的装置，其特征在于，该装置还包括：

检查模块，用于根据巡检规则检查ESB的运行状态，当检查到运行状态异常时，发出告警；以及根据通道阈值检查ESB各个采集通道的拥塞程度，当检查到采集通道拥塞时，暂停所述采集通道的采集任务，减轻所述采集通道上的负载并上报通知。

11.根据权利要求10所述的装置，其特征在于，该装置还包括：

修复模块，用于根据ESB的运行状态和各个采集通道的采集负载定位ESB运行过程中的故障类型；并根据定位的故障类型和预设的故障类型与指令匹配表中确定用于解决该故障类型的修复指令；再运行所述确定的修复指令修复该故障类型对应的故障。

12.根据权利要求11所述的装置，其特征在于，该装置还包括：

验证模块，用于对修复后的采集通道验证该修复后的采集通道是否可用；若验证可用，则发送确认信息。