CN112698929A - 一种信息采集方法及装置 - Google Patents

Abstract

本发明公开了一种信息采集方法及装置。该方法包括：由多个第一处理程序对等地接收任务请求，获取设备列表并将所述任务请求拆分为多个子任务，将所述子任务发送给高可用的消息队列中间件MQ；之后，再由多个第二处理程序对等地从所述消息队列中间件处获取所述子任务并处理相应的子任务，其中所述第二处理程序的个数可根据所述子任务的个数进行相应的调整。如此，通过多个对等的程序接收任务请求，并使用高可用的消息队列中间件MQ进行任务调度，再由多个对等的程序获取并处理这些任务，从而实现了从接收任务、调度任务到处理任务各个环节的高可用。

Description

一种信息采集方法及装置

技术领域

本发明涉及计算机信息处理领域，尤其涉及一种信息采集方法及装置。

背景技术

随着通信技术和互联网的日益发展和进步，使用跨地区和跨时区的分布式存储设备或计算设备组成的超大数据运算平台，也日益成为一种趋势。

然后如何从这些日益增长的分布式设备上收集设备的相关信息，例如配置数据；性能数据；状态数据等等，并对这些数据进行统一管理，也成为越来越困难的一件事。

现有的设备信息采集系统，大多采用1个主节点多个代理节点的系统架构，且将数据抓取、存储、展现功能集成在一起，扩展性低且欠缺高可用性方案。在这种架构下，一旦设备增长到一定数目，例如200多设备时，主节点存在明显的性能瓶颈。

因此，如何搭建一个可扩展、高可用的分布式信息采集平台，并在其基础之上实现一种可伸缩性更强的设备信息采集方法，还是尚待解决的一个技术问题。

发明内容

针对以上问题，本发明实施例提供了一种信息采集方法、装置及存储介质。

根据本发明实施例第一方面，一种信息采集方法，该方法包括：由多个第一处理程序对等地接收任务请求，获取设备列表并将任务请求拆分为多个子任务，并将子任务发送给高可用的消息队列中间件MQ；消息队列中间件接收到子任务后，通知多个第二处理程序提取子任务进行处理；由多个第二处理程序对等地从消息队列中间件处获取子任务并处理相应的子任务。

根据本发明实施例一实施方式，任务请求包括信息采集任务，相应地，处理相应的子任务包括采集相应设备的信息。

根据本发明实施例一实施方式，在采集相应设备的信息之前，该方法还包括：自定义要采集的信息。

根据本发明实施例一实施方式，在采集相应设备的信息之后，该方法还包括：将采集到的信息存储到与其他应用所共享的信息存储系统中。

根据本发明实施例一实施方式，在采集相应设备的信息之后，该方法还包括：根据信息采集任务所采集到的信息，并结合其他设备管理信息，判断是否存在资源占用异常的设备，若存在，则生成针对相应设备的资源调优任务，并将资源调优任务发送给多个第一处理程序。

根据本发明实施例一实施方式，任务请求还包括资源调优任务。

根据本发明实施例一实施方式，获取设备列表，包括：从配置管理数据库CMDB中获取设备列表，其中，配置管理数据库还存储有与设备对应的其他设备管理信息；相应地，在处理相应的子任务之后，该方法还包括：根据子任务的处理结果，更新配置管理数据库的设备列表和/或其他设备管理信息。

根据本发明实施例一实施方式，消息队列中间件有多个实例，相应地，将子任务发送给高可用的消息队列中间件，包括：将子任务发送给高可用的消息队列中间件中，与子任务对应设备位置邻近的实例。

根据本发明实施例一实施方式，在将任务请求拆分为多个子任务之后，该方法还包括：获取子任务数量；根据子任务数量调整第二处理程序的个数。

根据本发明实施例第二方面，提供一种信息采集装置，该装置包括：任务请求接收模块，用于对等地接收任务请求；设备列表获取模块，用于获取设备列表；子任务拆分模块，用于将任务请求拆分为多个子任务；子任务发送模块，用于将子任务发送给高可用的消息队列中间件MQ；子任务调度模块，用于在接收到子任务后，通知多个第二处理程序提取子任务进行处理；子任务处理模块，用于对等地从消息队列中间件处获取子任务并处理相应的子任务。

根据本发明实施例第三方面，一种计算机存储介质，在计算机存储介质上存储了程序指令，程序指令在运行时用于执行上述任一项的信息采集方法。

本发明实施例提供一种信息采集方法、装置及计算机存储介质，该方法包括：由多个第一处理程序对等地接收任务请求，获取设备列表并将所述任务请求拆分为多个子任务，将所述子任务发送给高可用的消息队列中间件MQ；之后，再由多个第二处理程序对等地从所述消息队列中间件处获取所述子任务并处理相应的子任务，其中所述第二处理程序的个数可根据所述子任务的个数进行相应的调整。如此，通过多个对等的程序接收任务请求，并使用高可用的消息队列中间件MQ进行任务调度，再由多个对等的程序获取并处理这些任务，从而实现了从接收任务、调度任务到处理任务各个环节的高可用。

需要理解的是，本发明的教导并不需要实现上面所述的全部有益效果，而是特定的技术方案可以实现特定的技术效果，并且本发明的其他实施方式还能够实现上面未提到的有益效果。

附图说明

通过参考附图阅读下文的详细描述，本发明示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本发明的若干实施方式，其中：

在附图中，相同或对应的标号表示相同或对应的部分。

图1为本发明实施例信息采集方法的实现流程示意图；

图2为本发明实施例信息采集方法一应用的具体实现流程示意图；

图3为本发明实施例信息采集装置的组成结构示意图。

具体实施方式

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

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

图1示出了本发明实施例信息采集方法的实现流程。参考图1，该方法包括：操作110，由多个第一处理程序对等地接收任务请求，获取设备列表并将任务请求拆分为多个子任务，并将子任务发送给高可用的消息队列中间件MQ；操作120，消息队列中间件接收到子任务后，通知多个第二处理程序提取子任务进行处理；操作130，由多个第二处理程序对等地从消息队列中间件处获取子任务并处理相应的子任务。

在操作110中，第一处理程序可以是应用程序；也可以是网络服务；还可以是接收网络请求的一个页面等。第一处理程序可以部署在分布式的各个服务器或处理节点上，其中，服务器对应的也可能是一个虚拟机；此外，在同一个服务器或处理节点上的第一处理程序还可以运行在多个程序执行容器(例如，docker)中，形成多个独立且对等的实例。通常，在第一处理程序的前端通常会设置一个负载均衡器(load balancer)或代理(agent)以实现多个第一处理程序可对等地接收任务请求，以实现接收任务请求的高可用性。

之后，为了进一步提高后续处理作业的并发性，可根据设备列表并将任务请求拆分为多个子任务。

其中，设备列表可以是通过任务请求中的参数指定的；也可以是从某个指定的设备配置信息管理数据库中获取的；还可以是配置文件中指定的等。

子任务指结合设备列表对接收的任务请求进行拆分得到的、可以单独运行的任务单元。例如，假设接收到任务“收集区域B内所有设备的剩余存储空间”，其中，获取到的区域B内的所有设备列表为：server01、server 02、……、server15，则可将任务拆解为“子任务01：收集server01的剩余存储空间”、“子任务02：收集server02的剩余存储空间”、……、“子任务15：收集server15的剩余存储空间”。

将子任务发送给高可用的消息队列中间件，主要指通过作为消息队列中间件的生产者，将任务作为消息放入到某个消息队列中。

如此，一个任务可以分解为可并发执行的多个子任务，提高了程序运行的效率，可大幅缩短执行时间。

在操作120中，消息队列中间件主要指通过集群系统实现消息队列高可用和持久化的中间件。而消息队列则是一种先进先出的数据结构，数据生成者可以将需要提供的数据放入消息队列，即可返回不必等等，而数据的消费者则可以通过订阅或由消息队列中间件推送的方式异步拿到所需的数据进行处理，特别适合用于解决分布式系统中应用耦合，异步消息和流量削锋等问题。

对于本发明实施方式的应用场景来说，设备信息的采集任务可划分为针对设备列表中每个设备的多个可并行执行的子任务，而这些子任务都是可以异步执行的。因此，引入消息队列中间件进行任务分配，比起传统的任务分配方法，可大大提高系统的处理能力。

举例说明如下：假设某个任务请求要采集100个设备的信息，其中解析和拆分这一任务请求的时间为50毫秒，每次采集一个设备的信息所需的时间为50毫秒，在不考虑网络传输延迟的情况下，串行执行该任务请求的时间是5050(50*11)毫秒，并行执行该任务请求的时间是100(50+50)毫秒。

在没有引入消息队列的情况下，上述任务请求会由运行第一处理程序的某个服务器或节点来处理，在串行执行该任务请求时，1秒内CPU的处理量大约是0.2次(1000/5050)；在并行方式处理的请求量是10次(1000/100)。

在引入了消息队列的情况下，运行第一处理程序的服务器或节点只需解析和拆分这一任务请求，而无需执行各个采集单个设备信息的子任务。此时，每次处理时间从最少100毫秒降到了50毫秒，1秒内CPU的处理量大约是20次(1000/50)。

由此可见，采用了消息队列之后，可大大提高第一处理程序运行端服务器的CPU在单位时间内的处理量。

而在运行第二处理程序端的服务器或节点，在没有引入消息队列中间件时，每个服务器或节点都会随机地收到个数不等的信息采集子任务，由每个服务器或节点的硬件性能可能不同，某一时段的额负载也可能不同，有可能造成，某些服务器或节点已经完成了分配的信息采集子任务，而某些的服务器或节点还有很多信息采集子任务没处理完的情况。

在引入了消息队列之后，每个第二处理程序可根据自己的处理能力，逐一从消息队列中获取单个信息采集子任务。如此，即使运行第二处理程序端的某个服务器或节点的处理速度较慢，也不会成为任务请求处理的瓶颈。

由此可见，引入了消息队列之后，还可从而大大提高信息采集子任务请求的处理效率，并使总处理时长缩短。

在操作130中，第二处理程序主要指消息队列中间件上的消息队列的消费者，作为消息队列的消费者，从消息队列中获取消息进行处理的节点。其中，第二处理程序可以是应用程序；也可以是网络服务；还可以是可执行的脚本程序等。

第二处理程序可以部署在分布式的各个服务器或处理节点上，在同一个服务器或处理节点上的第二处理程序还可以运行在多个程序执行容器中(例如，docker)，形成多个独立且对等实例。

第二处理程序还可以通过订阅的方式与MQ建立注册关系，并在MQ队列中存放有需要处理的消息时，就会收到相应的通知。

第二处理程序作为消息队列的消费者，对等地从消息队列中间件处获取子任务，并进行相应地处理。

由此可见，通过多个对等的程序接收任务请求，并使用高可用的消息队列中间件MQ进行任务调度，再由多个对等的程序获取并处理这些任务，从而实现了从接收任务、调度任务到处理任务各个环节的高可用。

根据本发明实施例一实施方式，任务请求包括信息采集任务，相应地，处理相应的子任务包括采集相应设备的信息。

根据本发明实施例一实施方式，在采集相应设备的信息之前，该方法还包括：自定义要采集的信息。

在本实施方式中，信息采集的任务是通过实施方自行开发实现的第二程序来执行的，因此，可以通过编程自定义要采集的信息，例如，通过存储接口获取数据，而存储类型及相关指标都可灵活定制，包括：可以通过任务请求中的某些参数来指定相关指标；也可以通过某些配置文件来定义要采集的相关指标等等。

比起使用第三方信息采集系统中预置的信息种类，可采集的信息种类可以根据需要自行定义，并可以不断扩充，执行起来也更为灵活。

根据本发明实施例一实施方式，在采集相应设备的信息之后，该方法还包括：将采集到的信息存储到与其他应用所共享的信息存储系统中。

在本实施方式中，信息存储系统可以是网络共享文件系统、分布式数据库、配置信息表等。这些信息存储系统中的信息，可以被其他应用，例如，设备信息管理系统、系统状态跟踪系统、报表系统等共享，避免了信息的重复采集，并可以更方便地实现各个系统中的信息同步。

根据本发明实施例一实施方式，在采集相应设备的信息之后，该方法还包括：根据信息采集任务所采集到的信息，并结合其他设备管理信息，判断是否存在资源占用异常的设备，若存在，则生成针对相应设备的资源调优任务，并将资源调优任务发送给多个第一处理程序。

在本实施方式中，其他设备管理信息主要指设备的用途信息(用于哪些处理业务)以及根据用途信息设置的资源使用阈值，例如，CPU使用情况、内存分配情况、硬盘存储空间使用情况、连接数、IO访问次数等。

在判断是否存在资源占用异常的设备时，可使用采集到的信息与相应资源使用阈值进行比对，如果有超出阈值范围的情况，则可任务出现了资源占用异常的情况。

资源调优任务主要指根据资源占用异常情况生成的、相应地资源管理任务，例如，终止占用资源过多的程序；挂起、重启或删除资源占用异常的服务器等；重新为资源占用异常的设备分配资源等。

在本实施方式中，不仅会完成日常的信息采集任务，还会根据采集到的信息，定期监测设备的资源占用情况，从而形成信息反馈机制，以便自动发现并及时处理相应的异常事件，使设备尽可能地处于良好可控的状态。

根据本发明实施例一实施方式，任务请求还包括资源调优任务。

在本实施方式中，高可用的信息采集架构，还可以用于执行资源调优任务。如此，可减少系统的重复搭建，提高各个处理节点的利用率，并可对信息采集和资源调优进行集中管理，形成良性循环。

根据本发明实施例一实施方式，获取设备列表，包括：从配置管理数据库CMDB中获取设备列表，其中，配置管理数据库还存储有与设备对应的其他设备管理信息；相应地，在处理相应的子任务之后，该方法还包括：根据子任务的处理结果，更新配置管理数据库的设备列表和/或其他设备管理信息。

比起自行维护的设备列表的方式，在本实施方式中，与CMDB建立连接并从CMDB中直接获取设备列表，可实时及时获知设备的更新情况和最新状态，无需定期同步，大大减少了更新延迟和信息不准确的问题。

此外，在处理相应的子任务之后根据子任务的处理结果，更新配置管理数据库的设备列表和/或其他设备管理信息，也可直接形成设备信息的闭环管理。

根据本发明实施例一实施方式，消息队列中间件有多个实例，相应地，将子任务发送给高可用的消息队列中间件，包括：将子任务发送给高可用的消息队列中间件中，与子任务对应设备位置邻近的实例。

在本实施方式中，使用子任务对应设备位置邻近的实例，例如，通过IP地址进行配对，可缩短网络传输的事件，从而缩短整个任务的处理时间。

根据本发明实施例一实施方式，在将任务请求拆分为多个子任务之后，该方法还包括：获取子任务数量；根据子任务数量调整第二处理程序的个数。

第二处理程序的个数，主要指第二处理程序运行在不同服务器或处理节点上不同容器中的实例个数，可通过不同服务器或处理节点的应用程序管理工具新建或删除第二处理程序的运行实例来实现调整第二处理程序的个数。

当子任务数量较多时，可新创建第二处理程序的运行实例以尽快提取消息队列中的子任务；相反，当子任务数量较多时，可删除第二处理程序的运行实例，腾出更多的系统资源。如此，可尽量减少因为第二处理程序的实例过少处理不过来的情况；同时，还可充分利用现有的系统资源，进一步提高系统资源的利用率。

图2示出了本发明实施例信息采集方法一应用的具体实现流程。如图2所示，在这一应用中，任务请求处理程序202以及子任务执行程序204是通过kubernetes+docer部署的微服务来实现的，这些微服务(例如，任务请求处理程序202和子任务执行程序204)部署在kubernetes上的多个虚拟机服务器(Node/Worker)中的多个运行容器(例如，docker)上。通过这种部署方式，可以实现多个处理程序实例之间的对等关系和高可用机制，即当某个容器或某个虚拟机出现故障时，不会影响其他容器或虚拟机，也不影响采集任务的处理和推进，同时增加整个应用的任务并行处理能力。

在这一应用中，执行信息采集任务的具体流程大致如下：

首先，由任务调度器201通过定时任务(例如，cronjob)或接收到执行信息采集的命令后，触发信息采集任务；

接下来，这些任务会被多个任务请求处理程序202(第一处理程序)，这些请求处理程序202也部署在kubernetes上某些虚拟机(Node/Worker)中的多个运行容器(dockers)上，以实现对任务请求的对等接收和处理；

在每个任务请求处理程序202处理信息采集任务时，会先从配置管理数据(CMDB)208处获取设备列表，然后将接收到的信息采集任务拆分成针对每一设备的子任务。例如，接收到任务“收集机房A所有设备的CPU使用情况”；从CMDB中获取机房A的所有设备，比如，server01、server 02、……、server15；将任务拆解为“子任务01：收集server01的CPU使用情况”、“子任务02：收集server02的CPU使用情况”、……、“子任务15：收集server15的CPU使用情况”。随后，获取各个服务器的IP地址，并将各个子任务发送到与该IP地址邻近的消息队列(MQ)203(例如，RabbitMQ)上；

之后，消息队列(MQ)203接收到相关任务，就会通知注册接收该消息队列任务的子任务执行程序204(第二处理程序)来提取信息采集子任务；

随后，子任务执行程序204获取到信息采集子任务，例如，“子任务01：收集server01的CPU使用情况”，就会去访问server01并收集server01的CPU使用情况，获得结果后，将采集到的结果发送给性能信息系统206(例如，Prometheus)或配置/状态信息数据库205(例如，MySQL)。

然后，在采集完信息之后，任务调度器201还会根据CMDB的设备管理信息包括业务优先级、业务所连接的设备、可分配给业务使用的CPU占比或存储空间，以及配置/状态数据库205和性能信息系统206中采集到的信息去检查Server01是否存在异常的资源占用情况。

例如，在CMDB中的信息表明:当前有2套业务系统的主机使用了同一套存储，分别为订单业务主机server01(S1，最高级别，IO延时敏感)和报表业务server02(S3，中级别，IO延时不敏感)，两台业务主机使用的相同的存储性能配额(如10000iops)。在某一时刻，根据性能采集数据发现，2台主机的读写响应延时均超过10ms。

而根据CMDB中业务分级的定义，此时的读写延时超过了S1级别业务的警戒阈值，而未达到S3级别业务的警戒阈值。因此，在任务调度器201上触发针对S1级别业务的资源调优任务。

之后，任务调度器201会启动处理资源调优任务的流程来处理上述资源调优任务，包括：

将该资源调优任务发送给某个任务请求处理程序202，由任务请求处理程序202将该资源调优任务发送到与server01邻近的消息队列(MQ)中；

消息队列(MQ)通知注册接收该消息队列任务的子任务执行程序204(此时作为资源调优执行器)来提取资源调优子任务；

通过子任务处理程序204访问server01，优先对订单业务主机server01的存储性能配额阈值进行调整，(以10％为单位)。调整后继续比对采集到的性能指标，如果订单系统主机的读写延时降低到S1级别业务的性能警戒阈值以下，则停止调整；否则继续调整。

假设在另一种情况下，如果子任务处理程序204接收到的任务是“终止server01”的话，则还需要更新CMB中的设备列表，将server01删除。

在上述信息采集过程中或调配资源任务的执行过程中，任务规模调度207会定时检查MQ中的任务数，并根据MQ中的任务数动态调整子任务执行程序204的实例个数。

此外，由于信息采集和资源调优任务是通过RestfulAPI实现的微服务，在实现其功能的代码中时可以通过存储接口获取数据，并灵活定制存储类型及相关指标的，从而实现自定义要采集的信息。

进一步地，本发明实施例还提供一种信息采集装置，如图3所示，该装置30包括：任务请求接收模块301，用于对等地接收任务请求；设备列表获取模块302，用于获取设备列表；子任务拆分模块303，用于将任务请求拆分为多个子任务；子任务发送模块304，用于将子任务发送给高可用的消息队列中间件MQ；子任务调度模块305，用于在接收到子任务后，通知多个第二处理程序提取子任务进行处理；子任务处理模块306，用于对等地从消息队列中间件处获取子任务并处理相应的子任务。

根据本发明实施例一实施方式，任务请求接收模块301具体用于接收信息采集任务，相应地，子任务处理模块306具体用于采集相应设备的信息

根据本发明实施例一实施方式，该装置30还包括采集信息自定义模块，用于自定义要采集的信息。

根据本发明实施例一实施方式，该装置30还包括信息存储模块，用于将采集到的信息存储到与其他应用所共享的信息存储系统中。

根据本发明实施例一实施方式，该装置30还包括：资源异常判断模块，用于根据信息采集任务所采集到的信息，并结合其他设备管理信息，判断是否存在资源占用异常的设备；资源调优任务生成模块，用于生成针对相应设备的资源调优任务；资源调优任务发送模块，用于将资源调优任务发送给多个第一处理程序。

根据本发明实施例一实施方式，任务请求接收模块301具体用于接收资源调优任务。

根据本发明实施例一实施方式，设备列表获取模块302具体用于从配置管理数据库CMDB中获取设备列表，其中，配置管理数据库还存储有与设备对应的其他设备管理信息；相应地，该装置30还包括数据更新模块，用于根据子任务的处理结果，更新配置管理数据库的设备列表和/或其他设备管理信息。

根据本发明实施例一实施方式，消息队列中间件有多个实例，相应地，子任务发送模块304具体用于将子任务发送给高可用的消息队列中间件中，与子任务对应设备位置邻近的实例。

根据本发明实施例一实施方式，该装置30还包括：子任务数量获取模块，用于获取子任务数量；第二处理程序数量调整模块，用于根据子任务数量调整第二处理程序的个数。

根据本发明实施例第三方面，一种计算机存储介质，在计算机存储介质上存储了程序指令，程序指令在运行时用于执行上述任一项的信息采集方法。

这里需要指出的是：以上针对信息采集装置实施例的描述和以上针对计算机存储介质实施例的描述，与前述方法实施例的描述是类似的，具有同前述方法实施例相似的有益效果，因此不做赘述。对于本发明对信息采集装置实施例的描述和对计算机存储介质实施例的描述尚未披露的技术细节，请参照本发明前述方法实施例的描述而理解，为节约篇幅，因此不再赘述。

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

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其他的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个装置，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其他形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以利用硬件的形式实现，也可以利用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储介质、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例方法的全部或部分。而前述的存储介质包括：移动存储介质、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (10)

1.一种信息采集方法，所述方法包括：

由多个第一处理程序对等地接收任务请求，获取设备列表并将所述任务请求拆分为多个子任务，并将所述子任务发送给高可用的消息队列中间件MQ；

消息队列中间件接收到所述子任务后，通知多个第二处理程序提取所述子任务进行处理；

由所述多个第二处理程序对等地从所述消息队列中间件处获取所述子任务并处理相应的子任务。

2.根据权利要求1所述的方法，所述任务请求包括信息采集任务，相应地，所述处理相应的子任务包括采集相应设备的信息。

3.根据权利要求2所述的方法，在采集相应设备的信息之前，所述方法还包括：

自定义要采集的信息。

4.根据权利要求2所述的方法，在所述采集相应设备的信息之后，所述方法还包括：

将所述采集到的信息存储到与其他应用所共享的信息存储系统中。

5.根据权利要求2所述的方法，在所述采集相应设备的信息之后，所述方法还包括：

根据所述信息采集任务所采集到的信息，并结合其他设备管理信息，判断是否存在资源占用异常的设备，若存在，则生成针对相应设备的资源调优任务，并将所述资源调优任务发送给所述多个第一处理程序。

6.根据权利要求5所述的方法，所述任务请求还包括资源调优任务。

7.根据权利要求1所述的方法，所述获取设备列表，包括：

从配置管理数据库CMDB中获取设备列表，其中，所述配置管理数据库还存储有与所述设备对应的其他设备管理信息；

相应地，在所述处理相应的子任务之后，所述方法还包括：

根据所述子任务的处理结果，更新所述配置管理数据库的设备列表和/或其他设备管理信息。

8.根据权利要求1所述的方法，所述消息队列中间件有多个实例，相应地，将所述子任务发送给高可用的消息队列中间件，包括：

将所述子任务发送给高可用的消息队列中间件中，与所述子任务对应设备位置邻近的实例。

9.根据权利要求1所述的方法，在将所述任务请求拆分为多个子任务之后，所述方法还包括：

获取子任务数量；

根据所述子任务数量调整所述第二处理程序的个数。

10.一种信息采集装置，所述装置包括：

任务请求接收模块，用于对等地接收任务请求；

设备列表获取模块，用于获取设备列表；

子任务拆分模块，用于将所述任务请求拆分为多个子任务；

子任务发送模块，用于将所述子任务发送给高可用的消息队列中间件MQ；

子任务调度模块，用于在接收到所述子任务后，通知多个第二处理程序提取所述子任务进行处理；

子任务处理模块，用于对等地从所述消息队列中间件处获取所述子任务并处理相应的子任务。

Images