CN112825504B - 一种数据监测方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种数据监测方法、装置、设备及存储介质，该方法的步骤包括：监听数据传输设备的通信状态；当通信状态为数据包传入数据传输设备时，通过探针获取数据传输设备中关键代码段的执行信息，关键代码段为与数据包转发逻辑相关的代码段；根据执行信息对数据包的转发状态进行判定以生成监测结果。本方法通过探针在关键代码段中获取关键代码段的执行信息，并根据执行信息判定数据包的转发状态，因此实现了在数据传输设备转发数据包的过程中，对数据包的转发状态进行代码粒度级别的监测。此外，本申请还提供一种数据监测装置、设备及存储介质，有益效果同上所述。

Description

一种数据监测方法、装置、设备及存储介质

技术领域

本申请涉及云计算领域，特别是涉及一种数据监测方法、装置、设备及存储介质。

背景技术

随着互联网的高速发展，云产业的快速突起，基础架构网络逐渐向基于通用计算平台的架构融合，以支持多样化的网络系统。

在数据中心网络中，数据包往往需要经过包括发送端设备、接收端设备、路由器以及交换机在内的各类数据传输设备，因此可能出现数据包丢失的情况，从而可能会导致业务出现不同程度的故障。

由此可见，提供一种数据监测方法，以实现对保数据包转发过程的状态监测，是本领域技术人员需要解决的问题。

发明内容

本申请的目的是提供一种数据监测方法、装置、设备及存储介质，以实现对保数据包转发过程的状态监测。

为解决上述技术问题，本申请提供一种数据监测方法，包括：

监听数据传输设备的通信状态；

当通信状态为数据包传入数据传输设备时，通过探针获取数据传输设备中关键代码段的执行信息，

关键代码段为与数据包转发逻辑相关的代码段；

根据执行信息对数据包的转发状态进行判定以生成监测结果。

优选地，当关键代码段的数量大于1时，通过探针获取数据传输设备中关键代码段的执行信息，包括：

通过探针统计数据传输设备中关键代码段的执行次数；

根据执行信息对数据包的转发状态进行判定以生成监测结果，包括：

判断各关键代码段的执行次数是否一致；

如果各关键代码段的执行次数一致，则将数据包的转发状态设置为正常状态；

如果各关键代码段的执行次数非一致，则将数据包的转发状态设置为异常状态。

优选地，在将数据包的转发状态设置为异常状态之后，方法还包括：

在各关键代码段中获取连续执行的第一关键代码段以及第二关键代码段，第一关键代码段先于第二关键代码段执行；

当第一关键代码段对应的执行次数大于第二关键代码段对应的执行次数时，将第一关键代码段设置为异常代码段。

优选地，在通过探针统计数据传输设备中关键代码段的执行次数之前，方法还包括：

划分与关键代码段的数量相同的资源池，资源池与关键代码段之间存在唯一对应关系；

通过与关键代码段对应的资源池建立探针。

优选地，当关键代码段的数量为1时，在根据执行信息对数据包的转发状态进行判定以生成监测结果之前，方法还包括：

获取数据包的总量；

通过探针获取数据传输设备中关键代码段的执行信息，包括：

通过探针统计数据传输设备中关键代码段的执行次数；

根据执行信息对数据包的转发状态进行判定以生成监测结果，包括：

判断关键代码段的执行次数与数据包的总量是否一致；

如果关键代码段的执行次数与数据包的总量一致，则将数据包的转发状态设置为正常状态；

如果关键代码段的执行次数与数据包的总量非一致，则将数据包的转发状态设置为异常状态，并将关键代码段设置为异常代码段。

优选地，监听数据传输设备的通信状态，包括：

监听存在通信异常概率的数据传输设备的通信状态。

优选地，通过探针获取数据传输设备中关键代码段的执行信息，包括：

通过基于Prometheus架构构建的探针获取数据传输设备中关键代码段的执行信息。

此外，本申请还提供一种数据监测装置，包括：

监听模块，用于监听数据传输设备的通信状态；

探针获取模块，用于当通信状态为数据包传入数据传输设备时，通过探针获取数据传输设备中关键代码段的执行信息，

关键代码段为与数据包转发逻辑相关的代码段；

结果生成模块，用于根据执行信息对数据包的转发状态进行判定以生成监测结果。

此外，本申请还提供一种数据监测设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行计算机程序时实现如上述的数据监测方法的步骤。

此外，本申请还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上述的数据监测方法的步骤。

本申请所提供的数据监测方法，首先监听数据传输设备的通信状态，进而当数据传输设备的通信状态表征数据包传入数据传输设备时，通过探针获取数据传输设备中关键代码段的执行信息，关键代码段为数据传输设备对数据包的转发逻辑相关的代码段，在获取关键代码段的执行信息后，根据执行信息对数据包的转发状态进行判定，并以此生成监测结果。本方法通过探针在关键代码段中获取关键代码段的执行信息，并根据执行信息判定数据包的转发状态，因此实现了在数据传输设备转发数据包的过程中，对数据包的转发状态进行代码粒度级别的监测。此外，本申请还提供一种数据监测装置、设备及存储介质，有益效果同上所述。

附图说明

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

图1为本申请公开的一种数据监测方法的流程图；

图2为本申请公开的一种具体的数据监测方法的流程图；

图3为本申请公开的一种具体的数据监测方法的流程图；

图4为本申请公开的一种具体的数据监测方法的流程图；

图5为本申请公开的一种具体的数据监测方法的流程图；

图6为本申请公开的一种具体场景实施例中的场景示意图；

图7为本申请公开的一种数据监测装置的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下，所获得的所有其他实施例，都属于本申请保护范围。

在数据中心网络中，数据包由发送端向接收端传输的过程中，往往需要经过包括路由器以及交换机在内的各类数据传输设备，因此可能出现数据包丢失的情况，从而可能会导致业务出现不同程度的故障，但是由于数据包在数据传输设备之间是流动传递的，因此无法获悉数据包丢失，难以确保数据包的可靠传输。

为此，本申请的核心是提供一种数据监测方法，以实现对数据传输设备中数据包的转发状态进行监控，确保数据包的可靠传输。

请参见图1所示，本申请实施例公开了一种数据监测方法，包括：

步骤S10：监听数据传输设备的通信状态。

本步骤中的数据传输设备是指可对输入的数据包执行与转发相关的逻辑操作的通信设备。数据传输设备通常设置于发送端与接收端之间，以用于将发送端的数据包转发至接收端的设备，通过监听数据传输设备的通信状态能够获悉数据传输设备中是否到达有数据包，也就是能够根据通信状态确定数据传输设备是否开始对数据包执行与转发相关的逻辑操作。

步骤S11：当通信状态为数据包传入数据传输设备时，通过探针获取数据传输设备中关键代码段的执行信息，关键代码段为与数据包转发逻辑相关的代码段。

当监听到数据传输设备的通信状态表征数据包传入数据传输设备时，进一步通过探针获取数据传输设备中关键代码段的执行信息，此处的执行信息指的是关键代码段运行时产生的相关信息，包括但不限于关键代码段的执行时长、执行过程中产生的状态参数以及执行结果等；此处的关键代码指的是数据传输设备执行的与数据包转发逻辑相关的代码段，由于关键代码决定着数据包能否正常被数据传输设备转发，因此基于关键代码段产生的执行信息能够进一步反映数据传输设备对数据包的处理状态。

另外，需要说明的是，本步骤中通过探针获取数据传输设备中关键代码段的执行信息，具体实现的方式可以是通过预先在关键代码段中设置探针函数的方式实现，进而关键代码段在执行时将进一步触发探针函数执行，进而探针函数根据自身的执行逻辑对关键代码的执行信息进行统计。

步骤S12：根据执行信息对数据包的转发状态进行判定以生成监测结果。

在获取到执行信息后，进一步根据执行信息对数据包的转发状态进行判定，以此获悉数据包是否被数据传输设备正常转发，并以此产生相应的监测结果。需要强调的是，根据执行信息对数据包的转发状态进行判定的方式应根据执行信息的具体类型而定，通常来讲可以根据执行信息的类型获取相应的判定标准，并通过判断执行信息是否满足该判定标准来判定数据包在数据传输设备中的转发状态。

本申请所提供的数据监测方法，首先监听数据传输设备的通信状态，进而当数据传输设备的通信状态表征数据包传入数据传输设备时，通过探针获取数据传输设备中关键代码段的执行信息，关键代码段为数据传输设备对数据包的转发逻辑相关的代码段，在获取关键代码段的执行信息后，根据执行信息对数据包的转发状态进行判定，并以此生成监测结果。本方法通过探针在关键代码段中获取关键代码段的执行信息，并根据执行信息判定数据包的转发状态，因此实现了在数据传输设备转发数据包的过程中对数据包的转发状态进行代码粒度级别的监测。

在上述实施例的基础上，作为一种优选的实施方式，监听数据传输设备的通信状态，包括：

监听存在通信异常概率的数据传输设备的通信状态。

需要说明的是，本实施方式是将数据传输设备进一步限定为在通信过程中存在异常概率，即异常可能性的数据传输设备，由于存在异常概率的数据传输设备可能造成数据包的丢失，因此有针对性的对该类数据传输设备进行监听能够相对确保数据监测的整体准确性。

另外，需要说明的是，本实施例中存在通信异常概率的数据传输设备，可以预先通过Netflow等网络监控技术对数据传输设备进行实时监测并筛选得到，Netflow是一种网络监测功能，可以收集进入及离开网络设备的IP数据包的数量及信息，通常应用在路由器及交换机等产品上。经由分析Netflow收集到的信息，网络运维人员可以获悉造成网络拥塞的路由器及交换机等产品。

在上述实施例的基础上，当关键代码段的数量大于1时，本申请还进一步提供以下优选的实施例。

本申请实施例公开了一种数据监测方法，如图2所示，包括：

步骤S20：监听数据传输设备的通信状态。

步骤S21：当通信状态为数据包传入数据传输设备时，通过探针统计数据传输设备中关键代码段的执行次数，关键代码段为与数据包转发逻辑相关的代码段。

步骤S22：判断各关键代码段的执行次数是否一致，如果是，则执行步骤S23，否则，执行步骤S24。

步骤S23：将数据包的转发状态设置为正常状态。

步骤S24：将数据包的转发状态设置为异常状态。

需要强调的是，本实施例的重点在于通过探针获取的关键代码段的执行信息具体为关键代码段的执行次数，也就是数据包通过关键代码段的次数。可以理解的是，数据包需要经过数据传输设备的全部关键代码段的处理后，才能够由当前的数据传输设备发送至下一个数据传输设备或接收端，因此本实施例在当数据包在数据传输设备中经过的关键代码段的数量大于1时，通过探针统计数据传输设备中各关键代码段的执行次数，其中，执行次数侧面反映的是数据包的整体数量，在获取到数据传输设备中各关键代码段的执行次数后，进一步判定判断各关键代码段的执行次数是否一致，如果是，则说明数据包在经过各个关键代码段时的整体数量均没有减少，因此将数据包的转发状态设置为正常状态，否则，说明存在数据包在经过关键代码段时发生丢失，因此将数据包的转发状态设置为异常状态。本实施例通过各个关键代码段的执行次数是否一致来判断数据包是否在经过关键代码段时发生丢失，相对确保了对数据包的转发状态进行监测的整体准确性。

本申请实施例公开了一种数据监测方法，如图3所示，包括：

步骤S30：监听数据传输设备的通信状态。

步骤S31：当通信状态为数据包传入数据传输设备时，通过探针统计数据传输设备中关键代码段的执行次数，关键代码段为与数据包转发逻辑相关的代码段。

步骤S32：判断各关键代码段的执行次数是否一致，如果是，则执行步骤S33，否则，执行步骤S34。

步骤S33：将数据包的转发状态设置为正常状态。

步骤S34：将数据包的转发状态设置为异常状态。

步骤S35：在各关键代码段中获取连续执行的第一关键代码段以及第二关键代码段，第一关键代码段先于第二关键代码段执行。

步骤S36：当第一关键代码段对应的执行次数大于第二关键代码段对应的执行次数时，将第一关键代码段设置为异常代码段。

需要说明的是，在将数据包的转发状态设置为异常状态后，本实施例进一步在各个关键代码中获取连续执行的第一关键代码段以及第二关键代码段，第一关键代码段与第二关键代码段是相对而言的两个连续执行的关键代码段，第一关键代码段先于第二关键代码段执行，进而当第一关键代码段对应的执行次数大于第二关键代码段对应的执行次数时，则说明在执行第一关键代码段的过程中，数据包发生丢失，因此将第一关键代码段设置为异常代码段。

本实施例在判定数据传输设备中数据包的转发状态为异常状态，即数据传输设备中的数据包存在丢失的情况后，进一步对造成数据包丢失的代码段进行了定位，确保了对数据包的转发状态的监测内容的全面性，进而用户能够有针对性的对于异常的关键代码段进行调整，从而确保数据包的可靠传输。

本申请实施例公开了一种数据监测方法，如图4所示，包括：

步骤S40：监听数据传输设备的通信状态。

步骤S41：划分与关键代码段的数量相同的资源池，资源池与关键代码段之间存在唯一对应关系。

步骤S42：通过与关键代码段对应的资源池建立探针。

步骤S43：当通信状态为数据包传入数据传输设备时，通过探针统计数据传输设备中关键代码段的执行次数，关键代码段为与数据包转发逻辑相关的代码段。

步骤S44：判断各关键代码段的执行次数是否一致，如果是，则执行步骤S45，否则，执行步骤S46。

步骤S45：将数据包的转发状态设置为正常状态。

步骤S46：将数据包的转发状态设置为异常状态。

需要说明的是，本实施例的重点在于在通过探针统计数据传输设备中关键代码段的执行次数之前，预先划分与关键代码段的数量相同的资源池，资源池与关键代码段之间存在唯一对应关系，进而针对于每一个关键代码段对应的资源池建立用于对该关键代码段进行监测的探针，因此能够相对确保每一个关键代码段的探针在执行时使用的资源池相互独立，也就是说，每一个资源池有相应的线程独占，相对避免了探针之前争抢同一资源的情况产生，确保了数据监测过程的整体稳定性。

在上述实施例的基础上，当关键代码段的数量为1时，本申请还进一步提供以下优选的实施例。

本申请实施例公开了一种数据监测方法，如图5所示，包括：

步骤S50：监听数据传输设备的通信状态。

步骤S51：当通信状态为数据包传入数据传输设备时，通过探针统计数据传输设备中关键代码段的执行次数，关键代码段为与数据包转发逻辑相关的代码段。

步骤S52：获取数据包的总量。

步骤S53：判断关键代码段的执行次数与数据包的总量是否一致，如果是，则执行步骤S54，否则，执行步骤S55。

步骤S54：将数据包的转发状态设置为正常状态。

步骤S55：将数据包的转发状态设置为异常状态，并将关键代码段设置为异常代码段。

需要说明的是，在本实施例针对于关键代码段的数量为1的场景，也就是说，在本实施例中，探针仅对一段关键代码段进行监测，在此情况下，需要预先获取传入数据传输设备的数据包的总量，进而在数据包传入数据传输设备后，探针统计关键代码段的执行次数，进而判断关键代码段的执行次数与数据包的总量是否一致，一致则说明数据包未发生丢失，因此将数据包的转发状态设置为正常状态；不一致则说明数据包在通过该关键代码段时发生丢失，因此将将数据包的转发状态设置为异常状态，并将关键代码段设置为异常代码段。本实施例确保了对数据包的转发状态的监测内容的全面性，进而用户能够有针对性的对于异常的关键代码段进行调整，从而确保数据包的可靠传输。

在上述一系列实施例的基础上，作为一种优选的实施方式，通过探针获取数据传输设备中关键代码段的执行信息，包括：

通过基于Prometheus架构构建的探针获取数据传输设备中关键代码段的执行信息。

需要说明的是，本实施方式的重点是通过基于Prometheus架构构建的探针获取数据传输设备中关键代码段的执行信息。Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。Prometheus使用Go语言开发，是Google BorgMon监控系统的开源版本。

由于Prometheus架构为开源架构，因此具有较高的可二次开发性，进而能够根据实际需求进一步对探针的函数结构进行优化，包括但不限于将Prometheus架构的初始化函数进一步封装为单独的接口，进而在探针的函数中通过调用该接口的方式对探针进行初始化，以提高探针的函数可读性。本实施方式相对提高了探针的可优化性以及可扩展性，进而确保了数据监测过程可控性。

为了加深对于本申请技术方案的理解，本申请还提供一种具体场景下的场景实施例，本实施例提供的场景实施例的场景示意图如图6所示。

在图6所示的场景中，发送端发出的数据包依次经过数据传输设备R1以及数据传输设备R2最终传输至接收端。

实际场景下的数据监测过程如下：

1、首先监测端利用Netflow或IPFPM技术来对发送端以及接收端之间的网络进行实时监测，当发送端以及接收端之间的网络出现丢失数据包的可能时，判断可能发生数据包丢失的数据传输设备，并告知发送端。在本场景下可能发生数据包丢失的数据传输设备可以包括数据传输设备R1和/或数据传输设备R1。

2、发送端针对某条正在发生丢包的数据流，构造出一批测试用的数据包，这批数据包的五元组，即源IP、目的IP、源端口、目的端口、传输层协议类型均与正在发生丢包的流相同，但不同的是，这批数据包会打上特殊的标记为来标记这些数据包属于探测数据包。

3、监测端通过探针对可能发生数据包丢失的数据传输设备中关键代码段的执行信息进行统计，并根据执行信息对数据包的在该数据传输设备中的转发状态进行判定以生成监测结果。

请参见图7所示，本申请实施例公开了一种数据监测装置，包括：

监听模块10，用于监听数据传输设备的通信状态；

探针获取模块11，用于当通信状态为数据包传入数据传输设备时，通过探针获取数据传输设备中关键代码段的执行信息，关键代码段为与数据包转发逻辑相关的代码段；

结果生成模块12，用于根据执行信息对数据包的转发状态进行判定以生成监测结果。

本申请所提供的数据监测装置，首先监听数据传输设备的通信状态，进而当数据传输设备的通信状态表征数据包传入数据传输设备时，通过探针获取数据传输设备中关键代码段的执行信息，关键代码段为数据传输设备对数据包的转发逻辑相关的代码段，在获取关键代码段的执行信息后，根据执行信息对数据包的转发状态进行判定，并以此生成监测结果。本装置通过探针在关键代码段中获取关键代码段的执行信息，并根据执行信息判定数据包的转发状态，因此实现了在数据传输设备转发数据包的过程中，对数据包的转发状态进行代码粒度级别的监测。

在前述实施例的基础上，本申请实施例对数据监测装置进行进一步的说明和优化。具体的：

在一种具体实施方式中，当关键代码段的数量大于1时，探针获取模块11，包括：

第一次数获取模块，用于通过探针统计数据传输设备中关键代码段的执行次数；

结果生成模块12，包括：

第一判断模块，用于判断各关键代码段的执行次数是否一致，如果是，则调用第一正常状态模块，否则，调用第一异常状态模块；

第一正常状态模块，用于将数据包的转发状态设置为正常状态；

第一异常状态模块，用于将数据包的转发状态设置为异常状态。

在一种具体实施方式中，装置还包括：

代码段获取模块，用于在各关键代码段中获取连续执行的第一关键代码段以及第二关键代码段，第一关键代码段先于第二关键代码段执行；

代码段判定模块，用于当第一关键代码段对应的执行次数大于第二关键代码段对应的执行次数时，将第一关键代码段设置为异常代码段。

在一种具体实施方式中，当关键代码段的数量为1时，装置还包括：

资源池划分模块，用于划分与关键代码段的数量相同的资源池，资源池与关键代码段之间存在唯一对应关系；

探针建立模块，用于通过与关键代码段对应的资源池建立探针。

在一种具体实施方式中，装置还包括：

总量获取模块，用于获取数据包的总量；

探针获取模块11，包括：

第二次数获取模块，用于通过探针统计数据传输设备中关键代码段的执行次数；

结果生成模块12，包括：

第二判断模块，用于判断各关键代码段的执行次数是否一致，如果是，则调用第二正常状态模块，否则，调用第二异常状态模块；

第二正常状态模块，用于将数据包的转发状态设置为正常状态；

第二异常状态模块，用于将数据包的转发状态设置为异常状态，并将关键代码段设置为异常代码段。

在一种具体实施方式中，监听模块10，包括：

选择性监听模块，用于监听存在通信异常概率的数据传输设备的通信状态。

在一种具体实施方式中，探针获取模块11，包括：

框架获取模块，用于通过基于Prometheus架构构建的探针获取数据传输设备中关键代码段的执行信息。

此外，本实施例还公开了一种数据监测设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行计算机程序时实现如上述的数据监测方法的步骤。

本申请所提供的数据监测设备，首先监听数据传输设备的通信状态，进而当数据传输设备的通信状态表征数据包传入数据传输设备时，通过探针获取数据传输设备中关键代码段的执行信息，关键代码段为数据传输设备对数据包的转发逻辑相关的代码段，在获取关键代码段的执行信息后，根据执行信息对数据包的转发状态进行判定，并以此生成监测结果。本设备通过探针在关键代码段中获取关键代码段的执行信息，并根据执行信息判定数据包的转发状态，因此实现了在数据传输设备转发数据包的过程中，对数据包的转发状态进行代码粒度级别的监测。

此外，本实施例还公开了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上述的数据监测方法的步骤。

本申请所提供的计算机可读存储介质，首先监听数据传输设备的通信状态，进而当数据传输设备的通信状态表征数据包传入数据传输设备时，通过探针获取数据传输设备中关键代码段的执行信息，关键代码段为数据传输设备对数据包的转发逻辑相关的代码段，在获取关键代码段的执行信息后，根据执行信息对数据包的转发状态进行判定，并以此生成监测结果。本计算机可读存储介质通过探针在关键代码段中获取关键代码段的执行信息，并根据执行信息判定数据包的转发状态，因此实现了在数据传输设备转发数据包的过程中，对数据包的转发状态进行代码粒度级别的监测。

以上对本申请所提供的一种数据监测方法、装置、设备及存储介质进行了详细介绍。说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

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

Claims (10)

1.一种数据监测方法，其特征在于，包括：

监听数据传输设备的通信状态；

当所述通信状态为数据包传入所述数据传输设备时，通过探针获取所述数据传输设备中关键代码段的执行信息，所述关键代码段为与数据包转发逻辑相关的代码段；

根据所述执行信息对所述数据包的转发状态进行判定以生成监测结果；

其中，当所述关键代码段的数量大于1时，所述根据所述执行信息对所述数据包的转发状态进行判定以生成监测结果，包括：

判断各所述关键代码段的执行次数是否一致；

如果各所述关键代码段的执行次数一致，则将所述数据包的转发状态设置为正常状态；

如果各所述关键代码段的执行次数非一致，则将所述数据包的转发状态设置为异常状态。

2.根据权利要求1所述的数据监测方法，其特征在于，当所述关键代码段的数量大于1时，所述通过探针获取所述数据传输设备中关键代码段的执行信息，包括：

通过所述探针统计所述数据传输设备中所述关键代码段的执行次数。

3.根据权利要求2所述的数据监测方法，其特征在于，在所述将所述数据包的转发状态设置为异常状态之后，所述方法还包括：

在各所述关键代码段中获取连续执行的第一关键代码段以及第二关键代码段，所述第一关键代码段先于所述第二关键代码段执行；

当所述第一关键代码段对应的执行次数大于所述第二关键代码段对应的执行次数时，将所述第一关键代码段设置为异常代码段。

4.根据权利要求2所述的数据监测方法，其特征在于，在所述通过所述探针统计所述数据传输设备中所述关键代码段的执行次数之前，所述方法还包括：

划分与所述关键代码段的数量相同的资源池，所述资源池与所述关键代码段之间存在唯一对应关系；

通过与所述关键代码段对应的所述资源池建立所述探针。

5.根据权利要求1所述的数据监测方法，其特征在于，当所述关键代码段的数量为1时，在所述根据所述执行信息对所述数据包的转发状态进行判定以生成监测结果之前，所述方法还包括：

获取所述数据包的总量；

所述通过探针获取所述数据传输设备中关键代码段的执行信息，包括：

通过所述探针统计所述数据传输设备中所述关键代码段的执行次数；

所述根据所述执行信息对所述数据包的转发状态进行判定以生成监测结果，包括：

判断所述关键代码段的执行次数与所述数据包的总量是否一致；

如果所述关键代码段的执行次数与所述数据包的总量一致，则将所述数据包的转发状态设置为正常状态；

如果所述关键代码段的执行次数与所述数据包的总量非一致，则将所述数据包的转发状态设置为异常状态，并将所述关键代码段设置为异常代码段。

6.根据权利要求1所述的数据监测方法，其特征在于，所述监听数据传输设备的通信状态，包括：

监听存在通信异常概率的数据传输设备的所述通信状态。

7.根据权利要求1至6任意一项所述的数据监测方法，其特征在于，所述通过探针获取所述数据传输设备中关键代码段的执行信息，包括：

通过基于Prometheus架构构建的所述探针获取所述数据传输设备中所述关键代码段的执行信息。

8.一种数据监测装置，其特征在于，包括：

监听模块，用于监听数据传输设备的通信状态；

探针获取模块，用于当所述通信状态为数据包传入所述数据传输设备时，通过探针获取所述数据传输设备中关键代码段的执行信息，

所述关键代码段为与数据包转发逻辑相关的代码段；

结果生成模块，用于根据所述执行信息对所述数据包的转发状态进行判定以生成监测结果；

其中，当所述关键代码段的数量大于1时，所述结果生成模块包括：

第一判断模块，用于判断各所述关键代码段的执行次数是否一致；

第一正常状态模块，用于如果各所述关键代码段的执行次数一致，则将所述数据包的转发状态设置为正常状态；

第一异常状态模块，用于如果各所述关键代码段的执行次数非一致，则将所述数据包的转发状态设置为异常状态。

9.一种数据监测设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至7任一项所述的数据监测方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的数据监测方法的步骤。

Images