一种上报设备异常的方法和装置与流程

本发明涉及计算机技术领域，特别涉及一种上报设备异常的方法和装置。

背景技术：

设备在运行的过程中，经常会因为硬件或软件上的问题出现运行故障，从而可能导致设备处理能力下降、执行逻辑错误，甚至会出现设备宕机、组件损坏等现象。为了能尽早发现设备的运行故障，用户可以通过性能监控程序(可称为监控工具)查看设备的性能指标，了解设备的运行状态。

设备在出现运行故障之前，往往会出现一些异常现象，这些异常现象可以通过设备的性能指标得到反映。以进程为例，当设备运行的某进程运行异常时，反映进程运行异常的性能指标——进程的cpu使用率，将超出正常范围，这时，运行在设备上的监控工具可以检测到上述性能指标异常，然后可以对相应的运行数据进行采集，如正在运行的各进程的进程号、cpu使用率以及调用的各个函数等数据。之后，监控工具可以将采集的运行数据发送给用户，以使用户可以通过这些运行数据，对设备出现的异常现象进行分析，判断设备是否可能出现故障问题。

在实现本发明的过程中，发明人发现现有技术至少存在以下问题：

只要检测到性能指标异常，监控工具就会将采集的性能数据发送给用户，这将消耗大量的设备处理资源。并且，监控工具采集的运行数据，其数据量往往很大，尤其当用户对多台设备进行监控时，需要分析的数据量将会极其巨大，导致用户需要花费较长的时间才可能基于设备出现的异常现象，判断设备是否会出现故障问题，浪费了用户大量的时间和精力。

技术实现要素：

为了解决现有技术的问题，本发明实施例提供了一种上报设备异常的方法和装置。所述技术方案如下：

第一方面，提供了一种上报设备异常的方法，所述方法包括：

当监控到设备的目标进程的性能指标出现异常时，采集运行数据；

对所述运行数据进行异常进程分析，生成异常分析结果；

如果所述异常分析结果指示为上报异常，则将所述异常分析结果进行上报，否则排除此次异常。

进一步的，所述在所述设备处对所述运行数据进行异常进程分析，生成异常分析结果，包括：

如果在预设时段内所述目标进程的cpu使用率小于所述预设阈值，则排除此次异常，否则在所述设备处对所述运行数据进行异常进程分析，生成异常分析结果。

进一步的，所述在所述设备处对所述运行数据进行异常进程分析，生成异常分析结果，包括：

基于预设下降率和所述目标进程的cpu使用率，计算下降后的cpu使用率；

如果所述下降后的cpu使用率小于所述预设阈值，则排除此次异常，否则在所述设备处对所述运行数据进行异常进程分析，生成异常分析结果。

进一步的，所述目标进程包括多个线程；

所述对所述运行数据进行异常进程分析，生成异常分析结果，包括：

在所述多个线程中确定处理主要业务且处于运行态的线程数目，并将所述目标进程的cpu使用率除以所述线程数目，得到平均线程使用率；

如果所述平均线程使用率大于等于所述预设阈值，则生成上报所述目标进程存在多线程跑高的异常分析结果，否则生成不上报异常的异常分析结果。

进一步的，所述对所述运行数据进行异常进程分析，生成异常分析结果，包括：

判断所述目标进程是否与任一cpu逻辑核绑定；

如果是，则生成上报所述目标进程与cpu逻辑核绑定的异常分析结果，否则生成上报所述目标进程与cpu逻辑核未绑定的异常分析结果。

进一步的，所述对所述运行数据进行异常进程分析，生成异常分析结果，包括：

判断所述目标进程是否属于由定时任务启动的进程；

如果是，则生成上报所述目标进程属于由定时任务启动的进程的异常分析结果，否则生成上报所述目标进程不属于由定时任务启动的进程的异常分析结果。

进一步的，所述判断所述目标进程是否属于由定时任务启动的进程，包括：

在进程树中向上遍历，确定包含所述目标进程的上级进程的进程名；

如果所述上级进程的进程名中包含有crond，则判断所述目标进程属于由定时任务启动的进程，否则判断所述目标进程不属于由定时任务启动的进程。

进一步的，所述判断所述目标进程是否属于由定时任务启动的进程，包括：

在crontab配置文件中查找所述目标进程的进程名；

如果查找到所述目标进程的进程名，则判断监控到所述目标进程的性能指标出现异常的时刻是否属于所述crontab配置文件为所述目标进程配置的执行周期；

如果是，则判断所述目标进程属于由定时任务启动的进程，否则判断所述目标进程不属于由定时任务启动的进程。

进一步的，所述对所述运行数据进行异常进程分析，生成异常分析结果，包括：

统计预设采样时段中各个函数的调用次数以及所有函数的调用总次数；

计算每个所述函数的所述调用次数占所述调用总次数的调用比值，按照所述调用比值由高到低的顺序对各个所述函数进行排序；

分别计算每个所述函数的所述调用比值和其之后一序位的所述函数的调用比值的差值，占每个所述函数的所述调用比值的落差比值；

生成上报包含有最大的所述落差比值对应的所述函数及其之前的所有所述函数的所述运行数据的异常分析结果。

第二方面，提供了一种上报设备异常的装置，所述装置包括：

采集模块，用于当监控到设备的目标进程的性能指标出现异常时，采集运行数据；

分析模块，用于在所述设备处对所述运行数据进行异常进程分析，生成异常分析结果；

上报模块，用于如果所述异常分析结果指示为上报异常，则将所述异常分析结果进行上报，否则排除此次异常。

进一步的，所述分析模块具体用于：

如果在预设时段内所述目标进程的cpu使用率小于所述预设阈值，则排除此次异常，否则在所述设备处对所述运行数据进行异常进程分析，生成异常分析结果。

进一步的，所述分析模块具体用于：

基于预设下降率和所述目标进程的cpu使用率，计算下降后的cpu使用率；

如果所述下降后的cpu使用率小于所述预设阈值，则排除此次异常，否则在所述设备处对所述运行数据进行异常进程分析，生成异常分析结果。

进一步的，所述目标进程包括多个线程；

所述分析模块具体用于：

在所述多个线程中确定处理主要业务且处于运行态的线程数目，并将所述目标进程的cpu使用率除以所述线程数目，得到平均线程使用率；

如果所述平均线程使用率大于等于所述预设阈值，则生成上报所述目标进程存在多线程跑高的异常分析结果，否则生成不上报异常的异常分析结果。

进一步的，所述分析模块具体用于：

判断所述目标进程是否与任一cpu逻辑核绑定；

如果是，则生成上报所述目标进程与cpu逻辑核绑定的异常分析结果，否则生成上报所述目标进程与cpu逻辑核未绑定的异常分析结果。

进一步的，所述分析模块具体用于：

判断所述目标进程是否属于由定时任务启动的进程；

如果是，则生成上报所述目标进程属于由定时任务启动的进程的异常分析结果，否则生成上报所述目标进程不属于由定时任务启动的进程的异常分析结果。

进一步的，所述装置还包括定时判断模块，用于：

在进程树中向上遍历，确定包含所述目标进程的上级进程的进程名；

如果所述上级进程的进程名中包含有crond，则判断所述目标进程属于由定时任务启动的进程，否则判断所述目标进程不属于由定时任务启动的进程。

进一步的，所述装置还包括定时判断模块，用于：

在crontab配置文件中查找所述目标进程的进程名；

如果查找到所述目标进程的进程名，则判断监控到所述目标进程的性能指标出现异常的时刻是否属于所述crontab配置文件为所述目标进程配置的执行周期；

如果是，则判断所述目标进程属于由定时任务启动的进程，否则判断所述目标进程不属于由定时任务启动的进程。

进一步的，所述分析模块具体用于：

统计预设采样时段中各个函数的调用次数以及所有函数的调用总次数；

计算每个所述函数的所述调用次数占所述调用总次数的调用比值，按照所述调用比值由高到低的顺序对各个所述函数进行排序；

分别计算每个所述函数的所述调用比值和其之后一序位的所述函数的调用比值的差值，占每个所述函数的所述调用比值的落差比值；

生成上报包含有最大的所述落差比值对应的所述函数及其之前的所有所述函数的所述运行数据的异常分析结果。

第三方面，提供了一种设备，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如第一方面所述的上报设备异常的方法。

第四方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如第一方面所述的上报设备异常的方法。

本发明实施例提供的技术方案带来的有益效果是：

在本实施例中，当监控到设备的目标进程的性能指标出现异常时，采集运行数据；在所述设备处对运行数据进行异常进程分析，生成异常分析结果；如果异常分析结果指示为上报异常，则将异常分析结果进行上报，否则排除此次异常。这样，在监控到进程运行异常后，设备可以预先对运行数据进行分析，得出异常原因，并可以对运行数据进行一定的筛选整理，以减少待上报的运行数据的数据量，不仅可以降低用户判断设备是否会出现故障问题的难度，还可以减少用户待分析的数据量，从而可以节省用户较多的时间和精力。同时，设备可以基于分析得到的异常分析结果，将那些需要上报的异常进行上报，无需每次都进行异常上报，从而可以节省较多的设备处理资源。另外，上述设备可以将异常分析结果上报给用于收集或分析异常数据的服务器或相关平台，可以进一步扩大异常分析的数据基础，且上述异常分析结果不同于无规律的运行数据，是基于技术人员进行异常分析的经验逻辑而得到，更具参考价值，可以使得上述服务器或相关平台的分析结果更加准确。

附图说明

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

图1是本发明实施例提供的一种上报设备异常的方法流程图；

图2是本发明实施例提供的一种上报设备异常的装置结构示意图；

图3是本发明实施例提供的一种上报设备异常的装置结构示意图；

图4是本发明实施例提供的一种设备的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

本发明实施例提供了一种上报设备异常的方法，该方法的执行主体可以是具备程序运行功能的任意设备，可以是服务器或者是设备。设备可以加载并运行有背景技术中提及的监控工具，该监控工具可以监控设备的运行状态，一方面，其可以将设备运行过程中产生的硬件或软件故障通知给用户，另一方面，其可以在监控到设备运行异常后，将设备异常情况上报给客户。上述设备可以包括处理器、存储器、收发器，处理器可以用于进行下述流程中对于上报设备异常的处理，存储器可以用于存储处理过程中需要的数据以及产生的数据，如各个正在运行的进程的进程号、cpu使用率以及调用的各个函数等，收发器可以用于接收和发送处理过程中的相关数据。设备可以支持多个进程同时运行，进程运行时不同程度的占用设备cpu的处理资源。

下面将结合具体实施方式，对图1所示的一种上报设备异常的方法的处理流程进行详细的说明，内容可以如下：

步骤101，当监控到设备的目标进程的性能指标出现异常时，采集运行数据。

在实施中，设备可以通过上述监控工具对各个进程的性能指标进行监控，以及时发现各个进程是否运行异常。当监控到某进程(可称为目标进程)的性能指标出现异常时，设备可以确定出监控到目标进程出现异常的异常时刻，然后可以对包含该异常时刻的一段时间内的运行数据进行采集，如采集异常时刻前后五分钟内运行的各进程的进程号、cpu使用率以及调用的各个函数等运行数据。

可选的，目标进程的性能指标可以是进程的cpu使用率，相应的，步骤101的处理可以如下：当监控到设备的目标进程的cpu使用率大于等于预设阈值时，采集运行数据。

在实施中，进程的cpu使用率可以在很大程度上反应该进程的运行情况，因此，可以将进程的cpu使用率作为监控进程运行情况的性能指标。设备可以通过判断目标进程的cpu使用率是否大于等于预设阈值的方式，来监控目标进程是否出现异常。具体的，上述预设阈值可以设置为80％，通常情况下，当进程的cpu使用率超过80％时，该进程很大可能已出现进程运行异常。当然，上述预设阈值也可以设置为其他数值，例如75％、70％等，以进一步调整判断进程是否运行异常的判断精度，这里对其不做具体限定。这样，当监控到目标进程的cpu使用率大于等于预设阈值时，设备可以对目标进程的相关运行数据进行采集。

步骤102，在设备处对运行数据进行异常进程分析，生成异常分析结果。

在实施中，设备在采集到运行数据后，可以在产生运行数据的源端，即设备处，由设备本身实时对采集的运行数据进行异常进程分析，判断目标进程的异常原因以及生成相应的异常分析结果，而无需将采集的运行数据发送给远端的大数据平台。需要说明的是，由于大数据平台往往同时服务大量的设备，因此，由大数据平台进行异常分析往往需要较长时间，进而导致需要在较长时间后，才可能得出异常分析结果，以解决设备出现的异常问题。而在设备处对采集的运行数据进行异常进程分析，设备只需对本身所采集的运行数据进行异常进程分析，这样，可以大大减少异常进程分析的时间，及时得出异常分析结果。

具体的，上述异常原因可以分为正常型异常原因和上报型异常原因，其中，正常型异常原因表明目标进程出现的进程运行异常实际为正常现象，无需进行上报，如虚假跑高；上报型异常原因表明目标进程出现的进程运行异常需要上报，如多线程跑高、是否由定时任务启动等。经过上述分析之后，设备可以生成相应的异常分析结果。异常分析结果同样可以分为两类，一类为排除型分析结果，在该类型的异常分析结果中，可以包括正常型异常原因以及整理后的与该异常原因相关的运行数据；另一类为上报型分析结果，在该类型的异常分析结果中，可以包括上报型异常原因以及整理后的与该异常原因相关的运行数据。这样，在出现进程运行异常后，设备可以预先对运行数据进行分析，得出异常原因，并可以对运行数据进行一定的筛选整理，以减少待上报的运行数据的数据量，不仅可以降低用户判断设备是否会出现故障问题的难度，还可以减少用户待分析的数据量，从而可以节省用户较多的时间和精力。

值得一提的是，如果设备在采集运行数据的过程中，出现运行数据采集失败的情形，如目标进程的突然结束，将会导致无法监控到目标进程的cpu使用率，则设备可以停止当前的异常进程分析，因为设备出现的绝大多数异常情形都可以复现，如果是极少情况下出现的异常情形，对设备的影响也是一个极短的时间，从长期来看对性能影响极小。

可选的，如果目标进程的cpu使用率降低到正常范围，则步骤102的处理可以如下：如果在预设时段内目标进程的cpu使用率小于预设阈值，则排除此次异常，否则在所述设备处对运行数据进行异常进程分析，生成异常分析结果。

在实施中，某一进程的cpu使用率是动态变化的，可能当前时刻的cpu使用率为45％，下一时刻的cpu使用率上升为55％。这样，对于目标进程的cpu使用率只是暂时大于等于预设阈值的异常情形，设备可以无需进行异常进程分析，以节省设备处理资源。具体的，设备可以在采集运行数据的过程中，继续监控目标进程的cpu使用率，如果在预设时段内，出现了目标进程的cpu使用率小于预设阈值的情形，则可以排除此次异常，不进行后续的异常进程分析处理；如果在预设时段内目标进程的cpu使用率仍然大于等于预设阈值，则继续进行后续的异常进程分析处理，生成异常分析结果。

可选的，考虑到可能存在进程迁移或进程处理的业务发生转移的情形，可以基于下降后的cpu使用率判断是否进行后续进程异常分析，相应的，步骤102的处理可以如下：基于预设下降率和目标进程的cpu使用率，计算下降后的cpu使用率；如果下降后的cpu使用率小于预设阈值，则排除此次异常，否则在所述设备处对运行数据进行异常进程分析，生成异常分析结果。

在实施中，可能因为出现进程迁移或者进程处理的业务发生转移的情形，导致目标进程的cpu使用率大于等于预设阈值。其中，进程迁移的情形是指，在进程号不变的情况下，目标进程在不同cpu之间进行调度，从而可能出现目标进程的cpu使用率一度大于等于预设阈值的情形。进程处理的业务发生转移的情形是指，在进程号不变的情况下，某一进程运行的业务短时间内转移到另一进程，导致异常现象随之转移到该另一进程，这样，如果某一进程运行的业务短时间内转移到目标进程，则可能出现目标进程的cpu使用率一度大于等于预设阈值的情形。为了应对上述情形，设备可以基于预设下降率和目标进程的cpu使用率，计算目标进程下降后的cpu使用率，然后判断下降后的cpu使用率与预设阈值的大小关系。具体的，可以采用以下公式计算目标进程下降后的cpu使用率：

processcpuusaget＝processcpuusaget*degrationa

其中，processcpuusaget表示目标进程实际的cpu使用率，degrationa表示预设下降率，processcpuusaget表示目标进程下降后的cpu使用率。

如果目标进程下降后的cpu使用率小于预设阈值，则可以排除此次异常，不进行后续的异常进程分析处理；如果目标进程下降后的cpu使用率仍然大于等于预设阈值，则继续进行后续的异常进程分析处理，生成异常分析结果。这样，可以在一定程度上降低由进程迁移或者进程处理的业务发生转移的情形带来的影响，以节省设备处理资源。

进一步的，为了应对上述进程迁移或者进程处理的业务发生转移的情形，设备还可以对预设阈值进行调整，得到调整后的预设阈值，然后判断目标进程的cpu使用率与调整后的预设阈值的大小关系。具体的，可以采用以下公式计算调整后的预设阈值：

thresholdcpu％＝thresholdcpu*degrationb

其中，thresholdcpu表示原始的预设阈值，degrationb表示预设调整率，thresholdcpu％表示调整后的预设阈值。

如果目标进程的cpu使用率小于上述调整后的预设阈值，则可以排除此次异常，不进行后续的异常进程分析处理；如果目标进程的cpu使用率仍然大于等于上述调整后的预设阈值，则继续进行后续的异常进程分析处理，生成异常分析结果。同样，上述处理也可以在一定程度上降低由进程迁移或者进程处理的业务发生转移的情形带来的影响，以节省设备处理资源。

可选的，对于目标进程包括多个线程的情形，步骤102的处理可以如下：在多个线程中确定处理主要业务且处于运行态的线程数目，并将目标进程的cpu使用率除以所述线程数目，得到平均线程使用率；如果平均线程使用率大于等于预设阈值，则生成上报目标进程存在多线程跑高的异常分析结果，否则生成不上报异常的异常分析结果。

在实施中，如果目标进程为多线程进程，则设备可以判断出现的进程运行异常是否由虚假跑高导致的异常。对于多线程进程，其cpu使用率的计算方法为进程中各个线程的cpu使用率之和，即：

其中，processcpuusagei表示进程的cpu使用率，threadcpuusageij表示该进程中某个线程的cpu使用率。

容易发现，上述计算方法可能导致计算出来的进程cpu使用率超过100％，甚至1000％的情况，这是由于进程虽然在某个cpu上运行，但是其包括的各个线程则可能分布运行于其他的cpu上，如果多个线程运行在同一个cpu上时，则在计算线程的cpu使用率时会出现重复计算。因此，需要根据实际情况将多线程进程的cpu使用率进行分摊，再基于分摊后的线程使用率判断是否出现虚假跑高。具体的，设备可以通过特殊进程表，预先对每个多线程进程中处理主要业务的各个线程进行记录。这样，设备可以基于特殊进程表，在目标进程包括的多个线程中确定出处理主要业务且处于运行态的线程数目，然后将目标进程的cpu使用率除以该线程数目，得到平均线程使用率。之后，设备可以判断平均线程使用率与预设阈值的大小关系，如果平均线程使用率大于等于预设阈值，则设备可以生成上报目标进程存在多线程跑高的异常分析结果；如果平均线程使用率小预设阈值，则设备可以生成不上报异常的异常分析结果。

可选的，步骤102的处理还可以如下：判断目标进程是否与任一cpu逻辑核绑定；如果是，则生成上报目标进程与cpu逻辑核绑定的异常分析结果，否则生成上报目标进程与cpu逻辑核未绑定的异常分析结果。

在实施中，设备可以从目标进程是否与cpu逻辑核绑定的角度，进行进程异常分析。具体的，设备可以基于适配3.10内核的bpf工具集，判断目标进程是否与任一cpu逻辑核绑定。如果目标进程与任一cpu逻辑核进行了绑定，则设备可以生成上报目标进程与cpu逻辑核绑定的异常分析结果；如果目标进程没有与任一cpu逻辑核进行了绑定，则生成上报目标进程与cpu逻辑核未绑定的异常分析结果。这样，用户在获取到上述异常分析结果后，可以进行针对性分析，降低了用户判断设备是否会出现故障问题时的难度，节省了用户较多的时间和精力。

可选的，步骤102的处理还可以如下：判断目标进程是否属于由定时任务启动的进程；如果是，则生成上报目标进程属于由定时任务启动的进程的异常分析结果，否则生成上报目标进程不属于由定时任务启动的进程的异常分析结果。

在实施中，设备可以从目标进程是否属于由定时任务启动的进程的角度，进行进程异常分析。具体的，设备可以通过crond标识或者crontab配置文件，来判断目标进程是否属于由定时任务启动的进程。如果目标进程属于由定时任务启动的进程，则设备可以生成上报目标进程属于由定时任务启动的进程的异常分析结果；如果目标进程不属于由定时任务启动的进程，则设备可以生成上报目标进程不属于由定时任务启动的进程的异常分析结果。这样，用户在获取到上述异常分析结果后，可以进行针对性分析，降低了用户判断设备是否会出现故障问题时的难度，节省了用户较多的时间和精力。

可选的，上述通过crond标识判断目标进程是否属于由定时任务启动的进程的处理可以如下：在进程树中向上遍历，确定包含目标进程的上级进程的进程名；如果上级进程的进程名中包含有crond，则判断目标进程属于由定时任务启动的进程，否则判断目标进程不属于由定时任务启动的进程。

在实施中，由于所有的定时任务均以crond进程的子进程形式产生，只要异常进程的上一级进程是crond进程，则该异常进程必属于由定时任务启动的进程，其中，crond进程是指该进程名中包含有crond的进程。这样，设备可以对记录有各个进程之间层级关系的进程树进行获取，然后在进程树中向上遍历，确定包含目标进程的上级进程的进程名。之后，设备可以判断这些包含目标进程的上级进程的进程名中是否包含有crond。如果上级进程的进程名中包含有crond，则设备可以判断目标进程属于由定时任务启动的进程；如果上级进程的进程名中不包含crond，则设备可以判断目标进程不属于由定时任务启动的进程。

可选的，上述通过crontab配置文件判断目标进程是否属于由定时任务启动的进程的处理可以如下：在crontab配置文件中查找目标进程的进程名；如果查找到目标进程的进程名，则判断监控到目标进程的性能指标出现异常的时刻是否属于crontab配置文件为目标进程配置的执行周期；如果是，则判断目标进程属于由定时任务启动的进程，否则判断目标进程不属于由定时任务启动的进程。

在实施中，设备可以在crontab配置文件中对各个定时任务的启动逻辑进行配置，包括配置的启动时间周期以及待执行的文件或指令，其中，在上述文件或指令中记录有启动的各进程的进程名。这样，设备可以对crontab配置文件进行获取，然后在crontab配置文件中查找目标进程的进程名。如果在crontab配置文件中查找到目标进程的进程名，则进一步判断监控到目标进程的性能指标出现异常的时刻，是否属于crontab配置文件为目标进程配置的执行周期，如果目标进程的性能指标出现异常的时刻，属于crontab配置文件为目标进程配置的执行周期，则设备可以判断目标进程属于由定时任务启动的进程。如果目标进程的性能指标出现异常的时刻，不属于crontab配置文件为目标进程配置的执行周期，或者在crontab配置文件中未查找到目标进程的进程名，则设备可以判断目标进程不属于由定时任务启动的进程。以定时任务为向用户报时为例，如果在crontab配置文件中配置的启动时间周期为每天的8时、10时、18时、20时，且目标进程的性能指标出现异常的时刻为8时、10时、18时、20时中的某一个时刻，则可以判断目标进程属于由定时任务启动的进程。

可选的，步骤102的处理还可以如下：统计预设采样时段中各个函数的调用次数以及所有函数的调用总次数；计算每个函数的调用次数占调用总次数的调用比值，按照调用比值由高到低的顺序对各个函数进行排序；分别计算每个函数的调用比值和其之后一序位的函数的调用比值的差值，占每个函数的调用比值的落差比值；生成上报包含有最大的落差比值对应的函数及其之前的所有函数的运行数据的异常分析结果。

在实施中，设备可以从函数调用的角度，进行异常分析。具体的，设备可以通过perf工具获取预设采样时段中各个函数的调用次数，然后对预设采样时段中各个函数的调用次数以及所有函数的调用总次数进行统计。之后，设备可以对每个函数的调用次数占调用总次数的调用比值进行计算，得到每个函数的调用次数占调用总次数的调用比值，然后按照调用比值由高到低的顺序，对每个函数的调用次数占调用总次数的调用比值进行排序，生成相应的调用比值排序表。之后，设备可以计算每个函数的调用比值和其之后一序位的函数的调用比值的差值，占每个函数的调用比值的落差比值，并可以将各个函数的落差比值记录在上述调用比值排序表中。之后，设备可以在调用比值排序表中确定出最大的落差比值对应的函数，然后设备可以将调用比值排序表中最大的落差比值对应的函数及其之前的所有函数的运行数据，通过异常分析结果进行上报。这样，可以对运行数据进行一定的筛选整理，以减少待上报的运行数据的数据量，不仅可以降低用户判断设备是否会出现故障问题的难度，还可以减少用户待分析的数据量，从而可以节省用户较多的时间和精力。

步骤103，如果异常分析结果指示为上报异常，则将异常分析结果进行上报，否则排除此次异常。

在实施中，设备在生成异常分析结果之后，可以基于生成的异常分析结果，判断是否上报此次出现的进程运行异常。具体的，如果异常分析结果指示为上报异常，例如上报型分析结果，则设备可以将该异常分析结果进行上报；如果异常分析结果指示为无需上报，例如排除型分析结果，则设备可以对此次出现的进程运行异常进行排除，无需将其上报。这样，设备可以只将需要上报的异常进行上报，从而无需每次都上报异常，可以节省较多的设备处理资源。需要说明的是，设备可以将生成的异常分析结果上报给用户，也可以将生成的异常分析结果上报给用于收集或分析异常数据的服务器或相关平台，如上述的大数据平台，作为上述服务器或相关平台的数据库的一部分，进一步扩大了异常分析的数据基础，且上述异常分析结果不同于无规律的运行数据，是基于技术人员进行异常分析的经验逻辑而得到，更具参考价值，可以使得上述服务器或相关平台的分析结果更加准确。

在本实施例中，当监控到设备的目标进程的性能指标出现异常时，采集运行数据；在设备处对运行数据进行异常进程分析，生成异常分析结果；如果异常分析结果指示为上报异常，则将异常分析结果进行上报，否则排除此次异常。这样，在监控到进程运行异常后，设备可以预先对运行数据进行分析，得出异常原因，并可以对运行数据进行一定的筛选整理，以减少待上报的运行数据的数据量，不仅可以降低用户判断设备是否会出现故障问题的难度，还可以减少用户待分析的数据量，从而可以节省用户较多的时间和精力。同时，设备可以基于分析得到的异常分析结果，将那些需要上报的异常进行上报，无需每次都进行异常上报，从而可以节省较多的设备处理资源。另外，上述设备可以将异常分析结果上报给用于收集或分析异常数据的服务器或相关平台，可以进一步扩大异常分析的数据基础，且上述异常分析结果不同于无规律的运行数据，是基于技术人员进行异常分析的经验逻辑而得到，更具参考价值，可以使得上述服务器或相关平台的分析结果更加准确。

基于相同的技术构思，本发明实施例还提供了一种上报设备异常的装置，如图2所示，所述装置包括：

采集模块201，用于当监控到设备的目标进程的性能指标出现异常时，采集运行数据；

分析模块202，用于在所述设备处对所述运行数据进行异常进程分析，生成异常分析结果；

上报模块203，用于如果所述异常分析结果指示为上报异常，则将所述异常分析结果进行上报，否则排除此次异常。

可选的，所述采集模块201具体用于：

当监控到所述目标进程的cpu使用率大于等于预设阈值时，采集所述运行数据。

可选的，所述分析模块202具体用于：

如果在预设时段内所述目标进程的cpu使用率小于所述预设阈值，则排除此次异常，否则在所述设备处对所述运行数据进行异常进程分析，生成异常分析结果。

可选的，所述分析模块202具体用于：

基于预设下降率和所述目标进程的cpu使用率，计算下降后的cpu使用率；

如果所述下降后的cpu使用率小于所述预设阈值，则排除此次异常，否则在所述设备处对所述运行数据进行异常进程分析，生成异常分析结果。

可选的，所述目标进程包括多个线程；

所述分析模块202具体用于：

在所述多个线程中确定处理主要业务且处于运行态的线程数目，并将所述目标进程的cpu使用率除以所述线程数目，得到平均线程使用率；

如果所述平均线程使用率大于等于所述预设阈值，则生成上报所述目标进程存在多线程跑高的异常分析结果，否则生成不上报异常的异常分析结果。

可选的，所述分析模块202具体用于：

判断所述目标进程是否与任一cpu逻辑核绑定；

如果是，则生成上报所述目标进程与cpu逻辑核绑定的异常分析结果，否则生成上报所述目标进程与cpu逻辑核未绑定的异常分析结果。

可选的，所述分析模块202具体用于：

判断所述目标进程是否属于由定时任务启动的进程；

如果是，则生成上报所述目标进程属于由定时任务启动的进程的异常分析结果，否则生成上报所述目标进程不属于由定时任务启动的进程的异常分析结果。

可选的，如图3所示，所述装置还包括定时判断模块204，用于：

在进程树中向上遍历，确定包含所述目标进程的上级进程的进程名；

如果所述上级进程的进程名中包含有crond，则判断所述目标进程属于由定时任务启动的进程，否则判断所述目标进程不属于由定时任务启动的进程。

可选的，所述装置还包括定时判断模块204，用于：

在crontab配置文件中查找所述目标进程的进程名；

如果查找到所述目标进程的进程名，则判断监控到所述目标进程的性能指标出现异常的时刻是否属于所述crontab配置文件为所述目标进程配置的执行周期；

如果是，则判断所述目标进程属于由定时任务启动的进程，否则判断所述目标进程不属于由定时任务启动的进程。

可选的，所述分析模块202具体用于：

统计预设采样时段中各个函数的调用次数以及所有函数的调用总次数；

计算每个所述函数的所述调用次数占所述调用总次数的调用比值，按照所述调用比值由高到低的顺序对各个所述函数进行排序；

分别计算每个所述函数的所述调用比值和其之后一序位的所述函数的调用比值的差值，占每个所述函数的所述调用比值的落差比值；

生成上报包含有最大的所述落差比值对应的所述函数及其之前的所有所述函数的所述运行数据的异常分析结果。

需要说明的是：上述实施例提供的上报设备异常的装置在上报设备异常时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的上报设备异常的装置与上报设备异常的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

图4是本发明实施例提供的设备的结构示意图。该设备400可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器422(例如，一个或一个以上处理器)和存储器432，一个或一个以上存储应用程序442或数据444的存储介质430(例如一个或一个以上海量存储设备)。其中，存储器432和存储介质430可以是短暂存储或持久存储。存储在存储介质430的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对设备中的一系列指令操作。更进一步地，中央处理器422可以设置为与存储介质430通信，在设备400上执行存储介质430中的一系列指令操作。

设备400还可以包括一个或一个以上电源426，一个或一个以上有线或无线网络接口450，一个或一个以上输入输出接口458，一个或一个以上键盘456，和/或，一个或一个以上操作系统441，例如windowsservertm，macosxtm，unixtm，linuxtm，freebsdtm等等。

设备400可以包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行所述一个或者一个以上程序包含用于进行上述上报设备异常的指令。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

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