故障日志处理方法、装置、电子设备和存储介质

技术领域

本申请涉及网络技术领域，具体为网络故障处理技术，具体涉及一种故障日志处理方法、装置、电子设备和存储介质。

背景技术

为了维护系统稳定性，需要对故障日志进行采集和分析来排查系统故障。随着业务复杂度的上升，系统内模块的复杂程度会逐渐提高，模块数量也会增多，不同的模块会输出不同的日志。传统的故障日志采集中，通常对各个模块的日志进行分开收集，这使得故障定位较困难。

发明内容

本申请提供了一种故障日志处理方法、装置、电子设备和存储介质。

根据第一方面，本申请提供了一种故障日志处理方法，包括：

向故障机器的客户端发送故障日志采集请求；

接收所述客户端响应于所述故障日志采集请求发送的所述故障机器的N组故障日志，所述N组故障日志包括所述故障机器的各模块调用N个请求产生的全部日志，所述N为大于或等于1的整数；

根据所述N组故障日志，确定所述故障机器的故障来源模块信息和对应的故障类型信息。

根据第二方面，本申请提供了一种故障日志处理装置，包括：

发送模块，用于向故障机器的客户端发送故障日志采集请求；

接收模块，用于接收所述客户端响应于所述故障日志采集请求发送的所述故障机器的N组故障日志，所述N组故障日志包括所述故障机器的各模块调用N个请求产生的全部日志，所述N为大于或等于1的整数；

确定模块，用于根据所述N组故障日志，确定所述故障机器的故障来源模块信息和对应的故障类型信息。

根据第三方面，本申请提供了一种电子设备，包括：

至少一个处理器；以及

与至少一个处理器通信连接的存储器；其中，

存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行第一方面中的任一项方法。

根据第四方面，本申请提供了一种存储有计算机指令的非瞬时计算机可读存储介质，计算机指令用于使计算机执行第一方面中的任一项方法。

根据本申请的技术，由于所采集的N组故障日志为故障机器的各模块调用N个请求产生的全部日志，这样，能够根据N组故障日志，高效地确定故障机器的故障来源模块，从而高效地实现故障定位。

应当理解，本部分所描述的内容并非旨在标识本申请的实施例的关键或重要特征，也不用于限制本申请的范围。本申请的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1是根据本申请第一实施例的故障日志处理系统的结构示意图；

图2是根据本申请第一实施例的故障日志处理方法的流程示意图；

图3是根据本申请第二实施例的故障日志处理装置的结构示意图；

图4是用来实现本申请实施例的故障日志处理方法的电子设备的框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

故障日志是由故障机器在调用请求时所产生的，具体的，机器(machine)中设置有多个模块，当机器中的某个模块发生了故障时，该机器可称为故障机器。当一条请求进入机器之后，会顺序经历多个模块，每个模块会输出自己的日志，当机器发生故障时，机器的各模块调用任何请求所产生的日志即可理解为故障日志。

现有技术中，故障日志追查普遍由服务器(server)-客户端(client)模式构建，普遍采用以下方案：为每一台机器部署一个日志收集工具，客户端根据配置不断地读取日志收集工具收集的每一行日志，进行全量上报或筛选上报给服务器，随着流量的提高，日志收集客户端需要处理的数据量也不断增大，这使得日志收集客户端占用的系统资源过高，即使采用筛选机制，后端存储的日志数量也比较庞大。并且，随着业务复杂度的上升，机器内模块的复杂程度会逐渐变高，模块数量也会增多，不同的模块会输出不同的日志，而日志收集客户端通常是对各个模块的日志信息进行分开收集，容易造成日志混乱，这使得故障定位较困难。

为了解决现有技术中的上述技术问题，本申请提供故障日志处理方法、故障日志处理装置、电子设备和存储介质。

本申请中，故障日志处理模式仍然可采用服务器-客户端模式，并可通过如图1所示的故障日志处理系统实现。图1中，每台机器11均对应有各自的客户端12，各机器11的客户端12均与服务器13连接，服务器13还与报警组件14连接，报警组件14还与各机器11连接。其中，客户端12可用来采集机器11产生的日志，报警组件14可用来监控机器11的运行状态，当机器11发生故障时，报警组件14可发出故障报警信号，服务器13可通过报警组件14获取机器11的故障信息，服务器13与客户端12之间可交互通信，例如，服务器13可向客户端12发送故障日志采集请求，并接收客户端12发送的故障日志。

本申请中，故障日志的采集可以理解为从故障机器11获取故障日志，故障日志的采集端可以为故障机器11的客户端12。故障的定位可以包括故障来源模块的确定以及故障类型的确定，本申请中，故障的定位可以由服务器13实现。

以下对本申请的示范性实施例进行说明。

如图2所示，故障日志处理方法，包括如下步骤：

步骤201：向故障机器的客户端发送故障日志采集请求；

步骤202：接收所述客户端响应于所述故障日志采集请求发送的所述故障机器的N组故障日志，所述N组故障日志包括所述故障机器的各模块调用N个请求产生的全部日志，所述N为大于或等于1的整数；

步骤203：根据所述N组故障日志，确定所述故障机器的故障来源模块信息和对应的故障类型信息。

本申请实施例的故障日志处理方法可由故障日志处理装置执行，该故障日志处理装置可以为图1中的服务器13。

本申请实施例中，故障日志的采集不再是客户端主动采集并上报给服务器，而是客户端等待服务器的通知来采集故障日志。具体的，在步骤201中，服务器在获取到有故障信号时，可向故障机器的客户端发送故障日志采集请求。

若客户端接收到服务器发送的故障日志采集请求，则客户端可以响应于该故障日志采集请求，对机器进行日志采集。若服务器未向客户端发送故障日志采集请求，则客户端不会主动去采集机器的日志。这样，能够有效地解决传统日志采集方式而导致的资源浪费问题，能够节约客户端所在机器的资源损耗与网络带宽的浪费，使整个日志处理系统在占用资源小的前提下实现故障日志的处理。

服务器获取故障信号的方式可以有多种，例如，服务器定时从报警组件扫描或抓取故障信号，以确认是否有故障发生；又例如，报警组件在监控到故障发生时，主动向服务器上报故障信号。服务器能够通过故障信号来确定发生故障的机器(即故障机器)。

本申请实施例中，服务器一旦发现有故障出现，可以根据配置对故障机器的客户端发起故障日志采集请求，服务器可以在故障日志采集请求中携带有故障日志的采集要求。

在步骤202中，服务器可以接收到客户端响应于故障日志采集请求发送的故障机器的N组故障日志，其中，N组故障日志包括故障机器的各模块调用N个请求产生的全部日志。这里，每组故障日志又可理解为每个请求被故障机器调用所产生的完整日志。每一组故障日志可以视为一条完整日志，每条完整日志可以包括同一请求被多个模块调用所产生的多条日志。

上述N组故障日志可以为故障机器的部分故障日志，也可以为故障机器的全部故障日志，客户端可以随机采集N组故障日志，并发送给服务器。

由于N组故障日志为N个请求被故障机器调用所产生的完整日志，因此，在步骤203中，服务器可以根据N组故障日志，对故障进行溯源和定位，即，确定故障机器的故障来源模块信息，此外，服务器还可以根据故障日志确定对应的故障类型信息。

本申请实施例中，在对故障日志进行采集时，由于所采集的N组故障日志为故障机器的各模块调用N个请求产生的全部日志，这样，能够根据N组故障日志，高效地确定故障机器的故障来源模块，从而高效地实现故障定位。在机器发生故障时，可以通过本申请实施例实现故障日志的采集以及故障的定位，能够为运维人员高效排查故障机器提供方便。

可选的，所述故障日志采集请求包括故障日志的采集数量信息，所述N的取值与所述故障日志的采集数量信息相匹配。

上述故障日志采集请求中的故障日志的采集数量信息可以理解为完整日志的条数，例如，可以配置每台故障机器最多采集10条完整日志。

该实施方式中，通过在故障日志采集请求限制每台故障机器的日志采集数量，可以有效地限制客户端采集日志的数量，既不会漏过小数量级别的故障日志，而且，在大规模故障触发的时候，也不会采集过多的、重复的故障日志，从而能够进一步避免占用客户端和机器过多的资源，实现了轻量级的故障日志采集。

可选的，所述根据所述N组故障日志，确定所述故障机器的故障来源模块信息，包括：

按照所述N个请求的每一请求在所述故障机器中的调用顺序，将所述N组故障日志的每组故障日志进行排序，并按序查找每组故障日志，确定每组故障日志的故障来源模块信息。

当一条请求经过负载均衡进入代理模块之后，会顺序经历机器的多个模块，每个模块会输出自己的日志。服务器可以将每组故障日志按照模块访问顺序进行排序，并按序查找每一个模块的故障日志，从而确定故障日志的故障来源模块信息。

该实施方式，通过按照请求在故障机器中的调用顺序，对每组故障日志进行排序，能够使服务器快速地对故障来源进行追溯和排查，从而高效地实现故障的定位。并且，由于服务器能够按序查找每组故障日志，从而无需对客户端传输故障日志的顺序进行限制，从而可以降低客户端传输故障日志的复杂度。

可选的，所述N个请求分别预先配置有各自对应的标识信息，所述N个请求的每一请求在被所述故障机器的各模块调用时产生的全部日志均携带所述请求对应的标识信息。

该实施方式中，为了提高日志之间的关联性，可以预先创建一个代理模块，当一条请求进入后端，可以通过该代理模块来控制该请求，为该请求创建对应的标识信息，并且在后续的每个模块调用中都在日志输出该标识信息，从而提升日志之间的关联性。

这样，客户端在采集故障机器的故障日志时，可以根据日志中携带的标识信息来确保采集的故障日志为完整日志。

可选的，所述向故障机器的客户端发送故障日志采集请求，包括：

向预设数量的故障机器的客户端发送故障日志采集请求，所述预设数量小于故障机器总数。

本申请实施例中，除了可以对每台故障机器的日志采集数量进行限制，还可以对采集的机器数量进行限制。例如，当大规模故障发生时，发生故障的机器数量会较多，且大部分故障机器的故障原因有可能相同，因此，没有必要采集过多的、重复的故障日志，也就没有必要对每台故障机器进行故障日志的采集。鉴于此，当故障机器总数较多时，服务器可以向预设数量的故障机器的客户端发送故障日志采集请求。例如，预设数量可以是10，即，当故障机器总数大于10时，服务器可以向任意10台故障机器的客户端发送故障日志采集请求。

该实施方式中，通过对采集的机器数量进行限制，能够进一步避免占用客户端和机器过多的资源，进一步地实现了轻量级的故障日志采集。

可选的，在所述根据所述N组故障日志，确定所述故障机器的故障来源模块信息和对应的故障类型信息之后，所述方法还包括：

生成故障统计数据，所述故障统计数据包括故障来源模块的占比信息和对应的故障类型信息。

服务器在确定了故障机器的故障来源模块信息和对应的故障类型信息之后，可以将故障来源模块信息和对应的故障类型信息直接展示在前端，或采用消息推送的方式直接上报给研发、运维人员。

考虑到故障来源模块信息和对应的故障类型信息较为繁冗，因此，为了使研发、运维人员更直接地、清楚地、便捷地了解主要故障来源和故障类型，服务器可以根据确定的故障来源模块信息和故障类型信息，对每个日志的故障原因进行汇总，并生成故障统计数据。该故障统计数据可以包括故障来源模块的占比信息和对应的故障类型信息。例如，故障统计数据可以是譬如“70％模块A，连接DB失败，30％模块B，网络异常”。

服务器即便生成了故障统计数据，也可以继续存储详细的故障日志以及故障来源模块信息和对应的故障类型信息，以备研发、运维人员随时查看。

此外，随着云技术的发展，模块可以得到不断的优化、解耦和增加，因此，考虑到系统的可扩展性，在本申请实现过程中，可以对服务器设计配置文件，配置中的每个模块都可以配置0至n个依赖模块。每次在服务器启动时，可以对待梳理的模块进行排序，对于互不相关的模块，可以启动多个协程(goroutine)进行处理，从而加快处理效率。

需要说明的是，本申请中的故障日志处理方法中的多种可选的实施方式，彼此可以相互结合实现，也可以单独实现，对此本申请不作限定。

本申请的上述实施例至少具有如下优点或有益效果：

本申请实施例中，在对故障日志进行采集时，由于所采集的N组故障日志为故障机器的各模块调用N个请求产生的全部日志，这样，能够根据N组故障日志，高效地确定故障机器的故障来源模块，从而高效地实现故障定位。在机器发生故障时，可以通过本申请实施例实现故障日志的采集以及故障的定位，能够为运维人员高效排查故障机器提供方便。

如图3所示，本申请提供一种故障日志处理装置300，包括：

发送模块301，用于向故障机器的客户端发送故障日志采集请求；

接收模块302，用于接收所述客户端响应于所述故障日志采集请求发送的所述故障机器的N组故障日志，所述N组故障日志包括所述故障机器的各模块调用N个请求产生的全部日志，所述N为大于或等于1的整数；

确定模块303，用于根据所述N组故障日志，确定所述故障机器的故障来源模块信息和对应的故障类型信息。

可选的，确定模块303具体用于：

按照所述N个请求的每一请求在所述故障机器中的调用顺序，将所述N组故障日志的每组故障日志进行排序，并按序查找每组故障日志，确定每组故障日志的故障来源模块信息和对应的故障类型信息。

可选的，故障日志处理装置300还包括：

生成模块，用于生成故障统计数据，所述故障统计数据包括故障来源模块的占比信息和对应的故障类型信息。

可选的，所述N个请求分别预先配置有各自对应的标识信息，所述N个请求的每一请求在被所述故障机器的各模块调用时产生的全部日志均携带所述请求对应的标识信息。

可选的，所述故障日志采集请求包括故障日志的采集数量信息，所述N的取值与所述故障日志的采集数量信息相匹配。

可选的，发送模块301具体用于：

向预设数量的故障机器的客户端发送故障日志采集请求，所述预设数量小于故障机器总数。

本申请提供的故障日志处理装置300能够实现上述故障日志处理方法实施例中的各个过程，且能够达到相同的有益效果，为避免重复，这里不再赘述。

根据本申请的实施例，本申请还提供了一种电子设备和一种可读存储介质。

如图4所示，是根据本申请实施例的故障日志处理方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图4所示，该电子设备包括：一个或多个处理器401、存储器402，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示GUI的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图4中以一个处理器401为例。

存储器402即为本申请所提供的非瞬时计算机可读存储介质。其中，存储器存储有可由至少一个处理器执行的指令，以使至少一个处理器执行本申请所提供的故障日志处理方法。本申请的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的故障日志处理方法。

存储器402作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的故障日志处理方法对应的程序指令/模块(例如，附图3所示的发送模块301、接收模块302和确定模块303)。处理器401通过运行存储在存储器402中的非瞬时软件程序、指令以及模块，从而执行故障日志处理装置的各种功能应用以及数据处理，即实现上述方法实施例中的故障日志处理方法。

存储器402可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据故障日志处理方法的电子设备的使用所创建的数据等。此外，存储器402可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器402可选包括相对于处理器401远程设置的存储器，这些远程存储器可以通过网络连接至故障日志处理方法的电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

故障日志处理方法的电子设备还可以包括：输入装置403和输出装置404。处理器401、存储器402、输入装置403和输出装置404可以通过总线或者其他方式连接，图4中以通过总线连接为例。

输入装置403可接收输入的数字或字符信息，以及产生与故障日志处理方法的电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置404可以包括显示设备、辅助照明装置(例如，LED)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用ASIC(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)、互联网和区块链网络。

计算系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决传统物理主机与虚拟专用服务器(VPS，Virtual Private Server)服务中存在的管理难度大，业务扩展性弱的缺陷。

根据本申请实施例的技术方案，在对故障日志进行采集时，由于所采集的N组故障日志为故障机器的各模块调用N个请求产生的全部日志，这样，能够根据N组故障日志，高效地确定故障机器的故障来源模块，从而高效地实现故障定位。在机器发生故障时，可以通过本申请实施例实现故障日志的采集以及故障的定位，能够为运维人员高效排查故障机器提供方便。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。