CN114389960B - 一种网络业务性能采集上报的方法和系统 - Google Patents

Abstract

本发明涉及通信领域，特别是涉及一种网络业务性能采集上报的方法和系统。主要包括：根据每个业务对应的性能描述模型，获取每个业务的性能对象；在同族业务的性能对象中选举出一个根源对象，以同族其它业务的性能对象为衍生对象；每次进行性能采集时，根据根源对象和衍生对象的关联关系，对衍生对象的上报内容进行拦截与合并，将合并后的上报内容进行上报。本发明可以通过以模型化的性能对象为单位整体采集和存储性能数据，并对同族业务的性能数据进行去重整合，减少了资源和效率损耗，同时避免了性能项重复。

Description

一种网络业务性能采集上报的方法和系统

【技术领域】

本发明涉及通信领域，特别是涉及一种网络业务性能采集上报的方法和系统。

【背景技术】

在网络通信系统运行过程中，网管和telemetry工具等会向网元设备下发性能采集任务，采集任务主要由网元上的主控盘发起，由各个单盘启动性能采集和计算，经过处理后的数据再经由主控盘统一收集汇总后上报给网管等。

各设备向网管上报性能时，由不同业务对应的私有性能描述模型来装载数据。每个性能描述模型中包含一组指标项组成。目前的上报方式中，每个设备需要逐项采集性能描述模型每个性能项的数据，并分别进行上报。该技术方案中，设备内部逐项采集数据，需要对每项数据单独进行存储和管理，对设备资源占用过大。进一步的，当设备中同族业务同时上报性能数据时，存在部分相同的性能项，会在网管上产生重复的性能显示项，对网络管理产生负面干扰，虽然目前技术方案中可以通过逐项展开的方式解决重复显示的问题，但该方法办法在时间和空间上均占用较多资源。

鉴于此，如何克服现有技术所存在的缺陷，解决目前网络业务性能采集上报时占用资源较多且性能项重复的现象，是本技术领域待解决的问题。

【发明内容】

针对现有技术的以上缺陷或改进需求，本发明解决了现有业务性能采集上报时占用资源较多且存在重复项的问题。

本发明实施例采用如下技术方案：

第一方面，本发明提供了一种网络业务性能采集上报的方法，具体为：根据每个业务对应的性能描述模型，获取每个业务的性能对象；在同族业务的性能对象中选举出一个根源对象，以同族其它业务的性能对象为衍生对象；每次进行性能采集时，根据根源对象和衍生对象的关联关系，对衍生对象的上报内容进行拦截与合并，将合并后的上报内容进行上报。

优选的，获取每个业务的性能对象，具体包括：获取性能描述模型中每个指标项的原始数据，将性能描述模型中的业务描述和所有指标项的原始数据进行整体编码。

优选的，在同族业务的性能对象中选举出一个根源对象，具体包括：统计每个性能描述模型与同族中其它业务的性能描述模型中重复的性能项的数量，将与其它性能描述模型重复的性能项数量总和最多的性能描述模型对应的性能对象作为根源对象。

优选的，对衍生对象的上报内容进行拦截与合并，具体包括：标记每个衍生对象上报内容中各性能项的有效性，对衍生对象中无效的性能项进行拦截，将衍生对象中有效的性能项进行合并。

优选的，标记每个衍生对象上报内容中各性能项的有效性，具体包括：逐个对比每个衍生对象和根源对象中的性能项，判断性能项是否对应相同；若相同，将该性能项标记为无效上报；若不同，将该性能项标记为有效上报。

优选的，标记每个衍生对象上报内容中各性能项的有效性，具体包括：根据设备需要，为每个设备使用的性能描述模型设置预设无效项，将性能对象中的预设无效项标记为无效上报。

优选的，为每个衍生对象生成有效性bitmap，bitmap中每个bit对应一个性能项的有效性标记。

优选的，将衍生对象中有效的性能项进行合并，具体包括：对每个采集周期的性能项数据进行累加计算；和/或，使用新采集周期的性能项数据对原性能项数据进行替换；和/或，根据新采集周期的性能项数据和原性能项数据进行即时计算。

优选的，在同族业务的性能对象中选举出一个根源对象，还包括：将性能对象模型以及根源对象和衍生对象的关联关系固化至资源文件，根据资源文件中的信息确认同族业务中的根源对象和衍生对象。

另一方面，本发明提供了一种网络业务性能采集上报的系统，具体为：包括网管系统1、性能采集平台2和网元设备3，其中：每个网管系统1对应至少一个性能采集平台2，性能采集平台根据第一方面中的网络业务性能采集上报的方法，将网元设备3的性能数据合并上报至相应的网管系统1。

与现有技术相比，本发明实施例的有益效果在于：通过以模型化的性能对象为单位整体采集和存储性能数据，并对同族业务的性能数据进行去重整合，减少了资源和效率损耗，同时避免了性能项重复。进一步的，在优选方案中，并使用有效性bitmap和固化的资源文件，进一步提高了资源上报的处理效率。

【附图说明】

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

图1为本发明实施例提供的一种网络业务性能采集上报的方法流程图；

图2为本发明实施例提供的一种网络业务性能采集上报中性能对象存储结构示意图；

图3为本实施例提供的一种网络业务性能采集上报中性能对象合并过程示意图；

图4为本实施例提供的另一种网络业务性能采集上报中性能对象合并过程示意图；

图5为本发明实施例提供的一种网络业务性能采集上报的系统架构示意图；

图6为本发明实施例提供的一种网络业务性能采集上报的系统架构中性能采集平台的架构示意图；

图7为使用本发明提供的一种网络业务性能采集上报的系统进行性能采集上报的流程图；

图8为本发明实施例提供的一种网络业务性能采集上报的系统架构中性能采集平台各设备的装置架构示意图。

【具体实施方式】

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

本发明是一种特定功能系统的体系结构，因此在具体实施例中主要说明各结构模组的功能逻辑关系，并不对具体软件和硬件实施方式做限定。

此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。下面就参考附图和实施例结合来详细说明本发明。

实施例1：

在进行每个业务的性能采集时，需要业务相关的各设备进行上报。设备内的每个单盘中存储了同一份性能模型资源文件，模型资源文件中包含了每个业务的性能描述模型。每个性能描述模型都由业务描述和一组业务指标项组成。其中，业务描述(resouce)具体包括：业务类型(type)、层次速率(layer-rate)和定位源(workstations key，简写为wskey)等。一组指标项中包含若干个可以量化采集计算的业务指标项(qualifier)，本实施例中业务指标项简称为指标项。在本实施例提供的方案中，采集业务性能数据时，首先从业务侧获取每个指标项的数据，再按照该业务对应的性能描述模型将业务描述和所有指标项按照固定的编码格式进行编码和打包，生成性能对象后再整体进行上报。本实例中，由于不同的性能对象中包含重复项，因此还需要对重复项进行合并后，再将合并后的性能对象进行统一上报。

如图1所示，本发明实施例提供的网络业务性能采集上报的方法具体步骤如下：

步骤101：根据每个业务对应的性能描述模型，获取每个业务的性能对象。

为了对业务性能进行上报，首先需要根据业务的性能描述模型获取业务的模型中每个性能项的原始性能数据，即获取性能描述模型中每个指标项的原始数据。在现有技术中，这些指标项数据会直接进行分别上报，但在本实施例中，将每个业务对应的性能描述模型中的业务描述和所有的性能项作为一个整体进行存储和处理，因此还需要将性能描述模型中的业务描述和所有指标项的原始数据进行整体编码。进行整体编码后的原始数据称为性能对象，性能对象是本实施例提供的方法中进行数据处理、存储、传输的基本单位。在采集性能数据时，每个设备的性能项都以性能对象为单位进行整体上报，在网管层面不需要逐个采集和存储每个设备的所有性能项，而是以每个业务的性能模型作为整体进行采集和存储，并在计算性能数据时利用整体编码使得整个性能对象的数据存储在一段连续的内存地址中，避免频繁地访问不连续地址带来的内存分段和分页访问性能损耗，提高计算过程中的内存访问效率和最终的数据计算速度。

在具体实施中，可以使用各种常用数据结构和数据压缩方式对性能对象中的各数据进行整合和存储。

为了减少存储空间占用、提高数据存储和查找效率，可以将性能对象中的原始数据按性能模型中预设的顺序排列存储于一片连续的内存中，每个业务描述的参数和性能项数值占用一段固定长度的内存。该方式仅需保存每项的数值，通过固定顺序和数据长度对数据结构进行组织，无需保存现有技术中各项独立打包时所需要的项id、项数据类型等描述信息，减少了存储占用的空间。同时，该方式还可以通过简单的通过内存拷贝按模型填充完成数据存储，并通过内存偏移量计算进行数据查找和解析，减少了数据采集过程中的内存开销和传输开销，提高了需上报数据的生产速度，也能提高后续数据处理时的消费速度，整体提高了性能数据采集上报的效率。

具体的，如图2所示，为业务lscm_lsp的性能对象存储结构示意图，对象名称：lscm_lsp和对象id：object_id作为查询标志独立存储，resource中其它信息和性能项pmA、PX_PPS、pmB、RX_DROP等仅保存对应数值并在需要的情况下进行强制类型转换，按照性能描述模型定义的顺序和数据类型逐项进行内存偏移，依次存储在连续的内存段中。按照该规则进行存储时，每个性能项的内存偏移可以通过性能描述模型中数据长度的定义计算能得到。一般使用场景中，为了处理简便且减少空间占用，每个项的数据长度即该项数据类型的长度，例如int类型数据长度为4byte，long类型数据长度为8byte。在某些特性场景中，也可以根据需要增加一些项的数据长度，以存储所需的额外信息。

本实施例提供的方案中，在进行数据采集时一次获取性能对象中所有业务描述和性能项的原始数据，与现有方案相比减少了数据获取和传输的次数、节省了每个性能项单独读取时对应的业务描述信息和项属性信息所需内存开销。并且，现有方案中一次采集后只能计算一个性能项数据，本实施例的方案生成性能对象后，通过内存偏移即可在一次采集计算中完成该对象所有项的处理，提高了处理效率。

步骤102：在同族业务的性能对象中选举出一个根源对象，以同族其它业务的性能对象为衍生对象。

为每个业务设计性能描述模型时，会根据业务特征定制业务描述中的业务类型、层次速率以及定位源。对于多个业务描述完全一致的性能对象，可以认为存在关联关系。本发明实施例中，将存在关联关系的一组业务描述相同的性能对象对应的业务，称为同族业务。同族业务在网管中显示时会包含重复项，因此需要进行合并以去除重复项。在进行存储时，根源对象仅需保存自身对象id；衍生对象除了需要保存自身对象id外，还需保存对应的根源对象id，以及根源项对应的序号和内存偏移等信息。

在本实施例中，为了便于合并，可以在同族性能对象中选举出一个性能对象作为根源对象，将其他性能对象作为衍生对象，将衍生对象与根源对象相同的性能项数据合并至根源对象中。优选的，为了便于合并，可以统计每个性能描述模型与同族中其它业务的性能描述模型中重复的性能项的数量，将与其它性能描述模型重复的性能项数量总和最多的性能描述模型对应的性能对象作为根源对象。例如，现有三个同族的性能对象，分别对应性能描述模型A、B和C，A与B存在3个重复性能项，B与C存在2个重复性能项，A与C存在1个重复性能项，则累加每个性能描述模型与其他所有性能描述模型的性能项重复数，A有4个，B有5个，C有3个，该场景中，选举重复项数最多的B对应的性能对象为根源对象。进一步的，在重复项数量一致时，为了避免冲突，将设计时间最早的性能描述模型对应的性能对象作为根源对象。在上述场景中，若A与其它性能描述模型的性能项重复数总和也是5个，则在AB中设计时间更早的一项对应的性能对象作为根源对象。使用该选举方式，能够尽可能的保证根源对象中包含的性能项是所有需上报的性能对象中性能项最大的公共集合，尽可能的减少步骤103中拦截合并过程中无法合并的性能项数量。

由于需要将根源对象作为上报对象，在某些具体场景中，当衍生对象上报数据时，需要先判断根源对象是否存在。若因根源对象无效等原因导致根源对象不存在，需要先创建根源对象，以完成步骤103中的性能项合并和上报。

步骤103：每次进行性能采集时，根据根源对象和衍生对象的关联关系，对衍生对象的上报内容进行拦截合并，将合并后的上报内容进行上报。

进行同族对象合并时，由于同族对象的业务描述相同，只需保留一份resouce值，并将重复的性能项数据的即时值和累加值合并至根源对象相应的性能项项中，再将合并后的性能项和不重复的性能项共同进行上报，已被合并过的重复性能项数据不进行上报。以下为了描述简便，将根源对象中的重复性能项数据称为根源项，将衍生对象中对应的性能项称为衍生项，将衍生对象中不与根源项重复的性能项称为非衍生项。在进行上报时，将合并后根源项以及非衍生项进行上报，衍生项由于和根源项重复需要与对应的根源项进行合并计算后再进行上报。

为了便于在上报时判断某个性能项是否需要上报，在具体实施时，可以标记每个衍生对象上报内容中各性能项的有效性，将需要上报的根源项和非衍生项标记为有效上报，将不需上报的衍生项标记为无效上报，对衍生对象中无效的性能项进行拦截，将衍生对象中有效的性能项进行合并。

在具体实施中，可以使用各种现有的标记方法对有效性进行标记。在本实施例中，为简化步骤提高效率，可以同时进行判断和标记。逐个对比每个衍生对象和根源对象中的性能项，判断性能项是否对应相同。若相同，表明该性能项为衍生项，无需上报，将该性能项标记为无效上报；若不同，表明该性能项为非衍生项，需要上报，将该性能项标记为有效上报。

为了便于将标记和性能项对应，并减少标记占用的内存资源，在优选方案中，可以使用bitmap结构将每个性能对象的有效性标记进行统一存储和管理。具体的，可以为每个衍生对象生成有效性bitmap，bitmap中每个bit对应一个性能项的有效性标记。具体实施中，有效性标记可以根据实际需要自行定义，为了判定简便且节约存储空间，在优选方案中，可以使用每个bit位的0/1值进行区分。当一个性能对象中的第n个性能项为有效上报时，bitmap中第n位bit值为1，否则为0。为了避免错误上报，每个bit的默认值为为0，当第n个性能项进行计算处理并得到正确的上报数据之后，置bitmap第n位为1表示有效上报，可以上报给网管等上级管理系统进行显示。为所有需上报的对象生成有效性bitmap后，可以方便的获取到所有需上报对象中需要上报的性能项，在进行上报时，只开辟内存用于存储有效上报的项。进一步的，有效性bitmap中的数据还需要根据性能对象数据的变化而更新，与性能对象中每个性能项的当前有效性保持一致，当后续的性能采集过程有新的有效数据产生或者有数据不再有效时，对bitmap中的有效性标记进行同步更新，并重新申请内存来拷贝和存储需要上报的性能项，上报完毕后或拷贝完成后释放旧数据占用的内存。

对性能对象中每个性能项的上报有效性进行确认后，还需要对衍生对象的上报内容进行拦截合并。在性能数据处理计算的一般场景中，性能对象需要周期性采集和上报，每个性能项按其数据的处理方式分为即时类型和累加类型，两种类型的数据性质不同，每个指标项的数据处理过程中需要按其处理类型进行处理。(1)累加类型例如收发包计数等，对每个采集周期的性能项数据进行累加计算，以累加计算的结果作为上报数据。(2)即时类型的数据例如速率等,需要使用新采集周期的性能项数据对原性能项数据进行替换，以替换的方式实时刷新该项的数据作为当前值存储。进一步的对于某些需要根据所有周期值的值进行即时计算的性能项，还需要根据新采集周期的性能项数据和原性能项数据进行即时计算，获取峰谷值和平均值等需要即时计算的值，并将计算结果作为当前值进行存储记录。如使用某个性能项的当前值、峰谷值等，使用最新的当前数据作为上报数据。而在衍生对象的拦截合并场景中，通过不同类型数据相应的合并计算，即可获取到一组同族业务无重复的有效上报数据，完成业务性能上报。

在具体实施中，由于同族性能描述模型中仅存在一个根源对象，但可能存在多个衍生对象，因此，每个采集周期内性能对象采集到的顺序可能不同，故而对衍生对象数据的拦截合并过程也略有不同。(1)当存在先于根源对象采集的衍生对象时，称为衍生先报。在衍生先报的场景下，即时类型的值由衍生项的值进行直接覆盖或即时计算后重新覆盖，本周期内后续到达的根源项和衍生项数据都与即时值当前部分进行累加计算，并使用得到的当前值做相应计算；累加类型的值则一律进行累加。例如：计算峰谷值使用覆盖后的值与历史峰谷值比较重新得出峰谷值，计算平均值时将所有后续根源项和衍生项数据都进行累加后再次平均。(2)当所有衍生对象都晚于根源对象采集，称为衍生后报。在衍生后报的场景下，在下一采集周期开始后，即时值当前部分只由根源项进行覆盖，衍生项的即时值当前部分统一累加进根源项即时值当前部分，即时值中的峰谷值与平均值以及累计值的计算逻辑都与衍生先报相同。进一步的，在衍生后报的情况下，合并计算使用的内存空间由根源对象存储节点负责开辟，只用于保留合并计算后根源项的数据，衍生项的数据则不再开辟内存空间保存，以减少内存资源占用。

在本实施例的具体实施过程中，对于每个业务来说，由于业务所使用的设备和关注的性能项固定，性能描述模型保持不变。对于同族业务，由于每个业务的性能描述模型固定，性能模型中包含的性能项也固定，因此每次进行性能采集时所产生的根源对象和衍生对象也一致。在本实施例的实际实施过程中，步骤101和步骤102的选举根源对象过程可以在开发阶段完成，或在加入新业务、新设备或新性能项时再次进行选举重新确定该同族业务的根源对象，在每次进行性能采集时只需直接根据已选举出的根源对象进行步骤103中的拦截合并上报过程。使用该方式可以避免重复进行选举，提高业务性能采集上报的效率。

经过本实施例中提供的步骤101-步骤103后，即可完成多个同族业务的性能数据采集、合并和上报，为网管等系统提供易于使用的无重复性能数据，并减少了性能数据采集上报时的资源占用，提高了性能数据采集的效率。

进一步的，由于性能描述模型通常为预先设计确定，在进行性能数据采集上报时不会变化。因此，为了提升步骤102中获取根源对象和衍生对象关联关系的效率，在初次录入性能描述模型或性能描述模型发生变更时，可以将性能对象模型以及根源对象和衍生对象的关联关系固化至资源文件，根据资源文件中的信息确认同族业务中的根源对象和衍生对象。具体的，性能描述模型设计完成后，与同族其它业务的性能描述模型相对照，得到该性能对象对应的根源对象的相关信息，如根源对象id、根源项序号、根源项存储时的偏移值等。再将这些信息与本性能描述模型数据的其它信息，如对象名称、对象id、resouce数据、每个性能项的名称、数据类型、长度、计算处理方式等通过资源文件形式保存在设备的每个盘中。为了将衍生项和根源项对应，每个衍生项还需要额外携带其根源的对象id、项数据存储计算时的根源项在根源对象中的序号以及内存偏移信息，同时依然保留自身的项id、项名称、数据类型、序号等已有的信息。具体的，资源文件可以保存为xml、ini等具有固定存储规则且易于解析读取的格式。进一步的，由于不同设备上运行的业务不同，因此每个进行上报时根源对象和衍生对象所使用的性能描述模型和对应关系可能不同，因此不同设备可以有各自配套的资源文件，一套资源文件可以有多个文件，比如专门负责采集上层业务如vpn性能的组件和专门负责采集硬件性能如cpu内存的组件可以拥有各自的资源文件，一个资源文件中可以存储多个性能对象的模型。在进行首次性能上报前，加载解析资源文件获取到本设备上各业务描述模型对应的关联信息，并在每次上报时根据关联信息快速简便的获取根源对象和衍生对象，以及根源项和对应的衍生项。

进一步的，为了避免resource相同的不同性能描述模型中存在的性能项冲突，存在多个不同资源文件时，还需要自动校验每个资源文件中resource相同的性能描述模型，并消除它们之间的性能项顺序等差异，以保证源自不同采集组件的相同性能对象数据在后续的项数据计算过程在不会出现偏差和内存访问异常等问题。进一步的，为了保持性能描述模型的一致性，当某一个资源文件中的性能描述模型消除冲突后，还需要检测其它组件上相同的性能描述模型，将本组件上性能描述模型的修改自动同步到相关组件中。需注意的是，为了避免修改后的性能描述模型之间产生冲突，初始版本的所有资源文件需由模型设计者确认无异常，并设定修改约束条件，以避免后续使用过程中修改性能描述模型时未对所有组件上的模型进行修改，导致引入性能项合并计算的冲突和存储内存处理问题。

进一步的，不同的设备对同一个业务的性能指标关注点不同。例如：接口的性能描述模型中包含一百多个性能项，但是，流量交换机更关心其中的流量计数速率等，而数通设备除此之外也关心ipv4、ipv6、qos相关的一些指标。为了在提高业务的性能描述模型通用性的前提下减少上报对象冗余，还可以在资源文件中固化每个性能描述模型在不同设备下每个性能项的上报有效性。在实际使用中，可以根据设备需要，为每个设备使用的性能描述模型设置预设无效项，将性能对象中的预设无效项标记为无效上报。在具体使用中，预设无效项的数据可以写入有效性bitmap的对应位中。进行性能数据采集后，预设无效项对应的无效上报和其它不需上报的无效上报同样不被上报。在资源文件中固化预设无效项，在设计性能模型时可以不需关注对象臃肿导致不必要上报的数据占用过多内存的问题，只需根据业务特性进行设计，并根据不同设备的特性设置无效上报即可。

本实施例提供的网络业务性能采集上报的方法，在进行性能采集时以性能对象为单位整体采集、处理和存储，不需要对每个性能项单独进行去重分析，处理效率高、存储空间占用小。将同族业务中的性能项进行合并，上报时不会出现描述信息完全相同但是数据不同的性能数据，后续处理中无需再次对重复的业务性能模型进行去重，便于数据后续处理使用；设计业务的性能描述模型时不需要顾虑与其他模型是否存在性能项重叠，可以将不同业务的性能描述模型设计成完全相同或部分相同。

实施例2：

基于实施例1中提供的网络业务性能采集上报的方法，本实施例中提供了一个该方法在具体使用场景中的实例。

如图3和图4所示，同族业务lscm_lsp、tem_te_lsp、tpoam_vp_lsp为例进行说明，每个性能对象所对应的数据保存在一段连续内存中。

在上述同族业务中，resource由类型、层次速率、定位源组成，且他们的resource值都相同，即类型为361，层次速率为600，定位源wskey为lsp-name＝1，表示他们都是同时在基于名字为1的lsp进行的不同业务上的性能指标采集分析，但是最终对外如网管只呈现出lsp 1的统一信息，而不呈现设备内部具体是何种基于lsp1的业务细节。

根源对象中仅记录自身id：object_id。衍生对象中新增信息记录根源对象的id：root_object，还需记录根源项在根源对象中的序号root_sequence以及内存偏移root_offset。

每个性能对象都有一组性能项，即图中qualifier部分。有效性bitmap中每一bit的数据对应图中qualifier部分的每一格的上报有效性，图中阴影表示该性能项不上报，即意味着bitmap中该位值为0；否则为有效上报，bitmap中该位值为1。

在进行具体合并时，如图3所示，以衍生对象tpoam_lsp和其携带的RX_PPS项为例：tpoam_lsp的对象id为0xc。其对应的根源对象为lscm_lsp，根源对象id为0xa，故tpoam_lsp的root_object记为0xa。tpoam_lsp的RX_PPS则对应到lscm_lsp中相同的RX_PPS，故lscm_lsp中的RX_PPS是tpoam_lsp的RX_PPS的根源项，相应的，tpoam_lsp中的RX_PPS是lscm_lsp的RX_PPS的衍生项。由于lscm_lsp中的RX_PPS前面只有一个项pmA，此处设定pmA的数据类型为int，其长度为4，故tpoam_lsp的RX_PPS中记录其根源项的内存偏移root_offset为4，以方便在对其做合并计算时快速的找到性能项数据存储的内存地址。图3和图4中其余衍生项都需要逐一根据实施例1中步骤103提供的方法进行合并。为了说明简便，图3和图4中的即时性能都只展示了即时值的当前部分，若某个性能项的处理方式不仅仅需要计算当前值，还需要根据当前值对性能项的值进行计算，并对计算后的性能项进行存储记录中时，还需要为后续性能项的内存偏移额外加上扩充的长度，例如需要通过即时计算获取的峰谷值或平均值等。例如：假定pmB的数据类型为int，其长度为4，进行了峰值计算，则其后的项偏移会增加4，以保存计算所得的峰值数据。

将每个衍生项合并至根源项之后，即可对有效上报项进行上报。本实施例中，lsp系列业务的性能采集频率为5秒1次，则每5秒为一个采集周期。图3中为衍生后报，同一周期内衍生对象tpoam_vp_lsp后于根源对象lscm_lsp上报，合并后tpoam_vp_lsp仍有性能项数据为有效上报，需要继续保留该对象的存储。进行有效性判定后，进行上报的性能项为：根源项：合并后的RX_PPS、合并后的RX_DROP；非衍生项：Pm1、Pm4、Pm5、pmA、pmB。图4中为衍生先报：同一周期内衍生对象tem_te_lsp先于根源对象lscm_lsp上报，合并后tem_te_lsp不再有性能项数据为有效上报，不需要继续保留该对象的存储。进行有效性判定后，进行上报的性能项为：根源项：合并后的pmA、合并后的RX_PPS、合并后的pmB、合并后的RX_DROP；不存在需上报的非衍生项。上述过程中，上报的先后顺序仅与被采集到的数据到达计算模块时间有关，与是否完全合并之间并无关联，本实施例中仅采取两种组合举例阐述有效性判定过程。

由本实施例提供的具体实例可知，实施例1中提供的网络业务性能采集上报的方法可以简便快速的将同族业务中的多个性能对象进行合并上报，避免了现有上报方式中每个性能项独立上报所造成的处理繁琐、占用资源较多、性能项重复等问题。

实施例3：

在上述实施例1至实施例2提供的网络业务性能采集上报的方法的基础上，本发明还提供了一种可用于实现上述方法的网络业务性能采集上报的系统。系统包括网管系统1、性能采集平台2和网元设备3，其中：每个网管系统1对应至少一个性能采集平台2，性能采集平台根据实施例1或实施例2中的网络业务性能采集上报的方法，将所有网元设备3的性能数据合并上报至相应的网管系统1。

如图5所示，为网络业务性能采集上报系统的结构示意图。在具体实施中，网管系统1可以使用O2000、U2000、Snmp、Controller等，也可以根据需要选择其它适当的网管系统。网元设备3为SDA、DDA等，也可以为实际使用的其它设备。

如图6所示，为性能采集平台2的具体结构，图中黑色虚线表示系统或组件的边界，实线为数据流。每个性能采集平台2中都包含多个单盘，其中一个单盘为集中式主控，其余单盘为业务盘，为了便于查看。其中，集中式主控包括NMU、IFMGR、TLM、L2VPN等，还包括PM_SERVER，实施例1和实施例2中提供的网络业务性能采集上报的方法的主要过程由集中式主控完成，为了便于数据读取，资源文件也可以保存在集中式主控上。业务盘包括PM_CLENT、DPO_GATH、DHC等，用于完成其它网络业务。

如图7所示，性能采集平台2完成实施例1和实施例2中提供的网络业务性能采集上报的方法的具体过程时，可以使用以下步骤。

步骤201：网管系统1中的业务组件通过PM_SERVER请求网元设备3需要上报的各种类型的性能数据。为了不影响正常的业务处理过程，在实际使用中可以采用异步查询的方式进行数据上报请求。

步骤202：PM_SERVER组件通过aim发起异步查询，PM_CLIENT通过pcs应答数据并回复aim结束，完成当前性能查询。

步骤203：PM_SERVER通过aim发起性能清零，PM_CLIENT通过pcs转发性能清零到pm_lib。

步骤204：PM_SERVER通过aim发起性能屏蔽，PM_CLIENT屏蔽性能上报。

步骤205：PM_SERVER通过aim发起性能订阅，PM_CLIENT实时上报被订阅的性能。

步骤206：PM_SERVER通过pcs下发秒级性能开关，PM_CLIENT通过pcs转发到pm_lib，pm_lib根据开关参数采集秒级数据推送到PM_CLIENT，PM_CLIENT实时上送秒级性能到PM_SERVER。

步骤207：PM_CLIENT实时计算各个业务上送的性能对象，按照实施例1和实施例2中提供的方法进行拦截合并，并在每个预设上报周期上送一次历史性能到PM_SERVER。为了提高采集上报效率，实时计算出的需上报的当前性能对象分布式存储在PM_CLIENT中，在按照步骤202的异步查询方式进行上送。在某个具体实施场景中，为了平衡正常网络业务的处理效率和性能数据的及时上报，上报周期可以设置为10-30分钟，优选为15分钟。

步骤208：pm_lib开启1s级定时器，按采集周期和性能描述模型采集性能设备3中每个业务的性能对象，并以性能对象为单位上送性能数据。

经过步骤201-步骤208，性能采集平台2使用了实施例1和实施例2中提供的方法，将网元设备3的性能数据进行采集和整合，并上报至网管系统1，使网管系统1无需处理每个网元设备3的性能数据，提高了业务性能数据采集的效率和采集结果的易读性。

如图8所示，是本发明实施例性能采集平台2中各设备的装置架构示意图。各设备中分别包括一个或多个处理器11以及存储器12。其中，图8中以一个处理器11为例。

处理器11和存储器12可以通过总线或者其他方式连接，图8中以通过总线连接为例。

存储器12作为一种网络业务性能采集上报方法非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如实施例1至实施例2中的网络业务性能采集上报方法。处理器11通过运行存储在存储器12中的非易失性软件程序、指令以及模块，从而执行网络业务性能采集上报的装置的各种功能应用以及数据处理，即实现实施例1至实施例2的网络业务性能采集上报的方法。

存储器12可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器12可选包括相对于处理器11远程设置的存储器，这些远程存储器可以通过网络连接至处理器11。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

程序指令/模块存储在存储器12中，当被一个或者多个处理器11执行时，执行上述本实施例中描述的各设备相应功能步骤，例如，执行以上描述的图1、图6所示的各个步骤。

本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(Read Only Memory，简写为：ROM)、随机存取存储器(Random AccessMemory，简写为：RAM)、磁盘或光盘等。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (7)

1.一种网络业务性能采集上报的方法，其特征在于：

根据每个业务对应的性能描述模型，获取性能描述模型中每个指标项的原始数据，将性能描述模型中的业务描述和所有指标项的原始数据进行整体编码，以整体编码作为每个业务的性能对象；

统计每个性能描述模型与同族中其它业务的性能描述模型中重复的性能项的数量，将与其它性能描述模型重复的性能项数量总和最多的性能描述模型对应的性能对象作为根源对象，以同族其它业务的性能对象为衍生对象；

每次进行性能采集时，根据根源对象和衍生对象的关联关系，标记每个衍生对象上报内容中各性能项的有效性，对衍生对象中无效的性能项进行拦截，将衍生对象中有效的性能项进行合并，将合并后的上报内容进行上报。

2.根据权利要求1所述的网络业务性能采集上报的方法，其特征在于，所述标记每个衍生对象上报内容中各性能项的有效性，具体包括：

逐个对比每个衍生对象和根源对象中的性能项，判断性能项是否对应相同；

若相同，将该性能项标记为无效上报；

若不同，将该性能项标记为有效上报。

3.根据权利要求2所述的网络业务性能采集上报的方法，其特征在于，所述标记每个衍生对象上报内容中各性能项的有效性，具体包括：

根据设备需要，为每个设备使用的性能描述模型设置预设无效项，将性能对象中的预设无效项标记为无效上报。

4.根据权利要求2所述的网络业务性能采集上报的方法，其特征在于，还包括：

为每个衍生对象生成有效性bitmap，bitmap中每个bit对应一个性能项的有效性标记。

5.根据权利要求1所述的网络业务性能采集上报的方法，其特征在于，所述将衍生对象中有效的性能项进行合并，具体包括：

对每个采集周期的性能项数据进行累加计算；

和/或，使用新采集周期的性能项数据对原性能项数据进行替换；

和/或，根据新采集周期的性能项数据和原性能项数据进行即时计算。

6.根据权利要求1所述的网络业务性能采集上报的方法，其特征在于，在同族业务的性能对象中选举出一个根源对象，包括：

将性能对象模型以及根源对象和衍生对象的关联关系固化至资源文件，根据资源文件中的信息确认同族业务中的根源对象和衍生对象。

7.一种网络业务性能采集上报的系统，其特征在于，包括网管系统（1）、性能采集平台（2）和网元设备（3），其中：

每个网管系统（1）对应至少一个性能采集平台（2），性能采集平台根据权利要求1-6中任一项所述的网络业务性能采集上报的方法，将网元设备（3）的性能数据合并上报至相应的网管系统（1）。