CN115914030A - 一种监测服务器的方法、装置及相关产品 - Google Patents

Abstract

本申请公开了一种监测服务器的方法、装置及相关产品。首先通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包；接着获取所述服务器在接收所述数据包后的性能数据；最后分析所述性能数据以监测所述服务器的性能。模拟IP地址并向服务器发送数据包，便模拟了网络设备与服务器通讯的目标场景。向服务器发送数据包后，抓取服务器性能数据并进行分析，便是实现了对于目标场景中服务器的性能监测。只需要模拟发生源IP地址便可以解决网络设备覆盖度不足的条件下难以进行服务器性能监测的问题。并且此方案可以不依赖于人工，自动地进行发包、数据抓取、数据分析，因此相比于人工监测方案，更加低成本。

Description

一种监测服务器的方法、装置及相关产品

技术领域

本申请涉及设备监测技术领域，特别是涉及一种监测服务器的方法、装置及相关产品。

背景技术

随着信息安全的不断发展，信息系统的多样化导致日志数量巨大，对承载服务器造成了很大的性能压力，对服务器的性能测试也成为了重中之重。传统的人工性能测试方式，需要进行人工干预，并且要一直观察性能走势及进程变化，其中数据采集和分析耗费大量的人工成本，而且数据分析的结果会有一定的偏差，最终造成成本提升且收效甚微。因此，有待提出可自动实现对服务器进行性能监测的方案，以减少人工负担，节省服务器监测成本。

随着互联网快速发展，网络环境愈发复杂，网络产品层出不穷，如入侵监测系统(Intrusion Detection Systems,IDS)网络设备、末梢节区域(Not-So-Stubby Area,NSSA)网络设备等。作为网络设备的审计产品——服务器，其自身在真实网络运行环境下的性能受到网络设备的发包影响。对于服务器的厂商，往往需要基于网络设备与服务器的通讯交互监测服务器的性能。由于在测试条件下各种网络设备的覆盖度不足，厂商难以获取多样化的网络设备与待监测的服务器进行通讯，导致难于获知服务器在真实的网络运行环境下的性能。显然，这对于服务器产品的测试、研发和改良都造成了阻碍。

发明内容

基于上述问题，本申请提供了一种监测服务器的方法、装置及相关产品，以较低成本实现对服务器的性能监测，解决网络设备覆盖度不足的条件下难以进行服务器性能监测的问题。

本申请实施例公开了如下技术方案：

本申请第一方面提供了一种监测服务器的方法，包括：

通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包；

获取所述服务器在接收所述数据包后的性能数据；

分析所述性能数据以监测所述服务器的性能。

可选地，所述目标场景包括与所述服务器通信连接的多个数据包发生源；通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包，包括：

在一台设备上通过Python的SCAPY模块分别模拟所述多个数据包发生源的IP地址；

通过所述IP地址模拟对应的数据包发生源向所述服务器发送数据包。

可选地，所述通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包，包括：

确定目标场景中数据包发生源对应所述服务器的发包规律；

根据所述发包规律，通过模拟的所述数据包发生源的IP地址向所述服务器发送数据包。

可选地，所述通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包，包括：

获取于处于目标场景下的所述服务器对应的性能测试需求；

根据所述性能测试需求，通过模拟的所述数据包发生源的IP地址向所述服务器发送数据包。

可选地，所述分析所述性能数据以监测所述服务器的性能，包括：

基于数据字段和数据类型归并所述性能数据；

根据归并后的数据建立基线；

通过关键字命中的方式拆解所述基线得到性能指标数据。

可选地，监测服务器的方法还包括：

根据所述性能指标数据与时间的对应关系生成性能波动曲线。

可选地，监测服务器的方法还包括：

获取所述服务器在目标操作下的性能指标数据；

根据所述服务器在目标操作下的性能指标数据更新性能波动曲线；

根据性能波动曲线反映的性能波动的时刻与所述目标操作的操作时刻的对应性，确定所述服务器的性能问题的影响因素。

可选地，监测服务器的方法还包括：

将所述性能指标数据与所述性能指标数据对应的告警阈值进行比较；

当所述性能指标数据高于所述性能指标数据对应的告警阈值时，产生告警；

根据告警生成所述服务器的性能监测报告。

可选地，监测服务器的方法还包括：

记录本次告警相关的归并后的数据；

根据数据容器的剩余容量、所述本次告警相关的归并后的数据以及所述数据容器中已有的归并后的数据的相对大小，判断是否将所述本次告警相关的归并后的数据插入所述数据容器中；

利用所述数据容器对所述服务器进行告警追溯。

可选地，所述根据数据容器的剩余容量、所述本次告警相关的归并后的数据以及所述数据容器中已有的归并后的数据的相对大小，判断是否将所述本次告警相关的归并后的数据插入所述数据容器中，包括：

当所述数据容器的剩余容量不为0，则将所述本次告警相关的归并后的数据插入所述数据容器中，并对所述数据容器中的数据进行冒泡排序；

当所述数据容器的剩余容量为0，则比较所述本次告警相关的归并后的数据以及所述数据容器中已有的归并后的数据的相对大小，若所述数据容器中存在历史告警相关的归并后的数据小于所述本次告警相关的归并后的数据，则对所述数据容器剔除最小值，将所述本次告警相关的归并后的数据插入所述数据容器中，并对所述数据容器中的数据进行冒泡排序。

可选地，所述根据告警生成所述服务器的性能监测报告，包括：

记录与告警相关的归并后的数据；

记录累计告警次数；

根据各次告警、各次告警相关的归并后的数据以及累计告警次数，生成所述服务器的性能监测报告。

可选地，所述性能指标数据包括以下至少一种：

内存占用百分比，CPU占用百分比。

本申请第二方面提供了一种监测服务器的装置，包括：

模拟发包模块，用于通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包；

性能数据抓取模块，用于获取所述服务器在接收所述数据包后的性能数据；

数据分析模块，用于分析所述性能数据以监测所述服务器的性能。

本申请第三方面提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，当所述程序被处理器运行时，实现如第一方面任意一种实现方式提供的监测服务器的方法。

本申请第四方面提供了一种处理器，用于运行计算机程序，所述程序运行时执行如第一方面任意一种实现方式提供的监测服务器的方法。

相较于现有技术，本申请具有以下有益效果：

本申请技术方案提供一种监测服务器的方法、装置及相关产品。在该监测方法中，首先通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包；接着获取所述服务器在接收所述数据包后的性能数据；最后分析所述性能数据以监测所述服务器的性能。数据包发生源是指目标场景中向服务器发送数据包的网络设备，对于服务器而言，在目标场景中该网络设备即作为数据包发生源。在本申请技术方案中，只需要明确出目标场景中服务器的数据包发生源，模拟其IP地址并向服务器发送数据包，便模拟了网络设备与服务器通讯的目标场景。向服务器发送数据包后，抓取服务器性能数据并进行分析，便是实现了对于目标场景中服务器的性能监测。可见，此方案只需要模拟发生源IP地址便可以解决网络设备覆盖度不足的条件下难以进行服务器性能监测的问题。并且此方案可以不依赖于人工，自动地进行发包、数据抓取、数据分析，因此相比于人工监测方案，更加低成本。

附图说明

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

图1为本申请实施例提供的一种目标场景示意图；

图2为本申请实施例提供的另一种目标场景示意图；

图3为本申请实施例提供的又一种目标场景示意图；

图4为本申请实施例提供的一种监测服务器的场景示意图；

图5为本申请实施例提供的另一种监测服务器的场景示意图；

图6为本申请实施例提供的又一种监测服务器的场景示意图；

图7为本申请实施例提供的一种监测服务器的方法流程图；

图8为本申请实施例提供的一种模拟IP地址发送数据包的用户界面示意图；

图9为本申请实施例提供的一种通过一台设备模拟出三个不同网络设备的IP地址的示意图；

图10为本申请实施例提供的另一种监测服务器的方法流程图；

图11为本申请实施例提供的性能波动曲线的示意图；

图12为本申请实施例提供的用户界面展示的告警详情的示意图；

图13本申请实施例提供的一种服务器的性能监测报告的示意图；

图14为本申请实施例提供的一种针对性能指标数据进行告警及告警追溯的过程示意图；

图15为本申请实施例提供的一种监测服务器的装置结构示意图。

具体实施方式

目前对服务器进行性能监测往往要依赖人工进行，导致对服务器的监测成本比较高。并且在与服务器通讯的网络设备有可能覆盖不足，导致难以通过预先的监测获知网络设备覆盖充足的真实网络运行环境下服务器的性能。针对以上问题，本申请中提出采用模拟发生源IP地址的方式，模拟出服务器在目标场景中的收包情况，并获取性能数据加以分析实现服务器监测。通过该方案，不但能够解决人工监测成本高的问题，还可以解决网络设备覆盖不足导致难以准确评估服务器性能的问题。

下面结合实施例和附图对本申请技术方案进行说明。

本申请实施例中，目标场景是指包括服务器及与服务器通讯的网络设备的场景。场景中的服务器以及网络设备之间的相互通讯，搭建了服务器所在的真实的网络运行环境。图1至图3为本申请实施例提供的三种不同的目标场景示意图。在图1的示例中，服务器与一个网络设备通讯。图2所示的场景中，服务器与多个网络设备通讯。图3所示场景中，多个服务器各自与多个网络设备通讯，作为示例，图3所示的多个服务器隶属于一个服务器集群。在一种可能的实现方式中，服务器作为网络设备的审计产品，用于接收网络设备发送的日志数据。这些日志数据可以以数据包的形式发送。网络设备作为数据包的发送方，可以视为数据包发生源，每一个不同的网络设备作为一个独立的数据包发生源。

本方法可以是对图1至图3示例的场景中任意一个待监测的服务器。该方法可以应用于一台独立于目标场景的设备实现，此设备可以为台式电脑、笔记本电脑等示例形式。即，本申请实施例提供的方法的执行主体可以为一台独立于目标场景的设备A实现。此外，本申请实施例提供的方法也可以由多台设备实现，例如设备A用于发送数据包，设备B用于获取性能数据，设备C用于根据设备B获取的性能数据进行分析；或者设备A用于发送数据包，设备B用于获取性能数据并根据服务器的性能数据做分析。针对上述三种方法执行情况，提供图4至图6。图4、图5、图6为本申请实施例提供的三种不同的监测服务器的场景示意图。

图7为本申请实施例提供的一种监测服务器的方法流程图，如图7所示，监测服务器的方法包括：

S701、通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包。

为了解决在监测服务器的场景中，网络设备覆盖不足，配置的网络设备的数量和/或种类与目标场景不匹配，本申请采用模拟IP地址的方式，在监测服务器的场景模拟目标场景中各数据包发生源向服务器发送数据包的效果。

具体而言，在一台Windows系统的设备上通过Python的SCAPY模块模拟数据包发生源的IP地址。如果目标场景中包含与服务器通讯的多个数据包发生源，则通过SCAPY模块模拟该多个数据包发生源的IP地址。实际应用中，可以根据目标场景的特征来模拟数据包发生源的IP地址，例如根据目标场景中对于网络设备与服务器的网络配置，模拟IP地址。

图8展示了一种模拟IP地址发送数据包的用户界面示意图。在图8所示的用户界面中，用户可以选择模拟数据包发生源的IP地址，也可以选择采用该设备本机的IP地址。从而，展示源IP地址。目的IP地址则是该待监测的服务器的IP地址。实际应用中，可以预先存储服务器IP地址在本机。另外，用户也可以通过图8所示的界面选择该服务器的收包端口(即目的端口)，如图8所示选择的端口为514端口。发送数据包时，用户也可以选择不同的发送内容。例如选择一行日志发送，或者选择一个以换行符分割日志的日志文件，或者选择一个以换行符分割日志的日志目录。

在界面上用户可以设置发送数据包的数量和/或频率。在图8所示意的用户界面中，控制台板块具有“后台运行”、“重置计数”、“运行”、“退出”等控件。当“运行”控件被触发，图示的发包工具便根据用户的设置向服务器发送数据包。需要说明的是，图8所示的发包工具用户界面仅作为示例，实际应用中，可以通过多种语言，例如Python3等搭建类似图8界面功能的发包工具。发包工具可以是安装后在图4至图6所示设备A的客户端，也可以是免安装使用的工具。通过模拟的IP地址发送的数据包也可以视为模拟数据包，即，并非在真实的目标环境中由真正的网络设备发送的数据包。

实际应用中，为了通过模拟的IP地址发送数据包，可以利用SOCKET和SCAPY模块，通过TCP、UDP形式多线程地发送给服务器。通过多形式、多线程的数据发送，可以兼顾发包的准确性，并提升发送能力，使本申请技术方案实现的监测可以匹配复杂的网络环境，监测服务器在受到强压力下的承载能力。

S702、获取所述服务器在接收所述数据包后的性能数据。

当以模拟的IP地址向服务器发送数据包后，服务器的性能将随着收包情况发生变化。例如，随着发包量的累积，服务器的CPU占用百分比提升，内存占用百分比提升。为了对服务器的性能进行准确的检测，本申请在发包后，还需要收集服务器的性能数据。需要说明的是，此处的性能数据是指直接从服务器收集而来的性能相关的原始数据，这些数据可能是杂乱的格式多样的。有必要通过步骤S703进行进一步分析，以更加直观地获知服务器在收包后的性能。

实际应用中在S701执行后，可以立即利用SSH协议与服务器建立通信，确立通信管道后，封装线程按照预设的频率向服务器发送TOP明令，并接受返回的数据(STDOUT)，即本步骤S702所指的性能数据。可选地，实时对于服务器的通信情况进行检测，如果检测通信异常断开，则对目前已采集的性能数据进行备份，以极大程度上防止数据丢失影响监测。

S703、分析所述性能数据以监测所述服务器的性能。

实际应用中，可以通过对性能数据进行处理，提取出能够反映服务器性能的关键字段的数据，再基于这些数据进一步分析服务器的性能。例如，可以将提取出的数据与相关阈值做比较，如果超出数据相关的阈值，可以得出性能不佳类似的结论。在可选的实现方式中，为了使用户能够更加直观地获知监测的情况，可以对分析结果或者数据本身进行展示；还可以通过报告的形式输出监测的结果。后文实施例中将对于上述方式作出详细的说明。

以上即为本申请实施例提供的监测服务器的方法。如上文所述，在本申请技术方案中，只需要明确出目标场景中服务器的数据包发生源，模拟其IP地址并向服务器发送数据包，便模拟了网络设备与服务器通讯的目标场景。向服务器发送数据包后，抓取服务器性能数据并进行分析，便是实现了对于目标场景中服务器的性能监测。可见，此方案只需要模拟发生源IP地址便可以解决网络设备覆盖度不足的条件下难以进行服务器性能监测的问题。并且此方案可以不依赖于人工，自动地进行发包、数据抓取、数据分析，因此相比于人工监测方案，更加低成本。

在前文介绍的实施例中提到，如果目标场景中包括与待监测的服务器通讯的多个数据包发生源，本申请实施例提供的监测服务器的方法也可以适用。图9为通过一台设备模拟出三个不同网络设备的IP地址的示意图。模拟出的这三个设备的IP地址，即IP A、IP B、IP C。将一个原本可能非常复杂且成本高昂的测试场景(图9左侧所示)转变为相对成本更低、更加便捷、设备覆盖度要求更低的测试场景(图9右侧所示)。实现了复杂网络环境的简化，更加易于实施，方便对服务器的测试和研发工作。

如上述实施例S701，通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包。在一种可选的实现方式中，具体的发包操作可以视目标场景的发包规律而定；在另一种可选的实现方式中，具体的发包操作还可以视性能测试需求而定。下面分别展开说明。

在一种可选实现方式中，S701可以具体包括：确定目标场景中数据包发生源对应所述服务器的发包规律；根据所述发包规律，通过模拟的所述数据包发生源的IP地址向所述服务器发送数据包。此处所述发包规律可以体现为：发包数量和/或发包频率。也就是说，为了确定监测期间应当以什么样的规律发包从而获得更加真实准确的监测效果，可以首先确定出该场景中数据包发生源对服务器的发包规律。此处发包规律可以是通过预先分析此场景中数据包发生源对服务器的历史发包数量、历史发包频率，通过对历史数据的分析，总结归纳得到此发包规律。其后，在监测时只需要按照该发包规律向服务器发包即可。此外，如果发包规律是呈现波动变化的或者某固定趋势变化的，也可以在后续监测中，随发包时长呈现与该发包规律类似波动变化或者趋势的发包效果。例如，夜间每隔五秒发送数据包，日间每隔两秒发送数据包。

在另一种实现方式中，S701可以具体包括：获取与处于所述目标场景下的所述服务器对应的性能测试需求；根据所述性能测试需求，通过模拟的所述数据包发生源的IP地址向所述服务器发送数据包。举例而言，需要预测评估服务器在低压力(收包数量少或者收包不密集)和在高压力(收包数量多或者收包密集)条件下的性能，则可以根据测试其在不同压力下的性能表现的需求，通过模拟IP地址发包的方式，做到对服务器压力的细致把控。此方案通过这一实现方式，也可以实现定制化场景下的服务器性能测试。

通过对压力的细致把控，能够在监测时或监测后，方便用户准确寻找性能提升的突破点。对于不同压力下的性能也可以通过报告或者用户界面上数据展示的方式进行呈现，方便用户直观比对不同压力下的服务器性能。

为了提供功能更加全面的服务器监测方案，本申请进一步提供了以下监测服务器的方法。如图10所示，该监测服务器的方法包括：

S1001、获取日志样本。

本申请实施例中，为了获得更加准确地模拟场景、发包效果以及监测效果，本申请中可以预先获取一些日志样本。这些日志样本可以是真实场景下获取到的，获取方式可以从网络设备中获取，也可以从服务器获取。这些日志样本的作用是在模拟发包的情况下构建更加真实的数据包。

S1002、基于日志样本，通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包。

如前文所述，基于日志样本可以构建本步骤发送的数据包。构建完成后通过模拟的IP地址进行发送。

S1003、获取所述服务器在接收所述数据包后的性能数据。

前面提到，本步骤直接获取到的性能数据可能是杂乱无章的，并不利于获得直观的监测结果。为此可以首先通过以下步骤S1004对性能数据进行处理。

S1004、基于数据字段和数据类型归并所述性能数据。

作为一种可选的实现方式，本步骤中，对于上述杂乱的性能数据格式化处理为可以被程序识别的格式。按照每秒获取一次性能数据为例，对于每一秒获得的性能数据先格式化处理为规定的数据字段。逐秒获得的数据均按照上述方式处理。对于不同秒获得的数据之间，继续按照数据类型进行归并。例如，可以将数据按照CPU、内存、进程、CPU详情等多种类型进行归并。多个不同的数据字段可能归属到同一种数据类型，同一数据类型的多个不同的数据字段之间具有关联关系。

数据字段示例如下：

内存占用百分比、内存、CPU占用百分比、CPU瞬时值、进程ID、进程名、产生时间、CPU详情、内存详情、SWAP(即内存交换空间)。

归并后的数据可以方便进行后续的数据分析，提升监测效率。归并过程剔除了无用信息，使数据更加精炼，避免浪费开发人员的过多精力。通过本步骤的处理，使数据具备较高的可读性，更加

S1005、根据归并后的数据建立基线。

作为归并后的数据的一种示例使用方式，本申请实施例提出基于归并后的数据，建立点位形式的基线。作为示例，基线队列最长存储10分钟约600个点，当基线时长大于10分钟或者点位多于600个时，基线会依照时间轴清除最早期的若干点位，避免不必要的资源消耗以及浪费。同时，基线的建立也保障了数据可查性。基线可以通过心跳方式进行更新。

需要说明的是，在建立基线时，可能仅仅用到归并后的数据中的部分数据。例如，根据归并后的内存数据中的部分或全部，以及CPU数据中的部分或全部来建立基线。至于归并后的其他未用于建立基线的数据，其与基线存在时间或者数据类型的联系。

S1006、通过关键字命中的方式拆解所述基线得到性能指标数据。

基线是由诸多点位数据形成。从基线中拆解的性能指标数据可以是：内存占用百分比和/或CPU占用百分比。在实际应用中，根据监测需求，还可以采用其他关键词进行命中，得到相应的性能指标数据。此处，性能指标数据即反映用户较为关注的服务器性能。此外，还可以基于基线中数据与其他归并后的数据的联系，拆解出其他归并后的数据中的性能指标数据。

S1007、根据所述性能指标数据与时间的对应关系生成性能波动曲线。

为了便于用户更加直观地观测到收包后服务器的性能变化，本申请实施例提出，可以根据上一步拆解得到的性能指标数据与时间的对应关系生成性能波动曲线。由于基线的点位数据是随时间更新的，因此生成性能波动曲线是比较便利于实现的。本申请中可以采用PyQt5.QtChart组件实现对于曲线的绘制。实际应用中只需要将用于生成性能波动曲线的数据传输给该组件即可完成曲线的绘制，渲染呈现在用户界面供用户查看。

图11为本申请实施例提供的性能波动曲线的示意图。在图11中，位于上方的波动较小的曲线为服务器的内存占用百分比的波动曲线；位于下方的波动较大的曲线为服务器的CPU占用百分比的波动曲线。

本申请实施例中性能波动曲线具有诸多用处。例如，性能波动曲线可以实时反映出所监测的服务器的性能状况以及性能变化，反映性能变化或者性能不佳时对应的时间点，便于后续进行服务器的运维、调整、性能改进。此外，由于性能波动曲线随时间的实时更新与记录，本申请中，如果用户(例如运维人员)执行目标操作目的是改善当前服务器的性能或者定位造成服务器性能不佳的问题，性能波动曲线也可以反映出一些有效的信息供用户查看实现目标。

具体而言，本申请技术方案中可以获取所述服务器在目标操作下的性能指标数据；根据所述服务器在目标操作下的性能指标数据更新性能波动曲线；根据性能波动曲线反映的性能波动的时刻与所述目标操作的操作时刻的对应性，确定所述服务器的性能问题的影响因素。也就是说，用户可以一边执行目标操作一边观察性能波动曲线，再去定位性能问题的影响因素以便优化服务器本身的性能，为后续服务器提供更好的服务提供支持。性能波动曲线可以展示在大屏上，供多人查看或者有权限的用户查看、比对。

性能波动曲线的展示能够辅助用户监测CPU占用百分比、内存占用百分比等数据。性能波动曲线展示的信息维度相对较少，实际应用中，用户可能还关注性能指标数据之外的其他信息，或者获得及时的警示。为此可以执行以下步骤S1008。

S1008、将所述性能指标数据与所述性能指标数据对应的告警阈值进行比较，当所述性能指标数据高于所述性能指标数据对应的告警阈值时，产生告警，根据告警生成所述服务器的性能监测报告。

实际应用中，可以为性能指标数据设置对应的告警阈值。例如为CPU占用百分比设置告警阈值，为内存占用百分比设置告警阈值。通过与对应的阈值的比较，能够明确出服务器的相关性能指标是否处于不佳的状态。通过及时的告警，可以辅助用户进行做出适当的调整，或者及时发现问题。

为了更全面地展现所监测的服务器的性能情况，本申请实施例中，可以记录与告警相关的归并后的数据；记录累计告警次数；根据各次告警、各次告警相关的归并后的数据以及累计告警次数，生成所述服务器的性能监测报告。

图12为本申请实施例提供的用户界面展示的告警详情的示意图。告警详情可以包括：告警次数、各次告警的发生时间、内存、CPU、包名ID、CPU详情等。这些信息均可以在告警发生时从归并后的数据中提取和记录。在图12中同时还展示出了CPU详情的窗口，涉及到基本信息例如时间、CPU、内存、Swap、内存详情等，在CPU详情的窗口中还可以包括图中所示的进程信息。

图13本申请实施例提供的一种服务器的性能监测报告的示意图。如图13所示，报告中可以展示测试IP(即所监测的服务器的IP地址)、启动时间(即启动监测的时间)、CPU峰值、内存峰值、CPU告警数、内存告警数、运行时长(即通过发包进行监测的时长)。在性能监测报告中，还可以进一步提供详情信息，例如测试IP、告警数等基本信息，以及CPU均值、CPU峰值、峰值时间、峰值CPU信息、峰值内存信息等CPU信息。性能监测报告可以上传、下载及转发，供不同的设备上的用户查看。

针对监测期间出现的告警，本申请技术方案还提供了一种追溯告警的方案，具体实现参加下述步骤S1009。

S1009、记录本次告警相关的归并后的数据；根据数据容器的剩余容量、所述本次告警相关的归并后的数据以及所述数据容器中已有的归并后的数据的相对大小，判断是否将所述本次告警相关的归并后的数据插入所述数据容器中。

每次告警后记录与本次告警相关的归并后的数据，将其插入到数据容器中供后续追溯。作为一种可能的实现方式，可以预先在程序中建立一个容量为10的数据容器。此处容量具体可以是指容纳的告警相关数据的次数，例如只能容纳10次告警有关的数据。告警一旦发生，可以首先判断数据容器中的剩余容量是否为0，是否为0表示是否可以继续直接容纳告警的数据。

当所述数据容器的剩余容量不为0，则将所述本次告警相关的归并后的数据插入所述数据容器中，并对所述数据容器中的数据进行冒泡排序；

当所述数据容器的剩余容量为0，则比较所述本次告警相关的归并后的数据以及所述数据容器中已有的归并后的数据的相对大小，若所述数据容器中存在历史告警相关的归并后的数据小于所述本次告警相关的归并后的数据，则对所述数据容器剔除最小值，将所述本次告警相关的归并后的数据插入所述数据容器中，并对所述数据容器中的数据进行冒泡排序。

剔除最小值，意味着在容器中保留性能更差的数据，将最严重的告警相关的数据保留在容器中，供用户实现更加具有针对性和关键行的告警追溯。图14为本申请实施例提供的一种针对性能指标数据进行告警及告警追溯的过程示意图。结合图14可知，针对不同的性能指标数据，可以分别产生不同类型的告警，例如针对CPU占用百分比的告警(属于CPU告警)，以及针对内存占用百分比的告警(属于内存告警)。

对于上述在数据容器中的大小比较，如果是内存告警，则比较内存字段，如果是CPU告警，则比较CPU字段。最终，当需要利用所述数据容器对所述服务器进行告警追溯。大幅度提升发现性能漏洞的及时性与准确性，从而降低成本。

以上介绍的技术方案中，基于学习方式对承载服务器进行数据发送、数据采集、数据分析、异常告警、报告转发，实现一键全自动，通过实时曲线波动和异常性能告警，快速定位性能缺陷，从而大幅度提升测试效率及性能检测准确率，降低投入成本。对每一个不同的业务场景可以进行定制测试方案，节约了使用者的配置时间。

Python3与PyQt5相结合，实现界面化配置、浏览，简化操作流程使用者更易操作，程序内部通过学习方式对数据进行广处理重分析，有效决服务器性能测试成本高、数据结论不准确问题。

在前述实施例提供的监测服务器的方法的基础上，本申请还进一步提供了一种监测服务器的装置。下面结合图15介绍此装置的具体实现。如图15所示，监测服务器的装置包括：

模拟发包模块，用于通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包；

性能数据抓取模块，用于获取所述服务器在接收所述数据包后的性能数据；

数据分析模块，用于分析所述性能数据以监测所述服务器的性能。

可选地，所述目标场景包括与所述服务器通信连接的多个数据包发生源；模拟发包模块，具体用于：

在一台设备上通过Python的SCAPY模块分别模拟所述多个数据包发生源的IP地址；

通过所述IP地址模拟对应的数据包发生源向所述服务器发送数据包。

可选地，模拟发包模块，具体用于：

确定目标场景中数据包发生源对应所述服务器的发包规律；

根据所述发包规律，通过模拟的所述数据包发生源的IP地址向所述服务器发送数据包。

可选地，模拟发包模块，具体用于：

获取与处于目标场景下的所述服务器对应的性能测试需求；

根据所述性能测试需求，通过模拟的所述数据包发生源的IP地址向所述服务器发送数据包。

可选地，数据分析模块，具体用于：

基于数据字段和数据类型归并所述性能数据；

根据归并后的数据建立基线；

通过关键字命中的方式拆解所述基线得到性能指标数据。

可选地，监测服务器的装置还包括：

曲线生成模块，用于根据所述性能指标数据与时间的对应关系生成性能波动曲线。

可选地，性能数据抓取模块，还用于获取所述服务器在目标操作下的性能指标数据；曲线生成模块，还用于根据所述服务器在目标操作下的性能指标数据更新性能波动曲线；

监测服务器的装置还包括：

影响因素确定模块，用于根据性能波动曲线反映的性能波动的时刻与所述目标操作的操作时刻的对应性，确定所述服务器的性能问题的影响因素。

可选地，监测服务器的装置还包括：

告警模块，用于将所述性能指标数据与所述性能指标数据对应的告警阈值进行比较；当所述性能指标数据高于所述性能指标数据对应的告警阈值时，产生告警；

报告生成模块，用于根据告警生成所述服务器的性能监测报告。

可选地，监测服务器的装置还包括：

记录模块，用于记录本次告警相关的归并后的数据；

数据插入模块，用于根据数据容器的剩余容量、所述本次告警相关的归并后的数据以及所述数据容器中已有的归并后的数据的相对大小，判断是否将所述本次告警相关的归并后的数据插入所述数据容器中；

告警追溯模块，用于利用所述数据容器对所述服务器进行告警追溯。

可选地，数据插入模块具体用于：

当所述数据容器的剩余容量不为0，则将所述本次告警相关的归并后的数据插入所述数据容器中，并对所述数据容器中的数据进行冒泡排序；

当所述数据容器的剩余容量为0，则比较所述本次告警相关的归并后的数据以及所述数据容器中已有的归并后的数据的相对大小，若所述数据容器中存在历史告警相关的归并后的数据小于所述本次告警相关的归并后的数据，则对所述数据容器剔除最小值，将所述本次告警相关的归并后的数据插入所述数据容器中，并对所述数据容器中的数据进行冒泡排序。

可选地，所述报告生成模块，具体用于：

记录与告警相关的归并后的数据；

记录累计告警次数；

根据各次告警、各次告警相关的归并后的数据以及累计告警次数，生成所述服务器的性能监测报告。

基于前述实施例提供的监测服务器的方法和装置，本申请实施例还提供了一种计算机可读存储介质。

该存储介质上存储有程序，该程序被处理器执行时实现本申请前述方法实施例保护的监测服务器的方法中部分或全部步骤。

该存储介质可以是U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

基于前述实施例提供的监测服务器的方法、装置和存储介质，本申请实施例提供了一种处理器。该处理器用于运行程序，其中，所述程序运行时执行前述方法实施例保护的监测服务器的方法中部分或全部步骤。

以上所述，仅为本申请的一种具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims (11)

1.一种监测服务器的方法，其特征在于，包括：

通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包；

获取所述服务器在接收所述数据包后的性能数据；

分析所述性能数据以监测所述服务器的性能。

2.根据权利要求1所述的方法，其特征在于，所述目标场景包括与所述服务器通信连接的多个数据包发生源；通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包，包括：

在一台设备上通过Python的SCAPY模块分别模拟所述多个数据包发生源的IP地址；

通过所述IP地址模拟对应的数据包发生源向所述服务器发送数据包。

3.根据权利要求1所述的方法，其特征在于，所述通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包，包括：

确定目标场景中数据包发生源对应所述服务器的发包规律；

根据所述发包规律，通过模拟的所述数据包发生源的IP地址向所述服务器发送数据包。

4.根据权利要求1所述的方法，其特征在于，所述通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包，包括：

获取与处于目标场景下的所述服务器对应的性能测试需求；

根据所述性能测试需求，通过模拟的所述数据包发生源的IP地址向所述服务器发送数据包。

5.根据权利要求1所述的方法，其特征在于，所述分析所述性能数据以监测所述服务器的性能，包括：

基于数据字段和数据类型归并所述性能数据；

根据归并后的数据建立基线；

通过关键字命中的方式拆解所述基线得到性能指标数据。

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

获取所述服务器在目标操作下的性能指标数据；

根据所述服务器在目标操作下的性能指标数据更新性能波动曲线；

根据性能波动曲线反映的性能波动的时刻与所述目标操作的操作时刻的对应性，确定所述服务器的性能问题的影响因素。

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

将所述性能指标数据与所述性能指标数据对应的告警阈值进行比较；

当所述性能指标数据高于所述性能指标数据对应的告警阈值时，产生告警；

根据告警生成所述服务器的性能监测报告。

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

记录本次告警相关的归并后的数据；

根据数据容器的剩余容量、所述本次告警相关的归并后的数据以及所述数据容器中已有的归并后的数据的相对大小，判断是否将所述本次告警相关的归并后的数据插入所述数据容器中；

利用所述数据容器对所述服务器进行告警追溯。

9.一种监测服务器的装置，其特征在于，包括：

模拟发包模块，用于通过模拟目标场景中数据包发生源的IP地址，向服务器发送数据包；

性能数据抓取模块，用于获取所述服务器在接收所述数据包后的性能数据；

数据分析模块，用于分析所述性能数据以监测所述服务器的性能。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当所述程序被处理器运行时，实现如权利要求1-8任一项所述的监测服务器的方法。

11.一种处理器，其特征在于，用于运行计算机程序，所述程序运行时执行如权利要求1-8任一项所述的监测服务器的方法。

Images