CN116244144A - 故障类型查询方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请实施例提供了一种故障类型查询方法、装置、电子设备及存储介质，涉及信息技术领域。其中，该方法包括：若检测到发生故障，则确定与所发生故障有关的采集目录；所述采集目录用于指示所发生故障需要采集的目标数据；创建分别指向客户端的监控端口和日志端口的多个采集线程，控制各采集线程按照所述采集目录指示的所述目标数据在所述客户端中进行数据采集；所述监控端口用于监听所述客户端中监控类型的数据；所述日志端口用于监听所述客户端中日志类型的数据；根据采集到的所述目标数据，确定所发生故障的故障类型。本申请实施例解决了多个客户端同时采集监控数据和日志数据时，操作步骤繁琐且性能消耗大的问题。

Description

故障类型查询方法、装置、电子设备及存储介质

技术领域

本申请涉及信息技术领域，具体而言，本申请涉及一种故障类型查询方法、装置、电子设备及存储介质。

背景技术

当信息系统发生故障时，基于对信息系统的监控，工作人员可以查看信息系统的监控数据，通过监控数据查看信息系统是否出现异常，如果出现异常，那么工作人员可以进一步查看信息系统的日志数据，以此确定出现异常的具体原因。

目前，市面上用于监控信息系统的工具有很多，这些工具大多数采用CS(client/service，客户端/服务端)模式，也就是说，在服务端(监控信息系统)有一个服务器组件接收监控数据，在客户端有一个代理客户端组件负责采集监控数据并发送到服务端，同样，在服务端有一个服务器组件接受日志数据，在客户端有一个代理客户端组件负责采集日志数据并发送到服务端。

由于一个客户端只能采集一种类型的数据(监控数据/日志数据)，若要同时采集监控数据和日志数据，则需要部署两个客户端分别采集监控数据和日志数据，但是，同时部署两个客户端不仅在采集数据时操作步骤繁琐，而且两个客户端消耗的性能很大。

由上可知，多个客户端同时采集监控数据和日志数据时，操作步骤繁琐且性能消耗大成为了亟需解决的问题。

发明内容

本申请各实施例提供了一种故障类型查询方法、装置、电子设备及存储介质，可以解决相关技术中存在的同时采集数据时操作步骤繁琐且性能消耗大的问题。所述技术方案如下：

根据本申请实施例的一个方面，若检测到发生故障，则确定与所发生故障有关的采集目录；所述采集目录用于指示所发生故障需要采集的目标数据；所述目标数据的类型包括监控类型、日志类型中的至少一种；创建分别指向客户端的监控端口和日志端口的多个采集线程，控制各采集线程按照所述采集目录指示的所述目标数据在所述客户端中进行数据采集；所述监控端口用于监听所述客户端中监控类型的数据；所述日志端口用于监听所述客户端中日志类型的数据；根据采集到的所述目标数据，确定所发生故障的故障类型。

根据本申请实施例的一个方面，故障检测模块，用于若检测到发生故障，则确定与所发生故障有关的采集目录；所述采集目录用于指示所发生故障需要采集的目标数据；所述目标数据的类型包括监控类型、日志类型中的至少一种；数据采集模块，用于创建分别指向客户端的监控端口和日志端口的多个采集线程，控制各采集线程按照所述采集目录指示的所述目标数据在所述客户端中进行数据采集；所述监控端口用于监听所述客户端中监控类型的数据；所述日志端口用于监听所述客户端中日志类型的数据；故障确认模块，用于根据采集到的所述目标数据，确定所发生故障的故障类型。

根据本申请实施例的一个方面，一种电子设备，包括：至少一个处理器、至少一个存储器、以及至少一条通信总线，其中，存储器上存储有计算机程序，处理器通过通信总线读取存储器中的计算机程序；计算机程序被处理器执行时实现如上所述的故障类型查询方法。

根据本申请实施例的一个方面，一种存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现如上所述的故障类型查询方法。

根据本申请实施例的一个方面，一种计算机程序产品，计算机程序产品包括计算机程序，计算机程序存储在存储介质中，计算机设备的处理器从存储介质读取计算机程序，处理器执行计算机程序，使得计算机设备执行时实现如上所述的故障类型查询方法。

本申请提供的技术方案带来的有益效果是：

在上述技术方案中，在信息系统发生故障时，通过创建指向一个客户端的多个端口的不同采集线程，便能够同时在客户端中采集监控类型和日志类型的目标数据，例如，监控端口用于监听客户端中监控类型的数据，日志端口则用于监听客户端中日志类型的数据，不仅减少了同时采集数据时的操作步骤，使得采集数据的操作变得简单，而且同时采集数据时仅面向一个客户端能够有效地降低所消耗的性能，从而解决了同时采集数据时操作步骤繁琐且性能消耗大的问题。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1a和图1b是根据本申请所涉及的实施环境的示意图；

图2是根据一示例性实施例示出的一种故障类型查询方法的流程图；

图3是图2对应实施例中步骤330在一个实施例的流程图；

图4是图3对应实施例中步骤335在一个实施例的流程图；

图5是图2对应实施例中步骤350在一个实施例的流程图；

图6是一应用场景中一种故障类型查询方法的具体实现示意图；

图7是根据一示例性实施例示出的一种故障类型查询装置的结构框图；

图8是根据一示例性实施例示出的一种服务器的硬件结构图；

图9是根据一示例性实施例示出的一种电子设备的结构框图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

如前所述，由于一个客户端只能采集一种类型的数据，因此，需要在信息系统中同时部署两个客户端，方能够同时采集监控数据和日志数据，但是此种方案不仅在同时采集数据时因为不同客户端的来回切换导致操作步骤繁琐，而且两个客户端的性能消耗很大。

然而，若将采集监控数据和日志数据集合在一个客户端完成，则目前尚难以分辨采集得到的数据到底是监控数据，还是日志数据。

由上可知，相关技术中仍存在多个客户端同时采集不同类型的数据时，操作步骤繁琐且性能消耗大的缺陷。

为此，本申请提供的故障类型查询方法，能够有效地简化采集多类型数据的操作步骤，并降低性能消耗，相应地，该故障类型查询方法适用于故障类型查询装置，该故障类型查询装置可部署于电子设备，该电子设备可以是配置冯诺依曼体系结构的计算机设备，例如，该计算机设备可以是台式电脑、笔记本电脑、服务器等等。

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

图1a为一种故障类型查询方法所涉及的实施环境的示意图。该实施环境包括采集组件集群110、消息队列集群120、解析组件集群130和数据库140。

具体地，采集组件集群110可以包括若干个采集模块，用于采集目标数据，目标数据的类型包括监控类型、日志类型中的至少一种。

消息队列集群120可以包括若干个消息队列，在采集到的目标数据的数据量较大时，用于暂存采集模块110采集得到的目标数据，以此缓解数据库140的压力，有利于提升信息系统的处理效率。进一步地，消息队列集群120还可以包括用于暂存日志类型的目标数据的日志消息队列、以及用于暂存监控类型的目标数据的监控消息队列。

解析组件集群130可以包括若干个解析组件，用于解析消息队列中的各目标数据。为了提升目标数据的传输效率，各消息队列中的目标数据在传输前会先进行封装和/或压缩，因此，在接收到封装和/或压缩后的目标数据后，便需要对该些目标数据进行解析。

数据库140可以包括多个数据库，用于存储解析得到的各目标数据，进而便能够根据数据库中存储的各目标数据，来确定信息系统所发生故障的故障类型。

具体地，当检测到发生故障，通过采集组件集群110采集监控类型和/或日志类型的目标数据，将采集得到的各目标数据存储于消息队列集群120的各消息队列中，然后，解析组件集群130中的各解析组件对消息队列集群120中存储的各目标数据进行解析，并将解析得到的数据传输至数据库140进行存储，基于此，便能够根据数据库140中存储的各目标数据，来确定信息系统所发生故障的故障类型。

其中，采集组件集群110、消息队列集群120、解析组件集群130和数据库140可以分别设置在不同的电子设备中，也可以集成设置在同一台电子设备中，该电子设备可以是台式电脑、笔记本电脑、服务器等，在此不作限定。

现结合图1b对上述各集群的部署进行举例说明，例如，采集组件集群110、消息队列集群120、解析组件集群130和数据库140可以集成设置在服务端200中；又例如，采集组件集群110、消息队列集群120、解析组件集群130集成设置在采集端100中，而数据库140设置在服务端200中；或者，采集组件集群110设置在采集端100，而消息队列集群120、解析组件集群130和数据库140则集成设置在服务端200，当然，以上举例并未涵盖所有可能的情况，在此不作限定。

其中，采集端110，可以是具有采集图片、文本、多媒体中至少一种或多种数据功能的电子设备，在此不构成具体限定。服务端200可以是台式电脑、笔记本电脑、服务器等等电子设备，还可以是由多台服务器构成的计算机设备集群，甚至是由多台服务器构成的云计算中心。服务端200与采集端100之间通过有线或者无线等方式预先建立通信连接，并通过该通信连接实现服务端200与采集端100之间的数据传输。例如，传输的数据包括但不限于：目标数据等。

随着采集端100与服务端200的交互，便能够基于采集到的目标数据来确定信息系统所发生故障的故障类型。

请参阅图2，本申请实施例提供了一种故障类型查询方法，该方法适用于电子设备，该电子设备可以是图1b所示出实施环境中的服务端200，还可以是台式电脑、笔记本电脑、服务器等。

在下述方法实施例中，为了便于描述，以该方法各步骤的执行主体为电子设备为例进行说明，但是并非对此构成具体限定。

如图2所示，该方法可以包括以下步骤：

步骤310，若检测到发生故障，则确定与所发生故障有关的采集目录。

其中，采集目录用于指示所发生故障需要采集的目标数据，目标数据的类型包括监控类型、日志类型中的至少一种。

可以理解，由于电子设备承载了信息系统，若信息系统发生故障，电子设备的数据也可能出现异常，例如，电子设备的处理器的负载值、上下文切换值等监控类型的目标数据有可能出现异常，包括信息系统以及系统中各应用等各个方面的日志类型的目标数据也有可能出现异常。因此，当检测到信息系统发生故障时，既可以通过各监控类型的目标数据判断所发生故障的故障类型，还可以根据各日志类型的目标数据判断所发生故障的故障类型，以此产生相应的解决方案，进而修复信息系统所发生的故障。

换而言之，在检测到发生故障后，便可基于所发生故障的表现来确定采集目录，以此来确定所发生故障需要采集的目标数据可以有哪些。

举例来说，若信息系统所发生故障的故障表现为系统无响应，那么，对处理器、内存的监控所形成的监控数据可能会出现异常，那么，便可确定采集目录中至少包括与对处理器内存的监控所形成的监控类型的目标数据，进一步地，若电子设备的系统日志、应用程序日志、安全日志等日志数据也可能反映上述异常，则采集目录还至少包括上述日志类型的目标数据。

此外，基于采集目录，可以使得后续采集数据时，根据采集目录所指示的目标数据的顺序进行采集，以便于管理各目标数据，减少目标数据采集错误的发生。

在一种可能的实现方式，在确定所发生故障需要采集的目标数据后，便可通过各目标数据所对应的标识生成采集目录。例如，若目标数据为日志类型，则可以根据各目标数据对应的日志标识生成采集目录，该日志标识用于唯一地表示日志类型的目标数据。

步骤330，创建分别指向客户端的监控端口和日志端口的多个采集线程，控制各采集线程按照采集目录指示的目标数据在客户端中进行数据采集。

其中，监控端口用于监听客户端中监控类型的数据；日志端口用于监听客户端中日志类型的数据。

首先说明的是，由于不同类型的目标数据对应同一个端口，尚难以分辨由该端口采集得到的目标数据的类型是什么，为此，本实施例的客户端提供了监控端口和日志端口，对于服务端而言，则创建了分别指向监控端口和日志端口的多个采集线程。

采集线程可以利用各监控端口和日志端口，采集得到客户端的各目标数据。具体地，通过采集目录所指示的目标数据，控制不同采集线程对日志端口和/或监控端口所监听到的目标数据进行数据采集，便能够得到采集目录所指示的目标数据。

也就是说，指向监控端口的采集线程负责采集该监控端口所监听到的监控类型的数据，指向日志端口的采集线程则负责采集该日志端口所监听到的日志类型的数据，那么，在客户端中监控端口和日志端口保持监听，服务端中多个采集线程保持指向监控端口和日志端口，也可以认为是保持对监控端口和日志端口的监控，由此便能够同时采集到监控类型和日志类型的目标数据。

步骤350，根据采集到的目标数据，确定所发生故障的故障类型。

如前所述，监控类型的目标数据可以反映电子设备的异常，而日志类型的目标数据有助于工作人员了解异常产生的原因，结合这两种类型的目标数据，工作人员可以确定所发生故障的故障类型，例如硬件故障、软件故障等，进一步地，制定解决方案，以此解决所发生故障。

举例来说，当信息系统死机，工作人员根据采集得到的目标数据发现，电子设备关于内存的监控数据出现了异常，而系统日志数据中也记载了相应的事件，由此确定所发生故障的故障类型为硬件故障，即电子设备的内存条出现了故障，工作人员便可以基于该故障类型更换电子设备的内存条，进而解决所发生故障。

通过上述过程，在信息系统发生故障时，通过创建指向一个客户端的多个端口的不同采集线程，便能够同时在客户端中采集监控类型和日志类型的目标数据，例如，监控端口用于监听客户端中监控类型的数据，日志端口则用于监听客户端中日志类型的数据，不仅减少了同时采集数据时的操作步骤，使得采集数据的操作变得简单，而且同时采集数据时仅面向一个客户端能够有效地降低所消耗的性能，从而解决了同时采集数据时操作步骤繁琐且性能消耗大的问题。

请参阅图3，在一示例性实施例中，步骤330还可以包括以下步骤：

步骤331，基于采集目录指示的目标数据，确定与目标数据对应的端口标识。

其中，端口标识是用于唯一地识别端口的标识，可以理解，不同端口的端口标识也不同。步骤333，根据所确定的端口标识为目标数据创建缓存目录。

首先说明的是，缓存目录用于指示目标数据的采集状态。在一种可能的实现方式，缓存目录是根据目标数据对应的端口标识创建的，此种方式下，缓存目录不仅能够表明目标数据是否采集完毕，还可以区分不同客户端中同一端口所采集到的不同目标数据。

其次，目标数据的采集状态可以包括待采集状态、采集中状态、采集完毕状态。具体地，当目标数据的采集状态为待采集状态时，表示尚没有采集线程采集该目标数据；当采集状态为采集中状态时，表示有采集线程正在采集该目标数据；当采集状态为采集完毕状态时，表示已经采集到了该目标数据。

举例来说，每个客户端的网络IP地址、监控项和日志文件名都不尽相同，在一个可能的实现方式，缓存目录可以根据客户端的IP地址、端口创建生成，例如，目标数据的类型为监控类型、客户端的IP地址为192.168.1.2、端口标识为1234、备注信息为CPU，则所创建的缓存目录的目录名可以表示为monitor-192.168.1.2-1234-cpu；目标数据的类型为日志类型、客户端的IP地址为192.168.1.2、端口标识为4321、备注信息为message.log，则所创建的缓存目录的目录名可以表示为log-192.168.1.2-4321-message.log。由此，基于缓存目录可以区别不同的目标数据，并且快速地获得目标数据的各项信息，有利于后续工作人员的维护。

步骤335，根据缓存目录指示的目标数据的采集状态，控制各采集线程进行目标数据的采集。

首先说明的是，为了快速完成数据采集，一个采集线程负责采集一个目标数据。在一个可能的实现方式，采集线程包括空闲采集线程和忙碌采集线程，空闲采集线程表示未进行目标数据的采集，忙碌采集线程表示正在进行目标数据的采集，可以理解，空闲采集线程和忙碌采集线程可以相互转化，例如，当空闲采集线程开始采集目标数据，该空闲采集线程便转化为忙碌采集线程，当忙碌采集线程将目标数据采集完毕，该忙碌采集线程便转化为空闲采集线程。

如前所述，根据缓存目录所指示的各目标数据的采集状态，采集线程可以对处于待采集状态的各目标数据进行数据采集。换而言之，正常情况下，由一个采集线程完成目标数据的完整采集过程。

在一个可能的实现方式，若缓存目录指示目标数据的采集状态为待采集状态，则确定空闲采集线程；控制空闲采集线程采集目标数据；直至目标数据采集完毕，在缓存目录中将目标数据的采集状态由待采集状态更新为采集完毕状态，并将忙碌采集线程设置为空闲采集线程。

当然，在目标数据的采集过程中，采集线程可能会因各种异常而发生异常，进而导致目标数据的采集发生中断。其中，异常包括但不限于：客户端中有其他高优先级的应用重启、安装了别的高优先级应用、人为误操作导致正在进行目标数据采集的采集线程被异常关闭、创建采集线程的应用程序出现异常。基于此，异常情况下，由两个不同的采集线程完成目标数据的完整采集过程。具体地，该两个不同的采集线程是指两个空闲采集线程。

在一个可能的实现方式，如图4所示，步骤335可以包括以下步骤：

步骤3351，若缓存目录指示目标数据的采集状态为采集中状态，则检测忙碌采集线程在采集目标数据的过程中是否发生异常。

若检测到忙碌采集线程发生异常，则执行步骤3352。

反之，若未检测到忙碌采集线程发生异常，则继续执行步骤3351，同时该忙碌采集线程继续对目标数据进行采集。

步骤3352，控制忙碌采集线程停止采集目标数据，在缓存目录中生成异常位置信息，并在缓存目录中将目标数据的采集状态由采集中状态更新为待采集状态。

其中，异常位置信息用于标记目标数据的采集中断位置。

首先说明的是，在采集目标数据的过程发生中断时，采集线程可能已经完成了部分目标数据的采集，停止采集目标数据后，可以通过重新采集该目标数据的方式得到目标数据，但是这种方式进行了重复采集，浪费资源，并且增加了采集时间，为了提升采集效率，本实施例采取继续采集的方式，即继续采集目标数据尚未采集的部分，并与之前已经采集的部分组合，得到目标数据，以此方式避免重复采集，进而能够大大提升目标数据的采集效率，节省采集时间，节约资源。

在一种可能的实现方式，继续采集的方式是通过在缓存目录中标记目标数据的采集中断位置实现的。

具体地，目标数据的采集中断位置根据目标数据的不同类型进行标记。若目标数据的类型为监控类型，则目标数据的采集中断位置在缓存目录中被标记为目标数据中断采集的时间戳；若目标数据的类型为日志类型，则目标数据的采集中断位置在缓存目录中被标记为目标数据中断采集的行数。

步骤3353，控制空闲采集线程从目标数据的采集中断位置继续进行目标数据的采集，直至得到目标数据。

如前所述，数据采集过程中出现的异常状态，可能是由于采集线程出现异常造成的，因此，为了避免单线程出现单一故障，本方案提供了两个空闲采集线程，当其中一个空闲采集线程采集目标数据的过程中发生异常时，便利用另一个空闲采集线程继续采集目标数据，无需等待其他采集线程空闲，此种方式来提高采集数据的效率，提升电子设备的采集性能。

具体地，根据上述目标数据的待采集状态，空闲采集线程可以查找到该目标数据，以对该目标数据进行采集，并且，根据异常位置信息，空闲采集线程可以定位至上个采集线程采集数据时的采集中断位置，在该采集中断位置上继续进行数据采集，以得到目标数据。例如，采集线程已经采集了目标数据的15行数据，在采集第16行数据时出现异常，则可以确定采集中断位置为目标数据的第16行数据。那么，空闲采集线程便从第16行数据开始继续进行数据采集，直至得到目标数据。

需要说明的是，目标数据类型的不同会影响空闲采集线程继续进行数据采集的方式，当目标数据为监控类型时，采集中断位置为目标数据中断采集的时间戳，进而使得另一个空闲采集线程基于该时间戳继续采集尚未采集的目标数据；当目标数据为日志类型时，另一个空闲采集线程将会基于采集中断位置继续采集尚未采集的目标数据，此处并非构成具体限定。

在上述实施例的作用下，利用多采集线程对采集目录中各目标数据进行数据采集，提升了采集数据的效率，加快了得到目标数据的速度；并且，在原采集线程进行数据采集出现中断时，提供了空闲采集线程继续采集目标数据，无需等待时间，提高了采集性能，进一步加快了目标数据的采集速度。

请参阅图5，在一示例性实施例中，步骤350还可以包括以下步骤：

步骤351，将采集得到的目标数据存储于相应的消息队列中。

首先说明的是，当采集线程完成目标数据的采集时，可以直接解析该目标数据，并存储于数据库中，但是，若多采集线程同时采集得到多个目标数据，或者高峰期，会使得采集到的目标数据的数据量较大时，会使得数据库的压力急速上升，进而影响信息系统的处理效率。

为了避免上述情况出现，本方案通过消息队列的方式，使得采集得到的目标数据在消息队列中排队缓存，达到削峰的目的，减少数据库的压力。

具体地，可以按照目标数据的采集时间，以先来后到的形式在消息队列中排队缓存，进而按照这个顺序解析并存储于数据库中。例如，可以先将采集得到的目标数据缓存在预先设置的存储空间，若目标数据采集完毕后，则可以将该目标数据的存储地址的地址信息存储在预先设置的消息队列中，从而根据各个目标数据对应的采集时刻，将各个目标数据缓存在消息队列中。

当然，在其他实施例中，还可以根据目标数据的类型将各目标数据缓存在不同的消息队列中。在一个可能的实现方式，若目标数据的类型为监控类型，则将目标数据存储于监控消息队列中；若目标数据的类型为日志类型，则将目标数据存储于日志消息队列中。具体地，可以根据用于表示日志类型的日志标识，对各个日志类型的目标数据进行分类，也可以根据监控项中表示主机地址的端口标识，对各个监控类型的目标数据进行分类。从而在同一专用消息队列或不同专用消息队列中存储相同类型的数据文件。其中，主机标识可以用于指示监控项所属的应用程序，也可以用于指示监控项所属的电子设备，还可以用于指示其他类型的分类规则。

关于消息队列中的目标数据，可以将同一个类型的目标数据都存储于任意一个专用消息队列中，也可以在各个专用消息队列中存储不同的目标数据量，例如，若采集得到10个监控类型的目标数据，有5个监控消息专用队列，则可以采用轮循的方式在每个监控消息队列中存储2个监控类型的目标数据，也可以将10个监控类型的目标数据都存在一个监控消息队列中，在此不作限定。

步骤353，分别解析各消息队列中的目标数据，并将解析后的目标数据存储至数据库。

首先说明的是，为了数据传输的快捷，消息队列中的各目标数据会按照一定结构进行封装和压缩数据，例如，目标数据会序列化为Json或者yaml格式数据，然后再通过gzip或者lz4来进行数据压缩，特别是日志类型的目标数据，基本都为文本形式，因此压缩率特别高，进而使得压缩后的目标数据有利于提高数据传输的效率。

因此，在将目标数据存储于数据库之前，需要对各目标数据进行解析，以此还原各目标数据。

在一个可能的实现方式，可以从任意一个消息队列中随机获取存储的当前一个目标数据，并对该目标数据进行解析，以得到解析后的目标数据，然后在从任意一个消息队列中随机获取存储的后一个目标数据，继续进行解析，直到对各消息队列中的各目标数据全部完成解析。

在一个可能的实现方式，在解析完当前目标数据后，可以根据当前目标数据的存储地址，获取与该存储地址相邻地址存储的目标数据，对该目标数据进行解析，以此类推，直到完成所有目标数据的解析。

在一个可能的实现方式，根据当前目标数据所在的消息队列，再次由该消息队列中获取目标数据，直至完成该消息队列中所有目标数据的解析。

在采集得到的各目标数据完成解析后，需要将解析后的各目标数据存储至数据库，举例来说，可以采用TCP(Transmission Control Protocol传输控制协议)、SNMP(Simple Network Management Protocol，简单网络管理协议)或HTTP(HyperTextTransport Protocol，超文本传送协议)等方式对解析后的目标数据进行传输，从而传输至ceph(一种分布式系统基础架构)或mongdb(一种搜索服务器)等数据库，最后通过ceph或mongdb等数据库中的各个存储空间对解析后的目标数据进行存储。

在一个可能的实现方式，可以随机将各目标数据存储于数据库中的空闲存储空间中。在一个可能的实现方式，还可以根据各目标数据的端口标识，确定数据库为各目标数据分配的与端口标识对应的存储空间；将各目标数据存储于数据库中对应的存储空间。

举例来说，若解析得到10个解析后的目标数据，解析后的目标数据A、C、D、I和J对应的端口标识为30001，解析后的目标数据B、G和H对应的端口标识为30002，则可以将解析后的目标数据A、C、D、I和J存储在数据库中的30001存储空间内，并将解析后的目标数据B、G和H存储在数据库中的30002存储空间内。

步骤355，基于数据库中存储的目标数据，确定所发生故障的故障类型。

在上述实施例的作用下，一方面，利用不同类型的消息队列，可以方便地管理采集得到的各目标数据；另一方面，利用消息队列，使得采集得到的目标数据在消息队列中排队缓存，达到削峰的目的，减少数据库的压力，进而有利于提升信息系统的处理性能。

图6是一应用场景中一种故障类型查询方法的具体实现示意图。结合图1a对该应用场景进行说明。

利用采集组件集群110，通过步骤701，采集多个日志文件和监控项。

利用消息队列集群120，通过步骤703，多个采集模块(线程)将多个日志文件或监控值存储至多个消息队列。

利用解析组件集群130，通过步骤705，多个解析组件对多个消息队列中的日志文件或监控项进行解析，得到多个解析后的日志文件及监控项。

利用数据库140，通过步骤707，多个解析组件将多个解析后的日志文件或监控项存储至数据库。

在本应用场景中，利用采集组件集群的各采集组件，可以同时采集多种类型的目标数据，解决了智能单一采集某一类型目标数据的问题，并且，采集组件集群的模块化设计，扩展性好，单个模块出问题，不影响其他模块的数据采集，提高了数据采集的鲁棒性。

下述为本申请装置实施例，可以用于执行本申请所涉及的故障类型查询方法。对于本申请装置实施例中未披露的细节，请参照本申请所涉及的故障类型查询方法的方法实施例。

请参阅图7，本申请实施例中提供了一种故障类型查询装置900，包括但不限于：故障检测模块910、数据采集模块930、以及故障确认模块950。

其中，故障检测模块910，用于若检测到发生故障，则确定与所发生故障有关的采集目录；采集目录用于指示所发生故障需要采集的目标数据；目标数据的类型包括监控类型、日志类型中的至少一种。

数据采集模块930，用于创建分别指向客户端的监控端口和日志端口的多个采集线程，控制各采集线程按照采集目录指示的目标数据在客户端中进行数据采集；监控端口用于监听客户端中监控类型的数据；日志端口用于监听客户端中日志类型的数据。

故障确认模块950，用于根据采集到的目标数据，确定所发生故障的故障类型。

需要说明的是，上述实施例所提供的故障类型查询装置在进行信息推荐时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即故障类型查询装置的内部结构将划分为不同的功能模块，以完成以上描述的全部或者部分功能。

另外，上述实施例所提供的故障类型查询装置与故障类型查询方法的实施例属于同一构思，其中各个模块执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。

图8根据一示例性实施例示出的一种服务器的结构示意。该服务器适用于图1所示出实施环境中的电子设备。

需要说明的是，该服务器只是一个适配于本申请的示例，不能认为是提供了对本申请的使用范围的任何限制。该服务器也不能解释为需要依赖于或者必须具有图8示出的示例性的服务器2000中的一个或者多个组件。

服务器2000的硬件结构可因配置或者性能的不同而产生较大的差异，如图8所示，服务器2000包括：电源210、接口230、至少一存储器250、以及至少一中央处理器(CPU,Central Processing Units)270。

具体地，电源210用于为服务器2000上的各硬件设备提供工作电压。

接口230包括至少一有线或无线网络接口231，用于与外部设备交互。例如，进行图1所示出实施环境中采集端100与服务端200之间的交互。

当然，在其余本申请适配的示例中，接口230还可以进一步包括至少一串并转换接口233、至少一输入输出接口235以及至少一USB接口237等，如图8所示，在此并非对此构成具体限定。

存储器250作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源包括操作系统251、应用程序253及数据255等，存储方式可以是短暂存储或者永久存储。

其中，操作系统251用于管理与控制服务器2000上的各硬件设备以及应用程序253，以实现中央处理器270对存储器250中海量数据255的运算与处理，其可以是WindowsServerTM、Mac OS XTM、UnixTM、LinuxTM、FreeBSDTM等。

应用程序253是基于操作系统251之上完成至少一项特定工作的计算机程序，其可以包括至少一模块(图8未示出)，每个模块都可以分别包含有对服务器2000的计算机程序。例如，故障类型查询装置可视为部署于服务器2000的应用程序253。

数据255可以是存储于磁盘中的照片、图片等，还可以是日志类型的目标数据、监控类型的目标数据等，存储于存储器250中。

中央处理器270可以包括一个或多个以上的处理器，并设置为通过至少一通信总线与存储器250通信，以读取存储器250中存储的计算机程序，进而实现对存储器250中海量数据255的运算与处理。例如，通过中央处理器270读取存储器250中存储的一系列计算机程序的形式来完成故障类型查询方法。

此外，通过硬件电路或者硬件电路结合软件也能同样实现本申请，因此，实现本申请并不限于任何特定硬件电路、软件以及两者的组合。

请参阅图9，本申请实施例中提供了一种电子设备4000，该电子设备400可以包括：台式电脑、笔记本电脑、服务器等。

在图9中，该电子设备4000包括至少一个处理器4001、至少一条通信总线4002以及至少一个存储器4003。

其中，处理器4001和存储器4003相连，如通过通信总线4002相连。可选地，电子设备4000还可以包括收发器4004，收发器4004可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器4004不限于一个，该电子设备4000的结构并不构成对本申请实施例的限定。

处理器4001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器4001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

通信总线4002可包括一通路，在上述组件之间传送信息。通信总线4002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。通信总线4002可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器4003可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscReadOnly Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器4003上存储有计算机程序，处理器4001通过通信总线4002读取存储器4003中存储的计算机程序。

该计算机程序被处理器4001执行时实现上述各实施例中的故障类型查询方法。

此外，本申请实施例中提供了一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述各实施例中的故障类型查询方法。

本申请实施例中提供了一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序存储在存储介质中。计算机设备的处理器从存储介质读取该计算机程序，处理器执行该计算机程序，使得该计算机设备执行上述各实施例中的故障类型查询方法。

与相关技术相比，在系统发生故障时，通过一个客户端的多个端口负责不同类型数据的监听，创建能够分别指向该多个端口的多个采集线程，以此实现同时采集监控数据和日志数据，不仅减少了同时采集数据的操作步骤的繁琐，使得采集数据的操作步骤变得简单，进而有利于提升同时采集数据的效率，而且同时采集数据时仅面向一个客户端能够有效地降低所消耗的性能。进一步地，利用消息队列机制，达到削峰目的，减少了存储大量目标数据时数据库的压力，并且，在原单采集线程进行数据采集出现中断时，在缓存目录中标记采集中断位置，并提供了两个空闲采集线程继续采集目标数据，无需等待时间，提高了采集性能，加快了目标数据的采集速度。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种故障类型查询方法，其特征在于，所述方法包括：

若检测到发生故障，则确定与所发生故障有关的采集目录；所述采集目录用于指示所发生故障需要采集的目标数据；所述目标数据的类型包括监控类型、日志类型中的至少一种；

创建分别指向客户端的监控端口和日志端口的多个采集线程，控制各采集线程按照所述采集目录指示的所述目标数据在所述客户端中进行数据采集；所述监控端口用于监听所述客户端中监控类型的数据；所述日志端口用于监听所述客户端中日志类型的数据；

根据采集到的所述目标数据，确定所发生故障的故障类型。

2.如权利要求1所述的方法，其特征在于，所述创建分别指向客户端的监控端口和日志端口的多个采集线程，控制各采集线程按照所述采集目录指示的所述目标数据在所述客户端中进行数据采集，所述方法还包括：

基于所述采集目录指示的所述目标数据，确定与所述目标数据对应的端口标识；

根据所确定的端口标识为所述目标数据创建缓存目录；所述缓存目录用于指示所述目标数据的采集状态；

根据所述缓存目录指示的所述目标数据的采集状态，控制各采集线程进行所述目标数据的采集。

3.如权利要求2所述的方法，其特征在于，所述根据所述缓存目录指示的所述目标数据的采集状态，控制各采集线程进行所述目标数据的采集，包括：

若所述缓存目录指示所述目标数据的采集状态为待采集状态，则确定空闲采集线程；

控制空闲采集线程采集所述目标数据，并将空闲采集线程设置为忙碌采集线程；

直至所述目标数据采集完毕，在所述缓存目录中将所述目标数据的采集状态由待采集状态更新为采集完毕状态，并将忙碌采集线程设置为空闲采集线程。

4.如权利要求2所述的方法，其特征在于，所述根据所述缓存目录指示的所述目标数据的采集状态，控制各采集线程进行所述目标数据的采集，包括：

若所述缓存目录指示所述目标数据的采集状态为采集中状态，则检测忙碌采集线程在采集所述目标数据的过程中是否发生异常；

若为是，则控制忙碌采集线程停止采集所述目标数据，在所述缓存目录中标记所述目标数据的采集中断位置，并在所述缓存目录中将所述目标数据的采集状态由采集中状态更新为待采集状态；

控制空闲采集线程从所述目标数据的采集中断位置继续进行所述目标数据的采集，直至得到所述目标数据。

5.如权利要求1所述的方法，其特征在于，所述根据采集到的所述目标数据，确定所发生故障的故障类型，包括：

将采集得到的所述目标数据存储于相应的消息队列中；

分别解析各消息队列中的所述目标数据，并将解析后的所述目标数据存储至数据库；

基于所述数据库中存储的所述目标数据，确定所发生故障的故障类型。

6.如权利要求5所述的方法，其特征在于，所述将采集得到的所述目标数据存储于相应的消息队列中，包括：

若所述目标数据的类型为监控类型，则将所述目标数据存储于监控消息队列中；和/或

若所述目标数据的类型为日志类型，则将所述目标数据存储于日志消息队列中。

7.如权利要求5所述的方法，其特征在于，所述分别解析各消息队列中的所述目标数据，并将解析后的所述目标数据存储至数据库，包括：

根据各所述目标数据的端口标识，确定所述数据库为各所述目标数据分配的与端口标识对应的存储空间；

将各所述目标数据存储于所述数据库中对应的存储空间。

8.一种故障类型查询装置，其特征在于，所述装置包括：

故障检测模块，用于若检测到发生故障，则确定与所发生故障有关的采集目录；所述采集目录用于指示所发生故障需要采集的目标数据；所述目标数据的类型包括监控类型、日志类型中的至少一种；

数据采集模块，用于创建分别指向客户端的监控端口和日志端口的多个采集线程，控制各采集线程按照所述采集目录指示的所述目标数据在所述客户端中进行数据采集；所述监控端口用于监听所述客户端中监控类型的数据；所述日志端口用于监听所述客户端中日志类型的数据；

故障确认模块，用于根据采集到的所述目标数据，确定所发生故障的故障类型。

9.一种电子设备，其特征在于，包括：至少一个处理器、至少一个存储器、以及至少一条通信总线，其中，

所述存储器上存储有计算机程序，所述处理器通过所述通信总线读取所述存储器中的所述计算机程序；

所述计算机程序被所述处理器执行时实现权利要求1至7中任一项所述的故障类型查询方法。

10.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的故障类型查询方法。

Images