网元监测方法和装置与流程

本发明涉及网络管理领域，尤其涉及一种网元监测方法和装置。

背景技术：

在网络管理中，当需要监测网元是否正常时，通常都采用轮询的方法。所谓轮询，是网管系统定期的向其网元发送查询报文，当所述网元有应答报文返回给所述网管系统时，说明所述网元正常；但是如果超过一定时间，所述网管系统没有接收到所述网元的应答报文，即所述网元没有返回响应，则说明所述网元出现故障。当网管系统中的网元出现故障时，要求网管系统能够快速发现网元故障，但是当所述网管系统管理的网元规模较大时，如达到几千上万个的时候，要求所述网管系统快速发现网元故障是很难做到。

常见的轮询方法是利用SNMP(Simple Network Management Protocol，简单网络管理协议)依次对网管系统中的各个网元状态进行轮询，即对一个网元发送SNMP GET请求，等待所述网元返回响应或者超时后，再对下一个网元采取同样办法进行轮询。假如一个网元轮询平均时间为t，网元总数为n，那么网管系统中网元轮询一遍的时间为nt，当n值达到几千的时候，轮询的总时间就会很长。现有的改进办法是采用多线程并发去轮询。若线程数为m，那么轮询的总时间为(nt/m)，在n值和t值一定的情况下，为缩短轮询时间会尽量增大m值，即增加线程数。但是增加线程就需要更多的系统资源，需要更高性能的硬件支持。

上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

技术实现要素：

本发明的主要目的在于提供一种网元监测方法及装置，解决现有轮询技术轮询时间长，网管在轮询过程中线程开销大的技术问题。

为实现上述目的，本发明提供的一种网元监测方法，包括步骤：

当侦测到开始轮询任务的指令时，向需要轮询的网元依次发送预设请求，以供所述网元根据所述预设请求返回响应；

判断是否接收到网元返回的响应；

当接收到所述响应时，根据所述响应的标识信息判定对应的网元正常。

优选地，所述当侦测到开始轮询任务的指令时，向需要轮询的网元依次发送预设请求，以供所述网元根据所述预设请求返回响应的步骤之后，还包括将被发送过所述预设请求的网元的标识信息添加到超时队列中。

优选地，所述当接收到所述响应时，根据所述响应的标识信息判定对应的网元正常的步骤之后，还包括：

将正常网元对应的标识信息移出所述超时队列；

判断所述超时队列中的网元的标识信息个数是否为零；

若所述超时队列中网元的标识信息个数不为零，则判断是否已发送预设次数的预设请求给所述标识信息对应的网元；

若已发送预设次数的预设请求给所述标识信息对应的网元，则判定所述网元故障，将所述网元的标识信息移出所述超时队列。

优选地，所述若所述超时队列中网元的标识信息个数不为零，则判断是否已发送预设次数的预设请求给所述标识信息对应的网元的步骤之后，还包括：

若未发送预设次数的预设请求给所述标识信息对应的网元，则向所述标识信息对应的网元继续发送所述预设请求。

优选地，所述当侦测到开始轮询任务的指令时，向需要轮询的网元依次发送预设请求，以供所述网元根据所述预设请求返回响应的步骤包括：

当侦测到开始轮询任务的指令时，根据所述指令向需要轮询的网元依次发送预设个数的预设请求；

在等待预设时间后，继续向需要轮询的网元依次发送预设个数的预设请求。

此外，为实现上述目的，本发明还提供一种网元监测装置，所述网元监测装置包括：

第一发送模块，用于当侦测到开始轮询任务的指令时，向需要轮询的网 元依次发送预设请求，以供所述网元根据所述预设请求返回响应；

第一判断模块，用于判断是否在接收到网元返回的响应；

第一判定模块，用于当接收到所述响应时，根据所述响应的标识信息判定对应的网元正常。

优选地，所述网元监测装置还包括添加模块，用于将被发送过所述预设请求的网元的标识信息添加到超时队列中。

优选地，所述网元监测装置还包括：

移出模块，用于将正常网元对应的标识信息移出所述超时队列；

第二判断模块，用于判断所述超时队列中网元的标识信息个数是否为零；

第三判断模块，用于若所述超时队列中网元的标识信息个数不为零，则判断是否已发送预设次数的预设请求给所述标识信息对应的网元；

第二判定模块，用于若已发送预设次数的预设请求给所述标识信息对应的网元，则判定所述网元故障，将所述网元的标识信息移出所述超时队列。

优选地，所述网元监测装置还包括第二发送模块，用于若未发送预设次数的预设请求给所述标识信息对应的网元，则向所述标识信息对应的网元继续发送所述预设请求。

优选地，所述第一发送模块包括：

第一发送单元，用于当侦测到开始轮询任务的指令时，根据所述指令向需要轮询的网元依次发送预设个数的预设请求；

第二发送单元，用于在等待预设时间后，继续向需要轮询的网元依次发送预设个数的预设请求。

本发明通过网管向需要轮询的网元依次发送预设请求，当网元接收到所述预设请求之后返回响应，所述网管接收到所述响应之后，根据所述响应的标识信息判定对应的网元正常。即网管在向一个网元发送请求后，不必等到其返回响应就开始对下一个网元发送请求。减少了网管轮询的时间和降低了网管在轮询过程中线程的开销。

附图说明

图1为本发明网元监测方法第一实施例的流程示意图；

图2为本发明实施例中当侦测到开始轮询任务的指令时，向需要轮询的网 元依次发送预设请求，以供所述网元根据所述预设请求返回响应的一种流程示意图；

图3为本发明网元监测方法第二实施例的流程示意图；

图4为本发明网元监测装置第一实施例的功能模块示意图；

图5为本发明实施例中第一发送模块的一实施例的细化功能模块示意图；

图6为本发明网元监测装置第二实施例的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例的主要解决方案是：当侦测到开始轮询任务的指令时，向需要轮询的网元依次发送预设请求，以供所述网元根据所述预设请求返回响应；判断是否在接收到网元返回的响应；当接收到所述响应时，根据所述响应的标识信息判定对应的网元正常。通过网管向需要轮询的网元依次发送预设请求，当网元接收到所述预设请求之后返回响应，所述网管接收到所述响应之后，根据所述响应的标识信息判定对应的网元正常。即网管在向一个网元发送请求后，不必等到其返回响应就开始对下一个网元发送请求。减少了网管轮询的时间和降低了网管在轮询过程中线程的开销。

由于在现有的网元监测方法中，网管在对一个网元发送SNMP GET请求后，要等待所述网元返回响应或者所述请求超时后，再向下一个网元发送SNMP GET请求，导致网管轮询时间长，线程开销大。

基于上述问题，本发明提供一种网元监测方法。

参照图1，图1为本发明网元监测方法第一实施例的流程示意图。

在本实施例中，所述网元监测方法包括：

步骤S10，当侦测到开始轮询任务的指令时，向需要轮询的网元依次发送预设请求，以供所述网元根据所述预设请求返回响应；

网管根据其网元的类型创建不同的轮询任务，并为每个轮询任务设置一个对应的轮询周期。当轮询周期到时，即所述网管侦测到开始轮询任务的指令时，启动轮询任务，向需要轮询的网元依次发送预设请求，即所述网管向一个网元发送预设请求后，不用等到所述网元根据所述预设请求返回响应就开始向下一个网元发送预设请求。所述网元的类型可以根据其使用的网络来划分，如将使用2G网络的网元放入一个表中，将使用3G网络的网元放入一个表中，使用3G网络的网元放入一个表中，为每一个表都设置一种轮询任务，每一种轮询任务对应一个轮询周期，也可以根据所述网元的功能、用途等进行划分。所述轮询周期的设定由所述网管管理的网元规模和其所在的网络状况而定。如所述轮询周期可以设定为一分钟，即每隔一分钟就对对应的轮询任务轮询一次，每个轮询任务都对应着有一个定时器，用来监测是否到达轮询周期的时间。如当上一次轮询任务过去一分钟之后，所述网管通过所述定时器启动轮询任务。所述预设请求包括但不限于SNMP GET请求。

所述网管执行轮询任务只要查询所述网元的一个简单的变量，如查询sysName，所述sysName是用于表列、变量以及用于存储对象名的存储过程参数。如所述网管查询所述网元sysName时发送的协议数据单元内容为类型TYPE：0；请求标识信息Request ID：全局唯一ID值；错误状态error status：0；错误指标error index：0；变量绑定Variable-Bindings：.1.3.6.1.2.1.1.5.0。

步骤S20，判断是否接收到网元返回的响应；

步骤S30，当接收到所述响应时，根据所述响应的标识信息判定对应的网元正常。

所述网管判断是否接收到其网元根据其发送的预设请求返回的响应。当所述网管管理的网元正常时，所述网元在接收到所述网管发送的预设请求时，会返回对应的响应给所述网管。当所述网管接收到所述网元返回的响应时，根据所述响应的标识信息判定对应的网元正常。如当所述网管接收到所述网元根据所述SNMP GET请求返回的SNMP GET响应，则所述SNMP响应的协议数据单元的内容为TYPE：0；Request ID：全局唯一ID值；error status：无错误noError；error index：0；Variable-Bindings：.1.3.6.1.2.1.1.5.0：sysName。

所述网元返回的SNMP GET响应中的请求标识符Request ID与所述网管发送的SNMP GET请求中的Request ID是一样的，所述网管就是根据所述 Request ID来确定所述SNMP GET响应是哪个网元发送过来的。

本实施例通过网管向需要轮询的网元依次发送预设请求，当网元接收到所述预设请求之后返回响应，所述网管接收到所述响应之后，根据所述响应的标识信息判定对应的网元正常。即网管在向一个网元发送请求后，不必等到其返回响应就开始对下一个网元发送请求。减少了网管轮询的时间和降低了网管在轮询过程中线程的开销。

参照图2，图2为本发明实施例中当侦测到开始轮询任务的指令时，向需要轮询的网元依次发送预设请求，以供所述网元根据所述预设请求返回响应的一种流程示意图。所述步骤S10包括：

步骤S11，当侦测到开始轮询任务的指令时，根据所述指令向需要轮询的网元依次发送预设个数的预设请求；

步骤S12，在等待预设时间后，继续向需要轮询的网元依次发送预设个数的预设请求。

当网管所管理的网元的轮询周期到来时，即侦测到要开始轮询任务的指令时，所述网管根据所述指令向需要轮询的网元依次发送预设个数的预设请求，当所述预设个数的预设请求发送完毕之后，等待预设时间，继续向需要轮询的网元发送预设个数的预设请求。如所述网管根据所述指令向需要轮询的网元依次发送预设个数的SNMP GET请求，当所述预设个数的SNMP GET请求发送完成之后，等待预设时间。所述网管在等待预设时间之后，继续向需要轮询的网元依次发送预设个数的SNMP GET请求。所述预设个数和预设时间根据UDP(User Datagram Protocol，用户数据协议报)协议栈处理数据的能力来设置，因为SNMP是基于UDP的，当所述网管发送的SNMP GET请求个数太多时，所述UDP协议栈会处理不过来，可能会造成一些SNMP GET请求数据包的丢失，所以需要等待预设时间之后，所述网管才继续向需要轮询的网元依次发送预设个数的SNMP GET请求。如所述预设个数为10个，预设时间为20ms。即所述网管在侦测到开始轮询任务的指令时，根据所述指令向需要轮询的网元依次发送10个SNMP GET请求，在发送完10个SNMP GET请求之后，等待20ms，保证所述10个SNMP GET请求发送完毕之后，继续向需要轮询的网元依次发送10个SNMP GET请求。

本实施例通过在网管依次向需要轮询的网元发送预设个数的预设请求之后，等待预设时间，才继续向需要轮询的网元依次发送预设个数的预设请求，以防在传输预设请求数据包的过程中造成数据包的丢失，保证了每次要发送的请求都发送出去，提高了网元监测方法的准确度。

参照图3，图3为本发明网元监测方法第二实施例的流程示意图，基于第一实施例提出本发明网元监测方法第二实施例。

在本实施例中，步骤S10之后，还包括：

步骤S40，将被发送过所述预设请求的网元的标识信息添加到超时队列中；

进一步地，步骤S30之后，还包括：

步骤S50，将正常网元对应的标识信息移出所述超时队列；

步骤S60，判断所述超时队列中网元的标识信息个数是否为零；

步骤S70，若所述超时队列中网元的标识信息个数不为零，则判断是否已发送预设次数的预设请求给所述标识信息对应的网元；

当网管向其网元发送预设请求之后，将被发送过所述预设请求的网元的标识信息添加到其超时队列中，并将正常网元对应的标识信息移出所述超时队列。所述网管定时检测其超时队列中网元的标识信息个数，判断所述超时队列中网元的标识信息个数是否为零。即所述网管通过其定时器在间隔一定的时间段后，检测其超时队列中网元的标识信息个数，如每间隔30秒钟检测一次其超时队列里面的网元的标识信息个数。若所述网管的超时队列中的网元的标识信息个数为零，则说明本次轮询任务中没有出现故障的网元，全部都是正常的网元。若所述网管发现所述超时队列中的网元的标识信息个数不为零时，则表示所述超时队列中的网元在超时时间内没有返回响应给所述网管。如当所述超时队列中的网元的标识信息在超时时间之后还没有被移出超时队列，即所述网管没有接收到所述网元的返回响应，则表示所述网元超时。所述超时时间是所述网管在发送所述预设请求到接收到所述网元的响应的时间，如果当前网络较差时，超时时间会长一点，但是通常情况下网络传输是很快的，一般3秒时间就足够了。若所述网管的超时队列中网元的标识信息个数不为零，则进一步判断是否已发送过预设次数的预设请求给所述超时队 列中标识信息对应的网元。

步骤S80，若已发送预设次数的预设请求给所述标识信息对应的网元，则判定所述网元故障，将所述网元的标识信息移出所述超时队列；

步骤S90，若未发送预设次数的预设请求给所述标识信息对应的网元，则向所述标识信息对应的网元继续发送所述预设请求。

若所述网管已经发送了预设次数的预设请求给所述超时队列中标识信息对应的网元，则判定所述网元故障，将所述网元的标识信息移出所述超时队列。若所述网管未发送预设次数的预设请求给所述超时队列中标识信息对应的网元，则向所述网元继续发送所述预设请求，直到达到预设次数。所述预设次数可以根据需要设置，如可以设置为1次，2次，3次等，优选地，设置为2次。如当所述网管发现超时队列里存在网元的标识信息，则进一步判断是否发送过两次SNMP GET请求给所述超时队列中标识信息对应的网元。若所述网管已经发送过两次SNMP GET请求给所述超时队列中标识信息对应的网元，则将所述网元的标识信息移出所述超时队列，判定所述网元故障。

本实施例通过当网管的超时队列中网元的标识信息个数不为零时，进行多次发送请求到所述超时队列中的标识信息对应的网元，排除所述请求在传输过程丢失的情况，提高了网元监测方法的准确度。

本发明进一步提供一种网元监测装置。

参照图4，图4为本发明网元监测装置第一实施例的功能模块示意图。

在本实施例中，所述网元监测装置包括：

第一发送模块10，用于当侦测到开始轮询任务的指令时，向需要轮询的网元依次发送预设请求，以供所述网元根据所述预设请求返回响应；

网管根据其网元的类型创建不同的轮询任务，并为每个轮询任务设置一个对应的轮询周期。当轮询周期到时，即所述网管侦测到开始轮询任务的指令时，启动轮询任务，向需要轮询的网元依次发送预设请求，即所述网管向一个网元发送预设请求后，不用等到所述网元根据所述预设请求返回响应就开始向下一个网元发送预设请求。所述网元的类型可以根据其使用的网络来划分，如将使用2G网络的网元放入一个表中，将使用3G网络的网元放入一个表中，使用3G网络的网元放入一个表中，为每一个表都设置一种轮询任务， 每一种轮询任务对应一个轮询周期，也可以根据所述网元的功能、用途等进行划分。所述轮询周期的设定由所述网管管理的网元规模和其所在的网络状况而定。如所述轮询周期可以设定为一分钟，即每隔一分钟就对对应的轮询任务轮询一次，每个轮询任务都对应着有一个定时器，用来监测是否到达轮询周期的时间。如当上一次轮询任务过去一分钟之后，所述网管通过所述定时器启动轮询任务。所述预设请求包括但不限于SNMP GET请求。

所述网管执行轮询任务只要查询所述网元的一个简单的变量，如查询sysName，所述sysName是用于表列、变量以及用于存储对象名的存储过程参数。如所述网管查询所述网元sysName时发送的协议数据单元内容为类型TYPE：0；请求标识信息Request ID：全局唯一ID值；错误状态error status：0；错误指标error index：0；变量绑定Variable-Bindings：.1.3.6.1.2.1.1.5.0。

第一判断模块20，用于判断是否接收到网元返回的响应；

第一判定模块30，用于当接收到所述响应时，根据所述响应的标识信息判定对应的网元正常。

所述网管判断是否接收到其网元根据其发送的预设请求返回的响应。当所述网管管理的网元正常时，所述网元在接收到所述网管发送的预设请求时，会返回对应的响应给所述网管。当所述网管接收到所述网元返回的响应时，根据所述响应的标识信息判定对应的网元正常。如当所述网管接收到所述网元根据所述SNMP GET请求返回的SNMP GET响应，则所述SNMP响应的协议数据单元的内容为TYPE：0；Request ID：全局唯一ID值；error status：无错误noError；error index：0；Variable-Bindings：.1.3.6.1.2.1.1.5.0：sysName。所述网元返回的SNMP GET响应中的请求标识符Request ID与所述网管发送的SNMP GET请求中的Request ID是一样的，所述网管就是根据所述Request ID来确定所述SNMP GET响应是哪个网元发送过来的。

本实施例通过网管向需要轮询的网元依次发送预设请求，当网元接收到所述预设请求之后返回响应，所述网管接收到所述响应之后，根据所述响应的标识信息判定对应的网元正常。即网管在向一个网元发送请求后，不必等到其返回响应就开始对下一个网元发送请求。减少了网管轮询的时间和降低了网管在轮询过程中线程的开销。

参照图5，图5为本发明实施例中第一发送模块的一实施例的细化功能模块示意图。所述第一发送模块10包括：

第一发送单元11，用于当侦测到开始轮询任务的指令时，根据所述指令向需要轮询的网元依次发送预设个数的预设请求；

第二发送单元12，用于在等待预设时间后，继续向需要轮询的网元依次发送预设个数的预设请求。

当网管所管理的网元的轮询周期到来时，即侦测到要开始轮询任务的指令时，所述网管根据所述指令向需要轮询的网元依次发送预设个数的预设请求，当所述预设个数的预设请求发送完毕之后，等待预设时间，继续向需要轮询的网元发送预设个数的预设请求。如所述网管根据所述指令向需要轮询的网元依次发送预设个数的SNMP GET请求，当所述预设个数的SNMP GET请求发送完成之后，等待预设时间。所述网管在等待预设时间之后，继续向需要轮询的网元依次发送预设个数的SNMP GET请求。所述预设个数和预设时间根据UDP(User Datagram Protocol，用户数据协议报)协议栈处理数据的能力来设置，因为SNMP是基于UDP的，当所述网管发送的SNMP GET请求个数太多时，所述UDP协议栈会处理不过来，可能会造成一些SNMP GET请求数据包的丢失，所以需要等待预设时间之后，所述网管才继续向需要轮询的网元依次发送预设个数的SNMP GET请求。如所述预设个数为10个，预设时间为20ms。即所述网管在侦测到开始轮询任务的指令时，根据所述指令向需要轮询的网元依次发送10个SNMP GET请求，在发送完10个SNMP GET请求之后，等待20ms，保证所述10个SNMP GET请求发送完毕之后，继续向需要轮询的网元依次发送10个SNMP GET请求。

本实施例通过在网管依次向需要轮询的网元发送预设个数的预设请求之后，等待预设时间，才继续向需要轮询的网元依次发送预设个数的预设请求，以防在传输预设请求数据包的过程中造成数据包的丢失，保证了每次要发送的请求都发送出去，提高了网元监测方法的准确度。

参照图6，图6为本发明网元监测装置第二实施例的功能模块示意图，基于第一实施例提出本发明网元监测装置第二实施例。

在本实施例中，所述网元监测装置还包括：

添加模块40，用于将被发送过所述预设请求的网元的标识信息添加到超时队列中；

移出模块50，用于将正常网元对应的标识信息移出所述超时队列；

第二判断模块60，用于判断所述超时队列里网元的标识信息个数是否为零；

第三判断模块70，用于若所述超时队列里网元的标识信息个数不为零，则判断是否已发送预设次数的预设请求给所述标识信息对应的网元；

当网管向其网元发送预设请求之后，将被发送过所述预设请求的网元的标识信息添加到其超时队列中，并将正常网元对应的标识信息移出所述超时队列。所述网管定时检测其超时队列中网元的标识信息个数，判断所述超时队列中网元的标识信息个数是否为零。即所述网管通过其定时器在间隔一定的时间段后，检测其超时队列中网元的标识信息个数，如每间隔30秒钟检测一次其超时队列里面的网元的标识信息个数。若所述网管的超时队列中的网元的标识信息个数为零，则说明本次轮询任务中没有出现故障的网元，全部都是正常的网元。若所述网管发现所述超时队列中的网元的标识信息个数不为零时，则表示所述超时队列中的网元在超时时间内没有返回响应给所述网管。如当所述超时队列中的网元的标识信息在超时时间之后还没有被移出超时队列，即所述网管没有接收到所述网元的返回响应，则表示所述网元超时。所述超时时间是所述网管在发送所述预设请求到接收到所述网元的响应的时间，如果当前网络较差时，超时时间会长一点，但是通常情况下网络传输是很快的，一般3秒时间就足够了。若所述网管的超时队列中网元的标识信息个数不为零，则进一步判断是否已发送过预设次数的预设请求给所述超时队列中标识信息对应的网元。

第二判定模块80，用于若已发送预设次数的预设请求给所述标识信息对应的网元，则判定所述网元故障，将所述网元的标识信息移出所述超时队列；

第二发送模块90，用于若未发送预设次数的预设请求给所述标识信息对应的网元，则向所述标识信息对应的网元继续发送所述预设请求。

若所述网管已经发送了预设次数的预设请求给所述超时队列中标识信息对应的网元，则判定所述网元故障，将所述网元的标识信息移出所述超时队列。若所述网管未发送预设次数的预设请求给所述超时队列中标识信息对应 的网元，则向所述网元继续发送所述预设请求，直到达到预设次数。所述预设次数可以根据需要设置，如可以设置为1次，2次，3次等，优选地，设置为2次。如当所述网管发现超时队列里存在网元的标识信息，则进一步判断是否发送过两次SNMP GET请求给所述超时队列中标识信息对应的网元。若所述网管已经发送过两次SNMP GET请求给所述超时队列中标识信息对应的网元，则将所述网元的标识信息移出所述超时队列，判定所述网元故障。

本实施例通过当网管的超时队列中网元的标识信息个数不为零时，进行多次发送请求到所述超时队列中的标识信息对应的网元，排除所述请求在传输过程丢失的情况，提高了网元监测方法的准确度。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。