一种基于日志的故障分析方法及装置与流程

本说明书涉及互联网技术领域，特别涉及一种基于日志的故障分析方法、装置、计算设备及计算机可读存储介质。

背景技术：

程序日志文件主要用于记录引擎底层及应用逻辑层系统状态变化过程，几乎所有的平台系统都会有一组操作日志的接口，日志框架系统的复杂度有高有低，具体目的主要是为调试及运营数据查询需要，可以说日志框架是否简洁易用，将直接影响到开发及运营效率。现有技术中的多数日志文件平时都是无用的，特别是当系统一切正常的时候，开发人员可能会删除许多的日志文件，但是如果系统出现异常，则又需要日志文件，然而，现有技术中以在出现异常时充分的利用日志文件，也不能基于日志文件对故障进行及时的排查和分析，导致在修复故障时需要耗费大量人力，降低了开发及运营效率。

技术实现要素：

有鉴于此，本说明书实施例提供了一种基于日志的故障分析方法、装置、计算设备及计算机可读存储介质，以解决现有技术中存在的技术缺陷。

根据本说明书实施例的第一方面，提供了一种基于日志的故障分析方法，包括：

实时获取由至少一个客户端上传的客户端信息，其中，所述客户端信息包括程序日志信息、ip地址信息和硬件基础信息；

在所述至少一个客户端中的任意所述客户端出现故障的情况下，获取所述客户端在故障发生时刻对应的至少一个带有日志标识的程序日志信息；

根据所述至少一个带有日志标识的程序日志信息确定触发故障的异常程序对应的开发信息，并对所述至少一个带有日志标识的程序日志信息按照类型和数量进行统计。

根据本说明书实施例的第二方面，提供了一种基于日志的故障分析装置，包括：

信息获取模块，被配置为实时获取由至少一个客户端上传的客户端信息，其中，所述客户端信息包括程序日志信息、ip地址信息和硬件基础信息；

日志获取模块，被配置为在所述至少一个客户端中的任意所述客户端出现故障的情况下，获取所述客户端在故障发生时刻对应的至少一个带有日志标识的程序日志信息；

故障分析模块，被配置为根据所述至少一个带有日志标识的程序日志信息确定触发故障的异常程序对应的开发信息，并对所述至少一个带有日志标识的程序日志信息按照类型和数量进行统计。

根据本说明书实施例的第三方面，提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现所述基于日志的故障分析方法的步骤。

根据本说明书实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现所述基于日志的故障分析方法的步骤。

本申请能够在客户端出现报错或宕机等故障的情况下，在服务器中获取在故障发生时刻对应的带有日志标识的程序日志信息，利用程序日志信息和软件配置管理工具对应用程序的故障触发原因进行分析，可自动追朔到触发报错的异常程序的开发信息，并对程序日志信息进行统计和分析，使得开发人员能够及时排查代码故障，从而大幅提高了系统故障排查效率，减少了人力资源的浪费。

附图说明

图1是本申请实施例提供的计算设备的结构框图；

图2是本申请实施例提供的基于日志的故障分析方法的流程图；

图3是本申请实施例提供的基于日志的故障分析方法的另一流程图；

图4是本申请实施例提供的基于日志的故障分析方法的另一流程图；

图5是本申请实施例提供的基于日志的故障分析方法的另一流程图；

图6是本申请实施例提供的基于日志的故障分析装置的结构示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

首先，对本发明一个或多个实施例涉及的名词术语进行解释。

日志：网络设备、系统及服务程序等，在运作时都会产生一个叫log的事件记录；每一行日志都记载着日期、时间、使用者及动作等相关操作的描述。windows网络操作系统都设计有各种各样的日志文件，如应用程序日志信息，安全日志、系统日志、scheduler服务日志、ftp日志、www日志、dns服务器日志等等，这些根据系统开启的服务的不同而有所不同，在系统上进行一些操作时，这些日志文件通常会记录下用户操作的一些相关内容。

日志标识：开源项目log4j定义了8个级别的日志(除去off和all，可以说分为6个级别)，优先级从高到低依次为：off、fatal、error、warn、info、debug、trace、all，如果将loglevel设置在某一个级别上，那么比此级别优先级高的log都能打印出来。例如，如果设置优先级为warn，那么off、fatal、error、warn4个级别的日志能正常输出，而info、debug、trace、all级别的log则会被忽略。

软件配置管理：软件配置管理(softwareconfigurationmanagement，scm)是指通过执行版本控制、变更控制的规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性，配置管理是对工作成果的一种有效保护。它是一种标识、组织和控制修改的技术，用于整个软件生存期，在软件建立时会经常产生变更，而变更加剧了项目中软件人员之间的混乱，之所以产生混乱，是因为在进行变更前没有仔细分析，或没有进行变更控制。因为变更在任何时刻都可能发生,因此软件配置管理活动的目标就是为了标识变更,控制变更,确保变更正确地实现,向其他有关的人报告变更。

在本申请中，提供了一种基于日志的故障分析方法、装置、计算设备及计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1示出了根据本说明书一实施例的计算设备100的结构框图。该计算设备100的部件包括但不限于存储器110和处理器120。处理器120与存储器110通过总线130相连接，数据库150用于保存数据。

计算设备100还包括接入设备140，接入设备140使得计算设备100能够经由一个或多个网络160通信。这些网络的示例包括公用交换电话网(pstn)、局域网(lan)、广域网(wan)、个域网(pan)或诸如因特网的通信网络的组合。接入设备140可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(nic))中的一个或多个，诸如ieee802.11无线局域网(wlan)无线接口、全球微波互联接入(wi-max)接口、以太网接口、通用串行总线(usb)接口、蜂窝网络接口、蓝牙接口、近场通信(nfc)接口，等等。

在本说明书的一个实施例中，计算设备100的上述部件以及图1中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图1所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备100可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或pc的静止计算设备。计算设备100还可以是移动式或静止式的服务器。

其中，处理器120可以执行图2所示方法中的步骤。图2是示出了根据本申请一实施例的基于日志的故障分析方法的示意性流程图，包括步骤202至步骤206。

步骤202：实时获取由至少一个客户端上传的客户端信息，其中，所述客户端信息包括程序日志信息。

在本申请实施例中，本申请的系统包括服务器和至少一个客户端，每个客户端能够实时上传自身的程序日志信息、ip地址信息和硬件基础信息，其中，所述硬件基础信息包括作为客户端的硬件设备的cpu、内存、存储空间、系统版本、设备型号和设备厂家等信息。

步骤204：在所述至少一个客户端中的任意所述客户端出现故障的情况下，获取所述客户端在故障发生时刻对应的至少一个带有日志标识的程序日志信息。

在本申请实施例中，在系统中的任意所述客户端出现故障的情况下，本申请的服务器能够获取所述客户端上报的至少一个带有日志标识的程序日志信息，其中，所述日志标识包括error、warning、assert、exception、info以及debug六个等级，在每个客户端中设置有可以自定义的日志标识开关，日志标识开关会根据每类日志标识对应的等级决定是否将该程序日志信息上报至服务器，例如，运行在客户端中的程序出现了异常并在生成程序日志信息认为本次异常的等级为关键错误(error)，就在输出程序日志信息时携带error标签，同时，如果error标签属于日志标识开关中需要进行上报的等级，则将该程序日志信息上传至服务器，如果error标签不属于日志标识开关中需要进行上报的等级，则不上传所述程序日志信息。

在本申请的实施例中，error标签和warning标签属于应当上传的等级，assert标签和exception标签属于可以上传的等级，info标签和debug标签属于一般不用上传的等级。

步骤206：根据所述至少一个带有日志标识的程序日志信息确定触发故障的异常程序对应的开发信息，并对所述至少一个带有日志标识的程序日志信息按照类型和数量进行统计。

在本申请实施例中，本申请的服务器能够从出现故障的客户端上传的程序日志文件中挑选出所述客户端在故障发生时刻对应的至少一个带有error标签或warning标签的程序日志信息，然后根据程序日志信息追溯到触发故障的异常程序对应的开发信息，并对出现故障的客户端上传的至少一个带有日志标识的程序日志信息进行统计分析，分析的内容主要包括但不限于报错日志，并对日志的各种等级或者每个等级的日志对应的具体数目进行统计。

本申请能够在客户端出现报错或宕机等故障的情况下，在服务器中获取在故障发生时刻对应的带有日志标识的程序日志信息，利用程序日志信息和软件配置管理工具对应用程序的故障触发原因进行分析，可自动追朔到触发报错的异常程序的开发信息，并对程序日志信息警醒统计和分析，使得开发人员能够及时排查代码故障，从而大幅提高了系统故障排查效率，减少了人力资源的浪费。

图3示出了本说明书一实施例的基于日志的故障分析方法，该基于日志的故障分析方法以对基于日志的故障分析为例进行描述，包括步骤302至步骤310。

步骤302：实时获取由至少一个客户端上传的客户端信息，其中，所述客户端信息包括程序日志信息、ip地址信息和硬件基础信息。

在本申请实施例中，本申请的系统包括服务器和至少一个客户端，每个客户端能够实时上传自身的程序日志信息、ip地址信息和硬件基础信息，其中，所述硬件基础信息包括作为客户端的硬件设备的cpu、内存、存储空间、系统版本、设备型号和设备厂家等信息。

步骤304：在所述至少一个客户端中的任意所述客户端出现应用程序错误的情况下，获取所述应用程序在错误发生时刻对应的至少一个带有日志标识的程序日志信息。

在本申请实施例中，在运行在任意所述客户端上的应用程序出现错位的情况下，所述客户端能够立即上报至少一个带有报错标识的程序日志信息，例如，至少一个带有error、warning、assert或exception标识的程序日志信息。

步骤306：从所述至少一个带有日志标识的程序日志信息中获取所述异常程序对应的基本信息。

在本申请实施例中，本申请的服务器能够从带有报错标识的程序日志信息中获取所述应用程序对应的基本信息，所述应用程序对应的基本信息包括应用程序的版本信息、设备信息、场景信息或对应的账号信息等等。

步骤308：调用预存的软件配置管理工具，根据所述应用程序对应的基本信息在所述软件配置管理工具中进行匹配，获取所述应用程序在错误发生时刻对应的提交历史信息。

在本申请实施例中，本申请的服务器能够调用预存的软件配置管理(scm)工具，所有的scm工具都提供了对代码进行修改的时间和修改人信息的检索，通过将检索指定时间内的信息并于所述应用程序对应的基本信息在所述软件配置管理工具中进行匹配，从而获取所述应用程序在错误发生时刻对应的提交历史信息。

步骤310：根据所述提交历史信息确定触发所述应用程序发生错误的代码以及开发人员。

在本申请实施例中，本申请的服务器根据所述提交历史信息确定触发所述应用程序发生错误的代码在源代码中的行号以及撰写该部分代码的开发人员。

图4示出了本说明书一实施例的基于日志的故障分析方法，该基于日志的故障分析方法以对基于日志的故障分析为例进行描述，包括步骤402至步骤412。

步骤402：实时获取由至少一个客户端上传的客户端信息，其中，所述客户端信息包括程序日志信息、ip地址信息和硬件基础信息。

在本申请实施例中，本申请的系统包括服务器和至少一个客户端，每个客户端能够实时上传自身的程序日志信息、ip地址信息和硬件基础信息，其中，所述硬件基础信息包括作为客户端的硬件设备的cpu、内存、存储空间、系统版本、设备型号和设备厂家等信息。

步骤404：获取所述客户端在宕机发生时刻生成的宕机文件。

在本申请实施例中，在客户端的系统宕机时会生成宕机文件(crash文件)，即使系统崩溃了客户端也能够收集宕机信息，出现宕机的客户端能够立即将宕机文件上传至服务器。

步骤406：根据所述宕机文件的生成日期，获取所述客户端在宕机发生时刻对应的至少一个带有日志标识的程序日志信息。

在本申请实施例中，本申请的服务器在获取客户端上传的宕机文件之后，根据所述宕机文件的生成日期，从该客户端上传的全部程序日志信息中挑选所述客户端在宕机发生时刻对应的至少一个带有报错标识的程序日志信息，挑选过程不存在固定标准由程序的复杂度而定，例如，客户端a需要和客户端b通信，如果客户端a宕机了，有可能是客户端b向客户端a发送了错误信息导致的，也可以结合客户端b的程序日志信息和客户端a的程序日志信息一起分析。

步骤408：从所述至少一个带有日志标识的程序日志信息中获取所述异常程序对应的基本信息。

在本申请实施例中，本申请的服务器能够从带有报错标识的程序日志信息中获取所述应用程序对应的基本信息，所述应用程序对应的基本信息包括应用程序的版本信息、设备信息、场景信息或对应的账号信息等等。

步骤410：调用预存的软件配置管理工具，根据所述应用程序对应的基本信息在所述软件配置管理工具中进行匹配，获取所述应用程序在错误发生时刻对应的提交历史信息。

在本申请实施例中，本申请的服务器能够调用预存的软件配置管理(scm)工具，所有的scm工具都提供了对代码进行修改的时间和修改人信息的检索，通过将检索指定时间内的信息并于所述应用程序对应的基本信息在所述软件配置管理工具中进行匹配，从而获取所述应用程序在错误发生时刻对应的提交历史信息。

步骤412：根据所述提交历史信息确定触发所述应用程序发生错误的代码以及开发人员。

在本申请实施例中，本申请的服务器根据所述提交历史信息确定触发所述应用程序发生错误的代码在源代码中的行号以及撰写该部分代码的开发人员。

在本申请的一个实施例中，在根据所述至少一个带有日志标识的程序日志信息确定触发故障的异常程序对应的开发信息，并对所述至少一个带有日志标识的程序日志信息按照类型和数量进行统计之后，还包括：

将触发故障的异常程序对应的开发信息以及程序日志信息的统计结果，通过邮件的方式发送至开发人员。

在本申请实施例中，本申请的服务器将异常程序对应的开发信息以及程序日志信息的统计结果，分析结果会通过邮件的方式告知技术人员，从而使得与代码相关的创建与编辑人员能够及时获知问题情况便于及时排查故障。当然，也可以通过其他的即时通讯工具进行通知。

在本申请的一个实施例中，如图5所示，所述实时获取由至少一个客户端上传的客户端信息包括步骤502至步骤504。

步骤502：通过http协议与客户端进行通讯，实时获取所述至少一个客户端上传的客户端信息。

步骤504：通过网页浏览器使用前端网页对所述客户端信息进行查询和浏览。

在本申请实施例中，本申请的服务器通过http协议与客户端进行通讯，在服务器部署了网页浏览日志服务，客户端收集了所有客户端的程序日志信息,提供网页浏览器可以输入任意客户端的ip地址信息，定点查看某台设备的日志实事刷新，从而可以实时且方便的查看日志。

本申请实现了根据需要对日志进行分级并且自动上报，且具体代码能够追朔到代码的创建和编辑者，一旦发现系统出现问题或者宕机，即可自动追朔到代码相关的创建与编辑人员，便于及时排查代码故障。此外，在客户端发生宕机后，服务器自动获取宕机文件，拿回对应时间的日志进行宕机分析，从而大幅提高了宕机后的故障排查效率。

与上述方法实施例相对应，本说明书还提供了基于日志的故障分析装置实施例，图6示出了本说明书一个实施例的基于日志的故障分析装置的结构示意图。如图6所示，该装置应用于服务器，包括：

信息获取模块601，被配置为实时获取由至少一个客户端上传的客户端信息，其中，所述客户端信息包括程序日志信息、ip地址信息和硬件基础信息；

日志获取模块602，被配置为在所述至少一个客户端中的任意所述客户端出现故障的情况下，获取所述客户端在故障发生时刻对应的至少一个带有日志标识的程序日志信息；

故障分析模块603，被配置为根据所述至少一个带有日志标识的程序日志信息确定触发故障的异常程序对应的开发信息，并对所述至少一个带有日志标识的程序日志信息按照类型和数量进行统计。

可选的，所述日志获取模块602包括：

错误日志获取单元，被配置为在所述至少一个客户端中的任意所述客户端出现应用程序错误的情况下，获取所述应用程序在错误发生时刻对应的至少一个带有日志标识的程序日志信息。

可选的，所述日志获取模块602包括：

宕机文件获取单元，被配置为获取所述客户端在宕机发生时刻生成的宕机文件；

宕机日志获取单元，被配置为根据所述宕机文件的生成日期，获取所述客户端在宕机发生时刻对应的至少一个带有日志标识的程序日志信息。

可选的，所述故障分析模块603包括：

基本信息抽取单元，被配置为从所述至少一个带有日志标识的程序日志信息中获取出现错误的所述应用程序对应的基本信息；

历史信息获取单元，被配置为调用预存的软件配置管理工具，根据所述应用程序对应的基本信息在所述软件配置管理工具中进行匹配，获取所述应用程序在错误发生时刻对应的提交历史信息；

代码追踪单元，被配置为根据所述提交历史信息确定触发所述应用程序发生错误的代码以及开发人员。

可选的，所述带有日志标识的程序日志信息包括带有error、warning、assert和/或exception标识的程序日志信息。

可选的，所述装置还包括：

发送至模块，被配置为将触发故障的异常程序对应的开发信息以及程序日志信息的统计结果，通过邮件的方式发送至开发人员。

可选的，所述信息获取模块601包括：

通讯单元，被配置为通过http协议与客户端进行通讯，实时获取所述至少一个客户端上传的客户端信息；

查询单元，被配置为通过网页浏览器使用前端网页对所述客户端信息进行查询和浏览。

本申请能够在客户端出现报错或宕机等故障的情况下，在服务器中获取在故障发生时刻对应的带有日志标识的程序日志信息，利用程序日志信息和软件配置管理工具对应用程序的故障触发原因进行分析，可自动追朔到触发报错的异常程序的开发信息，并对程序日志信息警醒统计和分析，使得开发人员能够及时排查代码故障，从而大幅提高了系统故障排查效率，减少了人力资源的浪费。

本申请一实施例还提供一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现以下步骤：

实时获取由至少一个客户端上传的客户端信息，其中，所述客户端信息包括程序日志信息；

在所述至少一个客户端中的任意所述客户端出现故障的情况下，获取所述客户端在故障发生时刻对应的至少一个带有日志标识的程序日志信息；

根据所述至少一个带有日志标识的程序日志信息确定触发故障的异常程序对应的开发信息，并对所述至少一个带有日志标识的程序日志信息按照类型和数量进行统计。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现如前所述基于日志的故障分析方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该计算机可读存储介质的技术方案与上述的基于日志的故障分析方法的技术方案属于同一构思，计算机可读存储介质的技术方案未详细描述的细节内容，均可以参见上述基于日志的故障分析方法的技术方案的描述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。