一种大数据组件的监控方法、装置、电子设备与流程

本申请涉及大数据组件的监控技术领域，尤其涉及一种大数据组件的监控方法、装置、电子设备及计算机可读存储介质。

背景技术：

随着大数据技术的快速发展，各行各业每天都会产生大量数据，面对海量数据的操作，各种大数据服务组件应运而生，比如hadoop、elasticsearch、clickhouse、kafka等。

大数据组件在运行过程中，为了方便对大数据组件进行调优以及故障诊断，通常，需要对运行的大数据组件进行监控。然而，相关的大数据组件监控技术中，由于通常需要依赖人工加载和删除监控方案，从而导致监控过程自动化程度较低，此外，在大数据组件数量巨大的情况下，还可能降低监控过程的处理效率。

技术实现要素：

本申请实施例提供一种大数据组件的监控方法，用以解决采用现有技术中通常需要依赖人工加载和删除监控方案，从而导致监控过程自动化程度较低的问题。

本申请实施例还提供一种大数据组件的监控装置，一种电子设备，以及一种计算机可读存储介质。

本申请实施例采用下述技术方案：

一种大数据组件的监控方法，包括：

监听服务器上是否存在待监控的目标组件；所述服务器，用于运行所述待监控的目标组件；

若监听到所述服务器上存在待监控的目标组件，则判断可用监控方案列表中是否存在与所述目标组件相匹配的监控方案，所述可用监控方案列表用于存储预先配置的监控方案；

若是，则获取与所述目标组件相匹配的所述监控方案并加载，以对所述目标组件进行监控。

一种大数据组件的监控装置，包括监听模块、判断模块和获取模块，其中：

监听模块，用于监听服务器上是否存在待监控的目标组件；所述服务器，用于运行所述待监控的目标组件；

判断模块，用于若监听到所述服务器上存在待监控的目标组件，则判断可用监控方案列表中是否存在与所述目标组件相匹配的监控方案，所述可用监控方案列表用于存储预先配置的监控方案；

获取模块，用于若所述可用监控方案列表中存在与所述目标组件相匹配的监控方案，则获取与所述目标组件相匹配的所述监控方案并加载，以对所述目标组件进行监控。

一种电子设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上所述的大数据组件的监控方法的步骤。

一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的大数据组件的监控方法的步骤。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

本申请实施例提供的方法，首先，预先配置大数据组件监控方案并存储于可用监控方案列表中；其次，通过监听服务器的运行情况从而确定待监控的目标组件，并在确定待监控的目标组件后，触发服务器判断可用监控方案列表中是否存在与目标组件相匹配的监控方案，最后，若判断可用监控方案列表中存在与目标组件相匹配的监控方案，则可以自动获取对应的监控方案并加载，以对目标组件进行监控，可见，整个监控过程不需要依赖人工加载，因此，避免了相关的大数据组件监控技术中，由于通常需要依赖人工加载和删除监控方案，从而导致监控过程自动化程度较低，以及在大数据组件数量巨大的情况下，还可能降低监控过程的处理效率的问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的一种大数据组件的监控方法的实现流程示意图；

图2为本申请实施例提供的一种大数据组件的监控方法的实现流程示意图；

图3为本申请实施例提供的一种大数据组件的监控装置的具体结构示意图；

图4为本申请实施例提供的一种大数据组件的监控电子设备的结构示意图。

具体实施方式

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

以下结合附图，详细说明本申请各实施例提供的技术方案。

实施例1

为了解决相关的大数据组件监控技术中，由于通常需要依赖人工加载和删除监控方案，从而导致监控过程自动化程度较低，以及在大数据组件数量巨大的情况下，还可能降低监控过程的处理效率的问题，本申请实施例1提供了一种大数据组件的监控方法。该方法的执行主体，可以但不限于是服务器或者由服务器构成的服务器集群等。

为方便说明，本申请以执行主体为服务器为例，对本申请的实施例进行介绍。可以理解，该方法的执行主体为服务器只是一种示例性的说明，并不应理解为对该方法的限定。

请参见图1，为本申请实施例提供的一种大数据组件的监控方法，该流程包括下述步骤：

步骤11，监听服务器上是否存在待监控的目标组件；

所述服务器，用于运行待监控的目标组件；本申请实施例中，服务器可以在待监控的目标组件上线\运行时，获取该客户端版本对应的配置文件，以确定该客户端版本的客户端中的各待监控的目标组件；或者，可以一并获取已经上线的若干客户端版本分别对应的配置文件，以确定每个上线的客户端版本的客户端中的各待监控的目标组件。

此外，由于如今的客户端更新非常频繁，往往需要针对每种功能，在服务端上部署该功能对应的很多版本的大数据组件，这将可能导致服务端越来越臃肿。如此一来，技术人员通常需要对服务器上每个正在运行的大数据组件进行监控，以实现对大数据组件、服务器进行调优以及故障诊断。基于此，本申请实施例中，所述待检测的目标组件可以包括各种可以在服务器上运行的大数据组件，例如，hadoop、elasticsearch、clickhouse、kafka等。

本申请实施例中，监听服务器上是否存在待监控的目标组件之前，可以预先为待监控的目标组件设置监控接口，以便在监听到服务器上存在待监控的目标组件时，可以调用预先设置的监控接口对目标组件进行监控。

步骤12，若监听到服务器上存在待监控的目标组件，则判断可用监控方案列表中是否存在与目标组件相匹配的监控方案；

所述可用监控方案列表，用于存储预先配置的大数据组件监控方案。

所述大数据组件监控方案，可以包括对大数据组件进行监控时，所需要部署的采集数据的程序以及程序的启动命令。为了方便后续查询，本申请实施例中，可以将预先配置的大数据组件监控方案统一存储至某一预设路径，例如可以存储至可用监控方案列表中，

在一个实施例中，由于后续操作过程中会有新的大数据组件监控方案产生，导致后续可能需要对预先配置的大数据组件监控方案进行横向扩展，因此，本申请中，还可以将预先配置的大数据组件监控方案上传到服务器或者将可用监控方案列表写入配置文件中，若后续产生新的大数据组件监控方案，则可以直接将新产生的大数据组件的监控方案上传服务器，或者将新产生的大数据组件的监控方案的服务的名称加入配置文件中，以实现横向扩展。

本申请实施例中，若通过步骤11监听到服务器上存在待监控的目标组件，则可以采用如下方法判断可用监控方案列表中是否存在与目标组件相匹配的监控方案：

步骤121，获取目标组件的相关信息；

其中，所述相关信息至少包括以下一种：目标组件的服务名称、目标组件对应的服务器的服务地址、目标组件对应的主机名称、目标组件对应的端口信息；

步骤122，根据相关信息判断可用监控方案列表中是否存在与目标组件相匹配的监控方案。

在本申请实施例步骤121中，获取目标组件的相关信息，具体可以是确定该客户端版本的客户端中的每个大数据组件的配置信息。

其中，大数据组件的配置信息具体可以包含两个方面的信息：1、大数据组件对应的功能信息；2、大数据组件的版本信息，如大数据组件的服务名称、大数据组件对应的服务器的服务地址、大数据组件对应的主机名称、大数据组件对应的端口信息以及支持的序列化协议(json、protobuf等)、代码的业务逻辑、要求的参数或格式等。

可选地，本申请中，为了提高获取相关信息的速度，可以仅获取待监控的目标组件的版本信息，例如，待监控的目标组件的服务名称、待监控的目标组件对应的服务器的服务地址、待监控的目标组件对应的主机名称、待监控的目标组件对应的端口信息。

其中，待监控的目标组件的服务名称用于确定与目标组件对应的监控方案；待监控的目标组件对应的主机名称用于确定目标组件运行的主机；待监控的目标组件对应的服务器的服务地址用于确定目标组件对应的服务器的服务地址；待监控的目标组件对应的端口信息，用于获取目标组件的相关信息。

具体地，获取目标组件的相关信息时，可以通过java程序实现，例如，首先，通过runtime执行linux命令，得到第一执行结果；其次，调用runtime.getruntime().exec(command)执行第一执行结果，并使用waitfor()方法等待命令执行完成；其中，runtime.exec方法可以产生一个本地的进程，并返回一个process子类的实例；然后，通过process.getinputstream()方法以及process.getoutputstream()方法对process子类的实例的输入、输出分别执行操作，以获取命令执行后的第二执行结果；最后，根据第二执行结果进行文本解析，即可获得服务器上运行的待监控的目标组件的的服务名称、目标组件对应的服务器的服务地址、目标组件对应的主机名称、目标组件对应的端口信息。

在一个实施例中，为了可以实现相关信息的通用性以及扩展性，通常可以对相关信息进行规范化管理，例如，可以将上述相关信息统一格式化，写入mysql数据库的元数据表中。

通过上述步骤121获取到目标组件的相关信息后，可以通过以下步骤，根据相关信息进一步判断可用监控方案列表中是否存在与目标组件相匹配的监控方案：

遍历可用监控方案列表，判断可用监控方案列表中是否存在与组件列表相匹配的大数据组件监控方案。

具体地，若可用监控方案列表中存在与组件列表中目标组件的服务名称一致的大数据组件监控方案，则判断可用监控方案列表中存在与组件列表相匹配的大数据组件监控方案。

例如，假设服务进程启动后，首先，通过加载配置文件，获取到预先配置的大数据组件监控方案的列表a；其次，读取mysql数据库中的元数据表，获取到服务器上正在运行待监控目标组件，并将目标组件的服务名称写入列表b中；最后，遍历该列表a，判断a中是否存在与b中目标组件的服务名称一致的大数据组件监控方案。

步骤13，若是，则获取与目标组件相匹配的监控方案并加载，以对目标组件进行监控。

步骤131，获取与目标组件对应的监控方案的启动命令；

步骤132，将监控方案的启动命令加载到与目标组件对应的服务器，以对目标组件进行监控。

沿用上述实例，若a中存在与b中的目标组件的服务名称一致的大数据组件监控方案则获取该监控方案，并获取对应的启动命令，进而将监控方案的启动命令加载到与目标组件对应的服务器，以对目标组件进行监控。

可选地，本申请实实例中，可以在启动命令启动后，将监控方案以目标组件对应的服务器的服务地址以及目标组件对应的端口信息为关键字，写入时序数据库的配置文件中，以便后续查询监控方案。其中，所述时序数据库，用于存储采集的数据。

可选地，本申请实施例中，对目标组件进行监控时，服务器可以通过监控接口将监控到的各目标组件的状态信息反馈给监控报告页面。其中，监控报告会显示的信息包括目标组件的服务名称、监控时间以及监控状态信息，比如，目标组件的运行状态。

在一个实施例中，可以将监控报告存储到服务器的时序数据库中，以便能够实时监控各组件的状态，及时发现进程宕掉的问题，甚至能够选择重新安装某个目标组件。

具体地，由于待监控的目标组件的服务名称是唯一的，因此，若后续需要在监控报告页面查询目标组件的信息，则只需要在时序数据库中输入目标组件的服务名称即可以进行查询。

需要说明的是，在展示之前，需要对某些数据依据其本身的性质来进行相应的处理，比如要展示数据库的数据总量，就要对各个服务器上获取的数据量做一个累加，例如sum()函数，这里的处理可以通过prometheus的内置函数就可以实现，要做什么样的处理是根据业务逻辑来定的，并且展示页面开发完成部署的时候一键导入即可。

采用本申请实施例提供的方法，首先，预先配置大数据组件监控方案并存储于可用监控方案列表中；其次，通过监听服务器的运行情况从而确定待监控的目标组件，并在确定待监控的目标组件后，触发服务器判断可用监控方案列表中是否存在与目标组件相匹配的监控方案，最后，若判断可用监控方案列表中存在与目标组件相匹配的监控方案，则可以自动获取对应的监控方案并加载，以对目标组件进行监控，可见，整个监控过程不需要依赖人工加载，因此，避免了相关的大数据组件监控技术中，由于通常需要依赖人工加载和删除监控方案，从而导致监控过程自动化程度较低，以及在大数据组件数量巨大的情况下，还可能降低监控过程的处理效率的问题。

本申请实施例中，由于如今的客户端更新非常频繁，往往需要针对每种功能，在服务端上部署该功能对应的很多版本的大数据组件，因此，针对很多版本的大数据组件，服务端上还会有很多对应的的监控方案，这将可能导致服务端越来越臃肿，进而影响服务器的服务性能，基于此，本申请实施例中还提供以下删除监控方案的方法，以提高服务器的服务性能：

当监听到目标组件完成监控后，根据预设脚本删除所述监控方案，以停止对所述目标组件进行监控。

具体地，当监听到目标组件完成监控后，若要对某个待监控的目标组件的监控方案进行删除，则可以直接调用删除脚本，并将待监控的目标组件对应的监控方案的名称传递给删除脚本，其中，删除脚本接收到监控方案的名称后，可以自动地调用卸载程序去元数据表中读取监控方案的相关信息，以便获取该监控方案运行在哪些服务器上，然后按照顺序，删除每台服务器运行的该监控方案。

采用该方法，可以避免相关技术中由于通常需要依赖删除监控方案，从而导致监控过程自动化程度较低，以及在大数据组件数量巨大的情况下，还可能降低监控过程的处理效率的问题。

以下通过介绍实施例2，对本申请实施例提供的大数据组件的监控方法作进一步说明。

实施例2

为了解决相关的大数据组件监控技术中，由于通常需要依赖人工加载和删除监控方案，从而导致监控过程自动化程度较低，以及在大数据组件数量巨大的情况下，还可能降低监控过程的处理效率的问题，本申请实施例提供一种大数据组件监控方法。

为方便描述，以下以执行主体为服务器为例，对本申请实施例进行介绍。如图2所示，本申请实施例提供一种大数据组件的监控方法，该流程包括下述步骤：

步骤21，确定服务器当前正在运行的大数据组件；

由于为了实现各种各样的服务功能，通常需要在服务端上部署该功能对应的很多版本的大数据组件，如此一来，可能导致服务端越来越臃肿，无法对大数据组件进行调优以及故障诊断，因此，通常需要对服务器上每个正在运行的大数据组件进行监控，以实现对大数据组件、服务器进行调优以及故障诊断。基于此，本申请中，可以先确定服务器上当前正在运行的大数据组件，例如，hadoop、elasticsearch、clickhouse、kafka等，以便确定待监控的目标组件。

此外，本申请实施例中，还需要获取待监控的目标组件的相关信息，所述相关信息至少包括以下一种：目标组件的服务名称、目标组件对应的服务器的服务地址、目标组件对应的主机名称、目标组件对应的端口信息。

其中，获取待监控的目标组件的相关信息时，可以采用如上述实施例1所提供的获取相关信息的方法，为避免赘述，此处不再说明。

确定服务器当前正在运行的大数据组件/待监控的目标组件后，可以执行下述步骤22，以确定与所述大数据组件/待监控的目标组件对应的监控方案，进而对当前运行的大数据组件/待监控的目标组件进行监控。

所述监控方案，可以包括对大数据组件进行监控时，所需要部署的采集数据的程序以及程序的启动命令。本申请实施例中，可以将预先配置的大数据组件监控方案统一存储至可用监控方案列表中，以便后续查询。

步骤22，确定与当前正在运行的大数据组件对应的监控方案，并自动加载该监控方案，以实现大数据组件的监控。

本申请实施例中，首先，可以加载配置文件，获取到预先配置的大数据组件监控方案的列表a；其次，读取mysql数据库中的元数据表，获取到服务器上正在运行待监控目标组件，并将目标组件的服务名称写入列表b中；最后，遍历该列表a，判断a中是否存在与b中目标组件的服务名称一致的大数据组件监控方案。

若a中存在与b中目标组件的服务名称一致的大数据组件监控方案，则获取与目标组件相匹配的监控方案并加载，以对目标组件进行监控。

需要说明的是，为了避免相关技术中由于通常需要依赖删除监控方案，从而导致监控过程自动化程度较低，以及在大数据组件数量巨大的情况下，还可能降低监控过程的处理效率的问题，本申请实施例中，当监听到目标组件完成监控后，还根据预设脚本删除所述监控方案，以停止对所述目标组件进行监控。

由于本发明实施例采用与上述实施例1相同的申请构思，因此也能够解决现有技术中的问题，此处不再赘述。

实施例3

出于与上述方法相同的发明构思，本申请实施例还提供一种大数据组件的监控装置，用于解决相关的大数据组件监控技术中，由于通常需要依赖人工加载和删除监控方案，从而导致监控过程自动化程度较低，以及在大数据组件数量巨大的情况下，还可能降低监控过程的处理效率的问题。

该大数据组件的监控装置30的具体结构示意图如图3所示，包括监听模块31、判断模块32以及获取模块33，其中，各模块功能如下：

监听模块31，用于监听服务器上是否存在待监控的目标组件；所述服务器，用于运行所述待监控的目标组件；

判断模块32，用于若监听到所述服务器上存在待监控的目标组件，则判断可用监控方案列表中是否存在与所述目标组件相匹配的监控方案，所述可用监控方案列表用于存储预先配置的的大数据组件监控方案；

获取模块33，用于当所述可用监控方案列表中存在与所述目标组件匹配的监控方案时，获取与所述目标组件对应的所述监控方案并加载，以对所述目标组件进行监控。

其中，所述判断模块31，具体包括获取第一单元以及第一判断单元，各单元的功能如下：

获取单元，用于获取所述目标组件的相关信息；其中，所述相关信息至少包括以下一种：所述目标组件的服务名称、所述目标组件对应的服务器的服务地址、所述目标组件对应的主机名称、所述目标组件对应的端口信息；

判断单元，用于根据所述相关信息判断所述可用监控方案列表中是否存在与所述目标组件相匹配的监控方案。

可选地，本申请实施例中，获取单元具体可以用于：

获取所述目标组件的相关信息，并将所述相关信息中的所述目标组件的服务名称写入组件列表；其中，所述相关信息至少包括以下一种：所述目标组件的服务名称、所述目标组件对应的服务器的服务地址、所述目标组件对应的主机名称、所述目标组件对应的端口信息；

可选地，本申请实施例中，判断单元具体可以用于：

遍历所述可用监控方案列表，判断所述可用监控方案列表中是否存在与所述组件列表相匹配的所述大数据组件监控方案。

具体地，若所述可用监控方案列表中存在与所述组件列表中所述目标组件的服务名称一致的所述大数据组件监控方案的名称，则判断所述可用监控方案列表中存在与所述组件列表相匹配的所述大数据组件监控方案。

所述获取模块33，具体包括第二获取单元以及监控单元，各单元的功能如下：

第二获取单元，用于获取与所述目标组件对应的所述监控方案的启动命令；

监控单元，用于将所述监控方案的启动命令加载到与所述目标组件对应的服务器，以对所述目标组件进行监控。

采用本申请提供的装置，首先，预先配置大数据组件监控方案并存储于可用监控方案列表中；其次，监听模块通过监听服务器的运行情况从而确定待监控的目标组件，并且判断模块在确定待监控的目标组件后，触发服务器判断可用监控方案列表中是否存在与目标组件相匹配的监控方案，最后，若可用监控方案列表中存在与目标组件相匹配的监控方案，获取模块则可以自动获取对应的监控方案并加载，以对目标组件进行监控，整个监控过程不需要依赖人工加载，因此，避免了相关的大数据组件监控技术中，由于通常需要依赖人工加载和删除监控方案，从而导致监控过程自动化程度较低，以及在大数据组件数量巨大的情况下，还可能降低监控过程的处理效率，避免了现有技术中由于通常需要依赖人工加载和删除监控方案，从而导致监控过程自动化程度较低，以及在大数据组件数量巨大的情况下，还可能降低监控过程的处理效率的问题。

可选地，本申请实施例提供的装置，还可以包括停止监控模块，用于：

当监听到目标组件完成监控后，根据预设脚本删除所述监控方案，以停止对所述目标组件进行监控。

采用本申请提供的装置，可以避免相关技术中由于通常需要依赖删除监控方案，从而导致监控过程自动化程度较低，以及在大数据组件数量巨大的情况下，还可能降低监控过程的处理效率的问题。

实施例4

本申请实施例，还提供一种用于设备控制的智能设备，该智能设备的硬件结构示意图如图4所示，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(random-accessmemory，ram)，也可能还包括非易失性存储器(non-volatilememory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是isa(industrystandardarchitecture，工业标准体系结构)总线、pci(peripheralcomponentinterconnect，外设部件互连标准)总线或eisa(extendedindustrystandardarchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成数据同步装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

监听服务器上是否存在待监控的目标组件；所述服务器，用于运行所述待监控的目标组件；

若监听到所述服务器上存在待监控的目标组件，则判断可用监控方案列表中是否存在与所述目标组件相匹配的监控方案，所述可用监控方案列表用于存储预先配置的大数据组件监控方案；

若是，则获取与所述目标组件相匹配的所述监控方案并加载，以对所述目标组件进行监控。

在一种情况下，处理器还可以执行以下操作：获取所述目标组件的相关信息；其中，所述相关信息至少包括以下一种：所述目标组件的服务名称、所述目标组件对应的服务器的服务地址、所述目标组件对应的主机名称、所述目标组件对应的端口信息；

根据所述相关信息判断所述可用监控方案列表中是否存在与所述目标组件相匹配的监控方案。

具体地，若可用监控方案列表中存在与组件列表中目标组件的服务名称一致的大数据组件监控方案，则判断可用监控方案列表中存在与组件列表相匹配的大数据组件监控方案。

可选地，处理器获取与目标组件对应的监控方案并加载，以对目标组件进行监控，具体包括：

获取与目标组件对应的监控方案的启动命令；

将监控方案的启动命令加载到与目标组件对应的服务器，以对目标组件进行监控。

上述如本申请图4所示实施例揭示的大数据组件的监控方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，cpu)、网络处理器(networkprocessor，np)等；还可以是数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(field－programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

当然，除了软件实现方式之外，本申请的电子设备并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

另外，图4还包括一些未示出的功能模块，在此不再赘述。

本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述大数据组件的监控方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(read-onlymemory，简称rom)、随机存取存储器(randomaccessmemory，简称ram)、磁碟或者光盘等。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本发明的实施例而已，并不用于限制本发明。对于本领域技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本发明的权利要求范围之内。