CN110046073A - 一种日志采集方法及装置、设备、存储介质 - Google Patents

Abstract

本发明实施例涉及计算机领域，公开了一种日志采集方法及装置、设备、存储介质。日志采集方法包括：根据用户上报的第一日志信息，确定用户运行业务时所执行的第一业务分支；若确定第一业务分支不属于标准业务树模型中的第二业务分支，则确定存在异常，并获取异常信息；根据异常信息，生成日志过滤规则；根据日志过滤规则，采集异常日志信息；其中，标准业务树模型包括正常运行业务时经过的各个第二业务分支，每个第二业务分支包括相关应用程序中的业务逻辑节点。通过不属于标准业务树中的第一业务分支，获取异常信息，再根据该异常信息，生成日志过滤规则，采集该日志过滤规则对应的异常日志信息，减少冗余，缩短定位问题的时间，提高效率。

Description

一种日志采集方法及装置、设备、存储介质

技术领域

本发明实施例涉及计算机领域，特别涉及一种日志采集方法及装置、设备、存储介质。

背景技术

目前，随着智能终端用户的不断增加，安装在终端上的相关应用程序会产生各种各样的日志信息，当这些应用程序出现问题，且该问题在产品上线前的测试阶段没有被暴露出来，则研发人员就需要在众多的日志信息中提取有用信息，进行问题定位。若日志种类较多，且该应用程序的用户数达到一定数量级时，比如百万级、千万级等，则该应用程序对应的服务器在处理日志文件时，就会有很多冗余，增加了服务器的处理压力。

此外，现有技术中至少存在如下问题：日志提取开关是否开启过于依赖开发人员的主观意识和开发经验，经常会漏掉一些关键节点上的程序运行信息。由于核心节点的日志信息通常不会很多，无法很好的定位某些特定业务所出现的异常问题，此时只能发送临时安装包给用户，临时采集一些节点上的业务日志文件，用于定位这些业务异常问题，这样就会导致解决问题的周期变长，效率低下。由于采集到的业务日志文件平时根本没有用处，只在出现业务功能异常时才会有助于定位异常问题，另外，由于业务日志文件包括了所有节点上的业务运行情况，但有时出现的异常问题只是对应某一个特定的业务功能，此时并不需要其他业务功能的日志，因此提取所有业务日志文件会产生很多冗余的信息，且开发人员需要过滤这些无效信息的工作量也大。

发明内容

本发明实施方式的目的在于提供一种日志采集方法及装置、设备、存储介质，减少冗余日志信息的提取，提高定位问题的效率，使通过日志文件定位问题的过程通用化，能够根据异常节点的信息确定存在的异常问题，并及时解决该异常问题，提高用户体验度。

为解决上述技术问题，本发明的实施方式提供了一种日志采集方法，包括以下步骤：根据用户上报的第一日志信息，确定用户运行业务时所执行的第一业务分支；若确定第一业务分支不属于标准业务树模型中的第二业务分支，则确定存在异常，并获取异常信息；根据异常信息，生成日志过滤规则；根据日志过滤规则，采集异常日志信息；其中，标准业务树模型包括正常运行业务时经过的各个第二业务分支，每个第二业务分支包括相关应用程序中的业务逻辑节点。

本发明的实施方式还提供了一种日志采集装置，包括：第一模块，确定异常模块，生成模块和采集模块；第一模块，用于根据用户上报的第一日志信息，确定用户运行业务时所执行的第一业务分支；确定异常模块，用于若确定第一业务分支不属于标准业务树模型中的第二业务分支，则确定存在异常，并获取异常信息；生成模块，用于根据异常信息，生成日志过滤规则；采集模块，用于根据日志过滤规则，采集异常日志信息；其中，标准业务树模型包括正常运行业务时经过的各个第二业务分支，每个第二业务分支包括相关应用程序中的业务逻辑节点。

本发明的实施方式还提供了一种电子设备，包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行上述日志采集方法。

本发明的实施方式还提供了一种计算机可读存储介质，存储有计算机程序，该计算机程序被处理器执行时实现上述日志采集方法。

本发明实施方式相对于现有技术而言，通过不属于标准业务树模型的第一业务分支，获取异常信息，再根据该异常信息，生成日志过滤规则，采集该日志过滤规则对应的异常日志信息，可获得更具有针对性的日志文件，减少了冗余，提高了定位问题的效率，使通过日志文件定位问题的过程通用化，能够根据异常信息确定存在的异常问题，并及时解决该异常问题，提高用户体验度。

另外，异常信息包括：运行业务时执行第一业务分支的用户的信息，和，第一业务分支包括的业务逻辑节点。

该方式中，通过运行业务时执行第一业务分支的用户的信息，和，第一业务分支包括的业务逻辑节点，来确定日志过滤规则，可获得特定用户所对应的具有针对性的日志信息，减少冗余，提高定位问题的效率。

另外，异常信息还包括：日志优先等级，和/或，软件版本号。

该方式中，通过日志优先等级，和/或，软件版本号的信息来获得更具有针对性的日志文件，提高定位问题的效率。

另外，标准业务树模型的构建过程包括：在预设时长内，根据各个相关应用程序中的埋点，获得用户上报的第二日志信息；根据第二日志信息，确定用户运行业务时经过的各个第二业务分支；根据各个第二业务分支，确定标准业务树模型。

该方式中，通过预先在相关的应用程序中进行埋点，获得用户上报的第二日志信息，使得在预设时长内，能够确定用户在执行该业务时，具体经过哪些业务分支，进而确定标准业务树模型，为后续定位问题提供对比基础，方便研发人员进行定位。

另外，第二业务分支包括：业务逻辑入口节点、业务逻辑终止节点和从业务逻辑入口节点到业务逻辑终止节点所经过的内部业务逻辑节点。

另外，在若确定第一业务分支不属于标准业务树模型中的第二业务分支，则确定存在异常，并获取异常信息之后，方法还包括：进行第一告警提示。

该方式中，通过第一告警提示开发人员，存在异常运行分支，能够根据异常逻辑节点的信息确定存在的异常问题，并及时解决该异常问题，提高用户体验度。

另外，日志过滤规则中包括：第一业务分支对应的业务的标识，和，运行业务时执行第一业务分支的用户的信息。

另外，根据日志过滤规则，采集异常日志信息，包括：根据执行第一业务分支的用户的信息，下发日志过滤规则至执行第一业务分支的用户；获得执行第一业务分支的用户根据日志过滤规则采集到的异常日志信息。

另外，根据日志过滤规则，采集异常日志信息之后，方法还包括：进行第二告警提示。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。

图1是根据本发明第一实施方式中的日志采集方法流程方框图；

图2是根据本发明第一实施方式中的程序代码分支流程方框图；

图3是根据本发明第二实施方式中的日志采集方法流程方框图；

图4是根据本发明第二实施方式中的标准业务树模型图；

图5是根据本发明第二实施方式中的根据日志文件解决问题的状态流程图；

图6是根据本发明第三实施方式中的日志系统的框架图；

图7是根据本发明第四实施方式中的日志采集装置的结构方框图；

图8是根据本发明第五实施方式中的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。

本发明的第一实施方式涉及一种日志采集方法。用于减少冗余日志信息的提取，进而缩小提取到的日志文件的大小，方便研发人员定位问题，同时，更有针对性的提取出现异常情况的终端所对应的日志信息，使研发人员定位问题的周期缩短，提高定位问题的效率，使通过日志文件定位问题的过程通用化。

下面对本实施方式中的日志采集方法的实现细节进行具体的说明，以下内容仅为方便理解本方案的实现细节，并非实施本方案的必须。

图1所示为本实施方式中的日志采集方法的流程图，该方法应用于服务器。该方法可包括如下步骤。

在步骤101中，根据用户上报的第一日志信息，确定用户运行业务时所执行的第一业务分支。

具体而言，可通过在业务系统的应用程序中预先埋点，来进行日志生成，用户通过客户终端访问业务系统时，相关应用程序根据用户的操作行为执行对应的代码，当执行到预先埋点处时，则自动生成日志信息，并上报给服务器。其中预先埋点可在应用程序中各业务逻辑节点处进行埋点，也就是说，只有当用户的请求执行到该些逻辑分支时，才会触发日志信息的生成。值得注意的是，埋点的范围和粒度具体设定可根据实际需求进行设定。

服务器在接收到用户上报的第一日志信息后，可通过分析用户上报的第一日志信息，确定用户在访问业务系统时，所执行到的逻辑分支，来确定第一业务分支。具体而言，由于用户上报的第一日志信息是基于用户的实际操作过程，所执行到的各个逻辑分支节点处生成并上报的，各节点分支所生成的日志信息可通过添加标识来进行区分，同时可记录日志信息生成的时间，通过该些信息，可确定出用户在访问业务系统时先后执行的业务逻辑节点，通过该些分支节点可构建出第一业务分支。

在步骤102中，若确定第一业务分支不属于标准业务树模型中的第二业务分支，则确定存在异常，并获取异常信息。

当服务器根据第一日志信息构建出第一业务分支后，可通过与标准业务树模型中的各第二业务分支进行比对，确定标准业务树模型中是否存在于第一业务分支相同的第二业务分支，若存在，则确定第一业务分支属于标准业务树模型中的第二业务分支；若不存在，则可确定第一业务分支不属于标准业务树模型中的第二业务分支。

具体而言，标准业务树模型可为预先构建的标准模型，可包括业务系统在正常运行业务时会经过的各个第二业务分支，每个第二业务分支包括相关应用程序中的业务逻辑节点，及先后关系。标准业务树模型的的构建可以是研发人员根据相关应用程序的正常运行逻辑来构建的，也可以是通过其他方式进行构建。

在一个具体实现中，如图2所示，标准业务树模型可包括以下节点：代码入口A1、业务逻辑节点B1、业务逻辑节点C1、业务逻辑节点E1、业务逻辑节点G2、业务逻辑节点B2、代码模块公开API入口A2、代码模块公开API入口A3、业务逻辑节点D2、业务逻辑节点F1和终点，该些节点包含在如下第二业务分支中：代码入口A1、业务逻辑节点B1、业务逻辑节点C1、业务逻辑节点E1、业务逻辑节点G2和终点；代码模块公开API入口A3、业务逻辑节点D2、业务逻辑节点F1、业务逻辑节点G2和终点；代码模块公开API入口A2、业务逻辑节点E1、业务逻辑节点G2和终点。

第一业务分支包括以下节点：业务逻辑节点C2、业务逻辑节点E2，那么可确定标准业务树模型中并不存在于第一业务分支相同的第二业务分支，则可确定存在异常，并获取异常信息。

其中，异常信息包括：运行业务时执行该第一业务分支的用户的信息，和，第一业务分支包括的业务逻辑节点。在一个具体实现中，该异常信息还包括：日志优先等级，和/或，软件版本号。

在一个具体实现中，在执行完步骤102之后，进行第一告警提示。该第一告警提示有可能出现异常，并执行步骤103。

在步骤103中，根据异常信息，生成日志过滤规则。

其中，日志过滤规则中包括：第一业务分支对应的业务的标识，和运行业务时执行第一业务分支的用户的信息。

在一个具体实现中，该日志过滤规则可以是单个的过滤规则，也可以是多个过滤规则的组合，当有多个过滤规则时，各个过滤规则之间用“&”隔开，并以多个过滤规则之间的并集作为最终的生效作用域。例如，在Android系统中，日志的使用方式为：Log.d(TAG,"this is log")；其中，日志优先等级划分为六个等级，该六个等级的优先级从低到高依次为：基础日志信息(VERBOSE)，调试信息(DEBUG)，详细信息(INFO)，告警信息(WARN)，错误信息(ERROR)和断言错误信息(ASSERT)；以上每个级别的日志信息都代表着日志信息的不同属性以及该日志信息的重要程度。

在一个具体实现中，若日志过滤规则为日志优先等级，当TAG＝DEBUG时，表示允许终端采集DEBUG等级及以上优先级的日志；当TAG＝DEBUG-时，表示只允许终端采集DEBUG级别日志；当TAG＝DEBUG-ERROR，表示允许终端采集DEBUG至ERROR范围的日志。

在一个具体实现中，若日志过滤规则为业务维度，例如，在某个应用程序中，adver和player都是用户能够执行的一种业务类型，当TAG＝“adver”时，表示允许用户采集所有执行adver业务时对应的日志信息；当TAG＝“！adver”时，表示允许用户采集所有执行除adver业务以外的其他业务类型对应的日志信息。若该日志过滤规则包括两种业务类型，例如，当TAG＝“adver；player”时，表示允许用户采集所有执行adver业务或者player业务时对应的日志信息；当TAG＝“！adver；player”，表示只允许用户采集执行player业务的日志，其中！adver失效。若日志过滤规则为多个过滤规则的组合，支持同时指定多个业务类型的过滤，中间以分号“；”隔开，例如，日志过滤规则为：TAG＝“adver&ERROR&V1.03”，其中，V1.03表示软件版本号，该日志过滤规则表示，所有执行adver业务的日志类型为ERROR的，并且软件版本号为V1.03的日志信息，在实际操作中，就需要提取用户10010和用户10020上的所有日志类型为ERROR的，并且软件版本号为V1.03的日志信息，并将该日志信息保存到对应的日志文件中。

在一个具体实现中，例如，在某个应用程序中，日志的使用方式为：Log.d(TAG,"this is log")；，其中的TAG通常被用来标识日志的来源，所以通常TAG的取值都是当前类名，研发人员在看到这条日志的TAG时，就清楚该去哪块代码寻找。为了兼容这种使用方式，对系统Log类进行一层封装，在支持系统原有方法的基础上，将所有方法进行重载，新增一个参数subtag，用于作为业务维度的标识之一，使用规则同TAG，如subtag＝adver，表示采集所有以adver作为subtag的日志。这样既可兼容传统的日志系统使用，也丰富了日志过滤规则，其中，subtag是作为TAG规则的补充。当同时使用多条过滤规则时，如日志过滤规则为“DEBUG&(TAG＝adver；dsp)&(subtag＝！adver；player)”，此时，以各维度的规则的并集作为生效的作用域；则该过滤规则的效果就是：允许用户采集所有DEBUG级别及以上，且TAG取值为adver或dsp，或subtag取值为player的日志信息，并将该日志信息保存到对应的日志文件中。

在生成了日志过滤规则后，服务器可将该日志过滤规则下发给对应的用户(即客户终端)，客户终端将基于该日志过滤规则对本地生成的日志信息进行过滤上报。

在步骤104中，根据日志过滤规则，采集异常日志信息。

服务器在下发日志过滤规则后，接收到对应的客户终端上传的日志信息可确定为异常日志信息，并可对异常日志信息进行分类管理，统一反馈给后台运维人员。

需要说明的是，用户采集的异常日志信息，根据其用途及性质可分为不同的类别，常见的有：崩溃(crash)日志信息、统计日志信息、调试日志信息、业务日志信息等。

不同类别的日志信息用途不一样，其中，崩溃日志信息用于收集客户终端上的应用程序在出现异常崩溃时的相关方法栈等信息，可用于统计该应用程序的崩溃率，方便开发人员根据日志进行排查并解决所出现的问题；调试日志信息主要是开发人员在开发期间设置的日志，用于帮助开发人员在开发期间验证相关功能是否有正确实现，这类日志信息的开关一般在上线的版本中会被关闭；统计日志信息用于统计应用程序中各元素组件的使用情况，最终生成对应的热点图，方便用户查看产品中的哪些元素模块比较受用户喜欢；业务日志信息用于查看用户的终端在运行对应业务时出现异常，所经过的应用程序中的各个逻辑分支的信息，即业务追踪链信息，来排查解决此异常问题；其中的崩溃日志信息和统计日志信息是必须要采集的日志，当用户数达到一定量级时，上报到服务器的调试日志信息和业务日志信息的信息量会成指数级增长，因此需要重点关注调试日志信息和业务日志信息的采集，可根据日志过滤规则，采集实际需要的异常日志信息。

在一个具体实现中，根据执行第一业务分支的用户的信息，下发日志过滤规则至执行第一业务分支的用户；获得执行第一业务分支的用户根据日志过滤规则采集到的异常日志信息。

例如，将日志过滤规则下发给执行第一业务分支的用户，当该用户接收到该日志过滤规则后，收集该日志过滤规则对应的异常日志信息，并将这些异常日志信息保存到对应的异常日志文件中，上报该异常日志文件给服务器，服务器接收到终端上报的异常日志文件后，反馈给研发人员，进行问题定位。

在一个具体实现中，在执行完步骤104之后，可进行第二告警提示。该第二告警提示研发人员或运维人员，当前已提取到了异常日志信息，需要研发人员根据包含该异常日志信息的异常日志文件，具体定位异常发生的原因，即确定该异常对应的应用程序中具体存在什么问题。

在本实施方式中，通过确定出第一业务分支是否为异常分支，进而获取异常信息，再根据该异常信息，生成日志过滤规则，采集该日志过滤规则对应的异常日志信息，可获得更具有针对性的日志文件，减少了冗余，提高了定位问题的效率，使通过日志文件定位问题的过程通用化，能够根据异常信息确定存在的异常问题，并及时解决该异常问题，提高用户体验度。

本发明的第二实施方式涉及一种日志采集方法。第二实施方式与第一实施方式大致相同，主要区别之处在于：在根据用户上报的第一日志信息，确定用户运行业务时所执行的第一业务分支之前，还需要构建标准业务树模型。

具体处理流程如图3所示，在本实施方式中，该日志采集方法包括步骤301～307，因该实施方式中步骤304～307，与第一实施方式中的步骤101～104相同，在此不再赘述，下面具体介绍本实施方式中的步骤301～303。其中，步骤301～303介绍了标准业务树模型的构建过程。

在步骤301中，在预设时长内，根据各个相关应用程序中的埋点，获得用户上报的第二日志信息。

在一个具体实现中，当业务系统初次上线，或进行更新升级之后，基于预先在应用程序的各业务逻辑节点中的埋点，在预设时间段内，获得用户上报的第二日志信息。需要说明的是，该第二日志信息是用户主动采集的，持续的、不间断的上报给服务器的。

在步骤302中，根据第二日志信息，确定用户运行业务时经过的各个第二业务分支。

需要说明的是，第二日志信息中记录了用户运行业务时，所出现的各种信息，包括用户的标识，业务的标识，业务运行时经过了哪些业务逻辑节点等，根据以上信息，就可确定第二业务分支。其中，第二业务分支包括：业务入口节点、业务终止节点和从业务入口节点到业务终止节点所经过的业务逻辑节点。

在一个具体实现中，如图2所示，业务逻辑入口节点包括：代码入口A1、代码模块公开API入口A2和代码模块公开API入口A3；业务逻辑终止节点包括：终点；从业务逻辑入口节点到业务逻辑终止节点所经过的业务逻辑节点包括：B1、C1、E1、G2；或，B2、D2、F1、G2。

在步骤303中，根据各个第二业务分支，确定标准业务树模型。

在一个具体实现中，根据第一实施方式中的图2所示的各个第二业务分支，生成如图4所示的标准业务树模型。其中的百分数表示经过各个分支的终端的数量占所有运行此标准业务树对应的业务的终端的数量的百分比，例如，其中的46％表示，假定所有运行此标准业务树对应的业务的终端的数量为100，则在运行此业务时，从代码入口A1经过业务逻辑节点B1、业务逻辑节点C1、业务逻辑节点E1和业务逻辑节点G2到达终点的终端的数量为46；其中的36％表示在运行此业务时，从代码入口A1经过业务逻辑节点B2、业务逻辑节点D2、业务逻辑节点F1、业务逻辑节点G2到达终点的终端的数量为36；其中的10％表示在运行此业务时，从代码模块公开API入口A3经过业务逻辑节点E1和业务逻辑节点G2到达终点的终端的数量为10；其中的8％表示在运行此业务时，从代码模块公开API入口A2经过业务逻辑节点F1、业务逻辑节点G2到达终点的终端的数量为8。

需要说明的是，一个大型的业务系统中可包含多个不同的子业务，可根据业务的复杂程度，选择构建标准业务树模型的方式，例如，若业务系统包含的子业务较少，且简单，则可以针对该业务系统构建一个标准业务树模型；若业务系统包含的子业务较多，且功能复杂，那么也可针对各个子业务构建对应的标准业务树模型。

需要说明的是，在完成标准业务树模型的初步构建后，可对其进行验证，验证标准树模型的方法可包含：运维人员基于应用程序中所包含的正常业务分支对标准树模型进行分析验证，若有错误，则进行人工调整；或者，服务器根据预设程序自动验证，即预设的验证时间段内，判断该标准树模型是否趋于稳定，若在一定时间段内，该标准业务树模型趋于稳定，则确定该标准业务树模型构建完成。其中，预设的验证时间段是基于实际情况确定的，在该预设的验证时间段内，能够统计到所有用户在业务逻辑分支上的所有使用记录即可。

在该实施方式中，通过构建标准业务树模型，服务器可以精准的知道哪部分群体的用户出现了异常问题，根据异常信息获得日志过滤规则，精准的选择用户群体来采集相关的异常日志信息，滤除掉冗余日志信息，进而缩小所采集到的日志文件的大小，降低开发人员分析的工作量，保证问题定位的有效性。

根据本发明的第一或第二实施例中所描述的日志采集方法获得日志文件，进而根据该日志文件解决异常问题的状态流程图，如图5所示。

在步骤501中，用户在运行某一业务时，持续上报第二日志信息。

在步骤502中，服务器根据用户上报的第二日志信息，确定用户运行业务时经过的各个第二业务分支，即业务运行追踪链；在预设时间内，服务器根据各个第二业务分支，建立标准业务树模型，并通过该标准业务树模型对用户在运行该业务时的状态进行监控和预警。

在步骤503中，用户持续上报第一日志信息。

在步骤504中，服务器根据用户上报的第一日志信息，确定存在不属于标准业务树的第一业务分支，获得该第一业务分支对应的异常信息，进而生成日志过滤规则。

在步骤505中，服务器将该日志过滤规则下发给执行第一业务分支的用户。

在步骤506中，当该用户接收到服务器下发的日志过滤规则时，过滤掉无效的日志信息，将符合日志过滤规则的异常日志信息保存到对应的异常日志文件中，上报给服务器。

在步骤507中，服务器将获得的符合日志过滤规则的异常日志文件，发送给开发人员和运维人员。

在步骤508中，开发人员根据获得的异常日志文件，进行问题定位，找到解决异常问题的方法。

在步骤509中，在用户运行的业务功能出现异常问题时，用户反馈该异常问题给运维人员，或向运维人员投诉该异常问题。

通过以上过程，使得开发人员能够及时发现异常问题并解决，减少给用户带来不好的影响。即使用户发现并投诉该业务功能的异常问题，开发人员也可以根据服务器所建立的标准业务树模型的监测状况，来下发对应的日志过滤规则给用户，采集相关日志文件。相对于现有技术方案而言，开发人员会占据更多的主动权，避免了发布临时安装包给用户，提高了定位问题的效率。

上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本发明的第三实施方式涉及一种日志采集系统，该日志采集系统的具体组成结构，如图6所示，其中，服务器和用户均是应用第一或第二实施例所描述的方法构建的。当用户没有出现异常问题时，用户所获取到的调试日志和业务日志都是正常运行情况下的日志，这些日志所能表达出的信息都代表着该用户处于正常状态，没必要去对这些日志做分析；若用户出现了异常问题，则服务器会产生区别于标准业务树模型中的第二业务分支的新的分支，根据该新的分支对应的异常信息，生成日志过滤规则，服务器下发该日志过滤规则给该用户，则该用户根据该日志过滤规则，确定需要提取App应用层中的某个功能模块所对应的日志信息，比如，提取功能模块A的业务日志信息，则该用户通过核心工作模块中的配置(config)组件对服务端下发的日志过滤规则进行过滤控制，通过输入/输出(I/O)组件进行写日志文件的操作，使用压缩(gzip)组件将该日志文件进行压缩处理，使用上传(upload)组件上报该日志文件给服务器。

本发明的第四实施方式涉及一种日志采集装置，该装置的具体实施可参见第一实施方式的相关描述，重复之处不再赘述。值得说明的是，本实施方式中的装置的具体实施也可参见第二实施方式的相关描述，但不局限于以上两个实施例，其他未说明的实施例也在本装置的保护范围之内。

如图7所示，该装置主要包括：第一模块701，确定异常模块702，生成模块703和采集模块704，该些模块可基于计算机程序实现。

第一模块701用于根据用户上报的第一日志信息，确定用户运行业务时所执行的第一业务分支；确定异常模块702用于若确定第一业务分支不属于标准业务树模型中的第二业务分支，则确定存在异常，并获取异常信息；生成模块703用于根据异常信息，生成日志过滤规则；采集模块704用于根据日志过滤规则，采集异常日志信息；其中，标准业务树模型包括正常运行业务时经过的各个第二业务分支，每个第二业务分支包括相关应用程序中的业务逻辑节点。

不难发现，本实施方式为与第一或第二实施方式相对应的装置实施例，本实施方式可与第一或第二实施方式互相配合实施。第一或第二实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第一或第二实施方式中。

值得一提的是，本实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施方式中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。

本申请第五实施方式提供了一种电子设备，该设备具体结构如图8所示。包括至少一个处理器801；以及，与至少一个处理器801通信连接的存储器802。其中，存储器802存储有可被至少一个处理器801执行的指令，指令被至少一个处理器801执行，以使至少一个处理器801能够执行第一实施方式所描述的日志采集方法。

本实施方式中，处理器801以中央处理器(Central Processing Unit，CPU)为例，存储器802以可读写存储器(Random Access Memory，RAM)为例。处理器801、存储器802可以通过总线或者其他方式连接，图8中以通过总线连接为例。存储器802作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如本申请实施例中实现日志采集方法的程序就存储于存储器802中。处理器801通过运行存储在存储器802中的非易失性软件程序、指令以及模块，从而执行设备的各种功能应用以及数据处理，即实现上述日志采集方法。

存储器802可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储选项列表等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器802可选包括相对于处理器801远程设置的存储器，这些远程存储器可以通过网络连接至外接设备。

一个或者多个程序模块存储在存储器802中，当被一个或者多个处理器801执行时，执行上述任意方法实施例中的日志采集方法。

上述产品可执行本申请实施例所提供的方法，具备执行方法相应的功能模块和有益效果，未在本实施例中详尽描述的技术细节，可参见本申请实施例所提供的方法。

本申请的第六实施方式涉及一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，该计算机程序被处理器执行时能够实现本申请任意方法实施例中涉及的日志采集方法。

本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (12)

1.一种日志采集方法，其特征在于，应用于服务器，所述方法包括：

根据用户上报的第一日志信息，确定所述用户运行业务时所执行的第一业务分支；

若确定所述第一业务分支不属于标准业务树模型中的第二业务分支，则确定存在异常，并获取异常信息；

根据所述异常信息，生成日志过滤规则；

根据所述日志过滤规则，采集异常日志信息；

其中，所述标准业务树模型包括正常运行所述业务时经过的各个所述第二业务分支，每个所述第二业务分支包括相关应用程序中的业务逻辑节点。

2.根据权利要求1所述的日志采集方法，其特征在于，所述异常信息包括：运行所述业务时执行所述第一业务分支的用户的信息，和，所述第一业务分支包括的业务逻辑节点。

3.根据权利要求2所述的日志采集方法，其特征在于，所述异常信息还包括：

日志优先等级，和/或，软件版本号。

4.根据权利要求1至3中任一项所述的日志采集方法，其特征在于，所述标准业务树模型的构建过程包括：

在预设时长内，根据各个所述相关应用程序中的埋点，获得所述用户上报的第二日志信息；

根据所述第二日志信息，确定所述用户运行所述业务时经过的各个所述第二业务分支；

根据各个所述第二业务分支，确定所述标准业务树模型。

5.根据权利要求4所述的日志采集方法，其特征在于，所述第二业务分支包括：

业务逻辑入口节点、业务逻辑终止节点和从所述业务逻辑入口节点到所述业务逻辑终止节点所经过的内部业务逻辑节点。

6.根据权利要求5所述的日志采集方法，其特征在于，在若确定所述第一业务分支不属于标准业务树模型中的第二业务分支，则确定存在异常，并获取异常信息之后，所述方法还包括：

进行第一告警提示。

7.根据权利要求1所述的日志采集方法，其特征在于，所述日志过滤规则中包括：

所述第一业务分支对应的业务的标识，和，运行所述业务时执行所述第一业务分支的用户的信息。

8.根据权利要求7所述的日志采集方法，其特征在于，根据所述日志过滤规则，采集异常日志信息，包括：

根据所述执行第一业务分支的用户的信息，下发所述日志过滤规则至所述执行第一业务分支的用户；

获得所述执行第一业务分支的用户根据所述日志过滤规则采集到的所述异常日志信息。

9.根据权利要求7或8所述的日志采集方法，其特征在于，根据所述日志过滤规则，采集异常日志信息之后，所述方法还包括：

进行第二告警提示。

10.一种日志采集装置，其特征在于，包括：第一模块，确定异常模块，生成模块和采集模块；

所述第一模块，用于根据用户上报的第一日志信息，确定所述用户运行业务时所执行的第一业务分支；

所述确定异常模块，用于若确定所述第一业务分支不属于标准业务树模型中的第二业务分支，则确定存在异常，并获取异常信息；

所述生成模块，用于根据所述异常信息，生成日志过滤规则；

所述采集模块，用于根据所述日志过滤规则，采集异常日志信息；

其中，所述标准业务树模型包括正常运行所述业务时经过的各个第二业务分支，每个所述第二业务分支包括应用程序中的业务逻辑节点。

11.一种电子设备，其特征在于，包括：

至少一个处理器；以及，

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

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至9中任一所述的日志采集方法。

12.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至9中任一所述的日志采集方法。