CN107181721A - 一种基于日志的信息处理方法及装置 - Google Patents

Abstract

本申请公开了一种基于日志的信息处理方法及装置，该方法包括：监测业务功能对用户发出的业务请求的响应结果，当监测到所述响应结果为失败时，获取所述业务请求对应的各业务功能的日志，在所述日志中，确定与该业务请求对应的日志信息，根据所述日志信息，确定各业务功能对应的中间业务结果，根据中间业务结果中的失败结果，生成标示有失败结果的业务图形，并展示。通过本方法，能够客观且明确地显示出对业务请求的处理过程中出现问题的环节所在。

Description

一种基于日志的信息处理方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种基于日志的信息处理方法及装置。

背景技术

随着信息技术的发展，在线系统(如：网站)中通常包含多种业务系统，用以提供不同的业务功能，从而，在线系统在这些业务系统的支持下，可面向用户提供丰富的业务服务。

目前，对于各业务系统中的业务功能而言，可能会受到运行环境、兼容性等因素的影响，造成业务功能中的部分功能出现问题(也称为业务障碍点)，从而导致业务服务在用户使用的过程中出错。例如：用户通过某网站内提供的账户注册业务，在该网站中的进行注册，若该过程中，账户注册业务中识别账户名的功能出现问题，那么，将造成该用户所填写的账户名无法被识别，进一步导致注册账户失败。显然，为了降低或避免上述问题对用户使用时的影响，就需要及时确定出业务功能所出现的问题，以便对该业务功能进行优化(如：针对出现故障的业务功能更新相应的补丁)。

现有技术中，确定业务功能所出现的问题，通常依赖于使用该业务功能的用户所反馈的意见。

但在实际应用中，用户所反馈的意见往往具有主观性，会对确定业务功能问题的准确性造成一定程度的影响。此外，实际应用中，在受到业务功能问题影响的用户中，可能只有部分用户会反馈意见，也就是说，反馈意见的用户并不能反映所有受到业务功能问题影响的用户，这就有可能对后续优化业务问题的过程产生影响，显然，仅依赖于用户所反馈的意见来确定业务功能的问题，局限性较大。

发明内容

本申请实施例提供一种基于日志的信息处理方法及装置，用以解决现有技术中依赖人工方式确定业务障碍点的局限性较大的问题。

本申请实施例提供的一种基于日志的信息处理方法，包括：

监测业务功能对用户发出的业务请求的响应结果；

当监测到所述响应结果为失败时，获取所述业务请求对应的各业务功能的日志；

在所述日志中，确定与该业务请求对应的日志信息；

根据所述日志信息，确定各业务功能对应的中间业务结果；

根据中间业务结果中的失败结果，生成标示有失败结果的业务图形，并展示。

本申请实施例另提供的一种基于日志的信息处理方法，包括：

获取各业务功能对应的日志；

根据获取到的各日志，确定各日志中属于同一业务的日志信息，生成各业务对应的日志信息集；

根据所述日志信息集，确定每一业务对应的业务障碍点；

根据所述业务障碍点，生成与每一业务对应的、标示有业务障碍点的业务图形，并展示。

本申请实施例另提供的一种基于日志的信息处理装置，包括：

监测模块，用于监测业务功能对用户发出的业务请求的响应结果；

日志获取模块，用于当所述监测模块监测到所述响应结果为失败时，获取所述业务请求对应的各业务功能的日志；

日志信息模块，用于在所述日志中，确定与该业务请求对应的日志信息；

确定模块，用于根据所述日志信息，确定各业务功能对应的中间业务结果；

展示处理模块，用于根据中间业务结果中的失败结果，生成标示有失败结果的业务图形，并展示。

本申请实施例另提供的一种基于日志的信息处理装置，包括：

获取模块，用于获取各业务功能对应的日志；

日志信息模块，用于根据获取到的各日志，确定各日志中属于同一业务的日志信息，生成各业务对应的日志信息集；

确定模块，用于根据所述日志信息集，确定每一业务对应的业务障碍点；

展示处理模块，用于根据所述业务障碍点，生成与每一业务对应的、标示有业务障碍点的业务图形，并展示。

本申请实施例提供一种基于日志的信息处理方法及装置，通过本方法，针对用户所发出的业务请求，服务器会监测业务功能对该业务请求进行处理后所返回的响应结果，如果响应结果为失败，那么，既有可能是业务功能本身出现的问题，也有可能是由于用户的错误操作所导致。为了直观且明确地反映出整个处理流程中出现失败的环节所在，故服务器会获取处理业务请求的各业务功能的日志，并从获取到的日志中确定出与业务请求相对应的日志信息，这些日志信息中记录了业务功能对业务请求进行处理后的处理结果(即，中间业务结果)，而失败的处理结果通常就是导致响应结果失败的原因所在，因此，也就可以根据处理结果中的失败结果，生成标示有失败结果的业务图形。与现有技术不同的是，采用本申请中业务图形的方式，能够客观且明确地显示出针对业务请求的处理过程中出现问题的环节所在，相对于现有技术中依赖于用户反馈意见的方式而言，本申请中的上述方式所展示的结果更具客观性，准确性也更高。

同时，服务器可以获取各业务功能的日志，并在各日志中，确定出同一业务所对应的日志信息集，这样一来，对于每一种业务，均可以获取到各自的日志信息集，进一步可以根据日志信息集来确定出每一种业务中的业务障碍点，并以业务图形的方式展示。根据日志信息的方式，可以准确且全面的收集到业务功能出现问题的信息，从而可以准确的反映出业务功能的问题所在，以便后续对该业务功能进行优化。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的一种基于日志的信息处理过程示意图；

图2为本申请实施例提供的账户注册业务的流程示意图；

图3a和3b为本申请实施例提供的业务图形的示意图；

图4为本申请实施例提供的另一种基于日志的信息处理过程示意图；

图5为本申请实施例提供的账户注册业务对应的业务图形的示意图。

图6为本申请实施例提供的一种基于日志的信息处理装置结构示意图；

图7为本申请实施例提供的另一种基于日志的信息处理装置的结构示意图。

具体实施方式

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

正如前述，当用户在使用在线系统所提供的业务服务的过程中，若用户受到业务功能的问题的影响而导致获取业务服务失败时，用户可能会向在线系统反馈意见，但用户所反馈的意见可能存在一定的主观性，就有可能导致难以根据用户所反馈的意见来准确确定是否是业务功能自身出现的问题，还是用户的错误操作而导致的业务服务失败。

例如：用户在某网站中，使用账户注册业务进行账户注册时，用户由于自身输入了错误的验证码，导致注册失败，假设该用户向该网站反馈“账户注册业务出错”的意见，显然，该意见具有主观性，并不能表征该网站的账户注册业务出现了问题。

基于上述情况，就需要一种能够客观且准确的方式，来确定出用户在使用业务功能的过程中，是否受到业务功能问题的影响。也即，在本申请实施例中，提供一种基于日志的信息处理方法，如图1所示。

具体地，如图1所示，该方法具体包括以下步骤：

S101：监测业务功能对用户发出的业务请求的响应结果。

在实际应用时，用户通常可以向在线系统发出相应的业务请求，以获取相应的业务服务，例如：用户在某网站内进行在线支付，那么，用户所发出的支付请求就是一种业务请求。在用户发出了业务请求后，相应的业务功能就会针对该业务请求进行处理，并在处理后，向用户返回响应结果(即，处理结果)。如上例：用户发出了支付请求后，相应的支付功能就会处理该支付请求，并返回支付成功(或支付失败)的处理结果(也即，响应结果)。

其中，所述的业务功能，就是在线系统内由不同的业务系统所提供的功能，例如：安全检测系统，可提供对操作系统的安全环境进行检测的功能；又例如：支付系统，可提供支付功能，使得用户完成在线支付等等。

业务功能所反馈的响应结果，可反映出业务功能对业务请求的处理是否成功。那么，监测该响应结果，也就可以及时获知用户的业务请求是否成功。

S102：当监测到所述响应结果为失败时，获取所述业务请求对应的各业务功能的日志。

响应结果为失败，就表明业务功能针对该业务请求的处理并未成功，响应结果为失败可能由多种原因导致，那么，就需要确定出发生失败的环节所在。

同时，考虑到实际应用中，在线系统内的各业务系统之间的关联越来越紧密，越来越多的业务由多个业务系统共同实现，例如：对于在线支付业务而言，需要页面展示系统、安全检测系统以及支付系统共同完成。也就是说，一个业务请求可能由多个业务功能进行处理。基于此，服务器就需要确定该业务请求所对应的各业务功能，并获取这些业务功能的日志。

当然，如果某个业务请求在实际处理过程中，只需要单一的业务功能便可完成，那么，服务器就只获取该业务请求对应的这一个业务功能的日志。这里并不构成对本申请的限定。

业务功能的日志中通常会记录该业务功能所执行的所有操作，包括：对不同用户的业务请求的处理、处理结果、处理时间等等，这就需要在日志所记录的大量数据中，挑选出与业务请求相关的信息，也即，执行下述步骤S103。

S103：在所述日志中，确定与该业务请求对应的日志信息。

作为本申请实施例中的一种方式，业务请求中通常会携带有诸如用户信息、业务标识、时间信息等信息，那么，便可以在日志中查找包含上述用户信息和业务标识的日志信息，再进一步根据时间信息，来筛选出该业务请求所对应的日志信息。当然，上述内容并不构成对本申请的限定。

S104：根据所述日志信息，确定各业务功能对应的中间业务结果。

在本申请实施例中，对于任一业务功能的日志信息而言，其中可包含：用户信息、业务信息、处理结果、所调用的其他业务功能ID等等。

通过日志信息，可以确定出任一业务功能对业务请求的处理结果(这些结果就是中间结果)，这样一来，便可以明确地确定出处理失败的业务功能、处理成功的业务功能。

S105：根据中间业务结果中的失败结果，生成标示有失败结果的业务图形，并展示。

在得到了中间业务结果的基础上，就可以针对上述的业务请求生成业务图形，并在业务图形上标示出处理失败的业务结果。从而，通过这样的业务图形，便可直观且明确地表示出上述业务请求的整个处理流程中出现问题的环节所在。

这里需要说明的是，上述步骤S101～S105，可由在线系统后台的服务器执行上述监测操作，具体地，可由服务器中用于收集并分析日志的业务功能实现，可以认为，该业务功能具有访问其他业务功能日志的权限，并将分析结果(即，上述的业务图形)提供给在线系统后的开发者。当然，这里并不构成对本申请的限定。

通过上述步骤，针对用户所发出的业务请求，服务器会监测业务功能对该业务请求进行处理后所返回的响应结果，如果响应结果为失败，那么，既有可能是业务功能本身出现的问题，也有可能是由于用户的错误操作所导致。为了直观且明确地反映出整个处理流程中出现失败的环节所在，故服务器会获取处理业务请求的各业务功能的日志，并从获取到的日志中确定出与业务请求相对应的日志信息，这些日志信息中记录了业务功能对业务请求进行处理后的处理结果(即，中间业务结果)，而失败的处理结果通常就是导致响应结果失败的原因所在，因此，也就可以根据处理结果中的失败结果，生成标示有失败结果的业务图形。与现有技术不同的是，采用本申请中业务图形的方式，能够客观且明确地显示出针对业务请求的处理过程中出现问题的环节所在，相对于现有技术中依赖于用户反馈意见的方式而言，本申请中的上述方式所展示的结果更具客观性，准确性也更高。

对于前述内容而言，日志信息中所记录的中间业务结果，就是各业务功能对业务请求进行处理的处理结果，故对于上述方法中的步骤S104而言，根据所述日志信息，确定该业务请求对应的中间业务结果，具体包括：根据所述日志信息，确定各业务功能针对所述业务请求的处理结果，并将所述处理结果作为所述中间业务结果。

其中，中间业务结果可包括：成功结果和失败结果。在此基础上，根据中间业务结果中的失败结果，生成标示有失败结果的业务图形，具体包括：根据所述失败结果以及成功结果，生成标示有成功结果以及失败结果的业务流程图形。

当然，作为本申请实施例中的一种方式，在实际应用时，可设置相应的检测机制，用于检测用户自身的操作是否出现错误(如：可检测用户是否输入了错误的验证码、用户名、证件号码等等)，进而，通过这样的检测机制，可以针对中间业务结果进行过滤，即，将由用户自身的错误操作而造成的失败的处理结果滤除，剩余的失败结果中，就有可能是业务自身出现的问题所导致的。当然，这里并不构成对本申请的限定。

为了能够清楚的说明如图1所示的方法，下面以用户进行账户注册的场景进行详细描述：

该场景下，用户A在某网站中发出账户注册请求(具体的表现方式可以为：用户A点击该网站中的“注册”选项，这里不作具体限定)，以便在该网站中注册账户，假设，该过程中，用户A需要填写用户名、密码、证件号码等个人信息。同时假设，账户注册业务由用户信息注册业务以及认证业务功能构成。如图2所示。

图2中示出了账户注册业务的业务流程，具体地，用户A首先使用用户信息注册业务，输入用户的个人信息，当用户A输入了自身的身份证号码后，用户信息注册业务会调用认证业务，以便对用户A所填写的身份证号码进行认证，并返回相应的认证结果，如图2所示，认证失败，从而最终反馈给用户的结果为：注册失败(即，响应结果)。

基于图2所示的业务流程，在此假设两种情况：

第一种情况，用户A由于自身输入错误，导致认证业务反馈认证失败的处理结果。在此情况下，服务器就会分别获取用户信息注册业务以及认证业务对应的日志，并确定出用户A的注册请求的日志信息，通过日志信息便可获知认证业务的处理结果为：失败。如果设置了相应的检测机制，就可以检测出此次的失败结果是由用户自身输入错误所导致的。所以，生成的业务流程图形可如图3a所示。

第二种情况，用户A输入的个人信息均正确，认证业务针对身份证号码的认证功能出现问题，在该情况下，服务器会执行上述操作，与前一种情况不同的是，此次的失败结果是由于认证业务中的业务功能出现问题所导致的，故生成的业务流程图形如图3b所示。

从本示例中可见，通过本申请中的上述方法，可以直观且准确地得到标示有处理结果的业务流程图形，便于确定出业务功能出现问题的环节所在。

基于上述内容，需要说明的是，本申请实施例中的一种应用场景下，通过上述方法所得到的业务图形可以提供给在线系统后台的客服人员，也即，在该场景下，若用户在在线系统中发出了业务请求但并未成功相应的业务服务，用户使用在线系统中的客服系统进行咨询，此时，为该用户提供咨询服务的客服人员便可以查看用户的业务请求所对应的业务图形，这样一来，通过该业务图形，是的客服人员可以直观地浏览到业务流程中出现问题的环节，并基于此为用户进行咨询服务。

在另一种应用场景下，可以将上述的业务图形提供给用户，以便向用户展示业务功能中出现问题的环节。当然，上述的两种场景均不构成对本申请的限定。

除了上述针对用户的业务请求所生成的业务图形的方式之外，考虑到实际应用中，即使业务功能出现了问题，导致用户不能顺利获得相应的业务服务，但通常也只会有部分用户反馈意见，难以真实地反映出受到影响的用户的数量，那么，就可能会对出现问题的业务功能进行优化的过程产生一定程度的影响，例如：假设某一业务功能出现问题，已影响了大量用户的正常使用，但由于反馈意见的用户数量较少，使得在线系统后台针对该业务功能的评估结果为：不进行优化。显然，在不能及时进行优化的情况下，将严重影响业务功能的正常运行。

基于此，在本申请实施例中，还提供一种基于日志的信息处理方法，如图4所示。与前述如图1所示的方法类似，图4中的方法也可由服务器执行。具体地，图4中，所述方法具体包括如下步骤：

S401：获取各业务功能对应的日志。

每一业务功能在运行过程中，均会生成各自的日志。不同业务功能的日志中，记录了该业务功能所处理的业务请求、业务结果、用户信息、时间信息等。这里并不作具体限定。

在本申请实施例的一种方式中，服务器可以获取在线系统后台所有的业务功能所对应的日志。当然，在另一种方式中，服务器可以根据实际应用的需要，只获取某些业务功能所对应的日志。上述方式并不构成对本申请的限定。

S402：根据获取到的各日志，确定各日志中属于同一业务的日志信息，生成各业务对应的日志信息集。

需要说明的是，一种业务可能需要多种业务功能共同实现，这里可以认为，一种业务能够为用户提供一种业务服务，例如：账户注册业务，可以面向用户提供账户注册服务，而账户注册业务又是由用户信息注册功能和认证功能共同实现的。

各业务功能的日志当中，包含了多种业务的日志信息，举例来说：认证功能的日志中，记录了对证件号码进行认证的日志信息、对银行卡号进行认证的日志信息，其中，对证件号码进行认证的日志信息属于账户注册业务，而对银行卡号进行认证的日志信息可能属于在线支付业务。可见，业务功能的日志中，记录了不同业务的日志信息。

那么，就可以从各日志中，确定出属于同一业务的日志信息集。

S403：根据所述日志信息集，确定每一业务对应的业务障碍点。

针对于同一业务而言，日志信息集中记录了不同用户的业务请求的处理结果，那么，也就可以根据这些处理结果，确定出该业务出现问题的环节(即，业务障碍点)。例如：假设对于账户注册业务而言，该账户注册业务的日志信息集中，记录了大量用户在进行身份证号码认证时的失败结果，那么，就表明账户注册业务中，身份证号码认证这一环节可能出现了问题(即，身份证号码认证可能就是账户注册业务的业务障碍点)。

S404：根据所述业务障碍点，生成与每一业务对应的、标示有业务障碍点的业务图形，并展示。

与前述方法类似，在确定出了每一业务的业务障碍点之后，便可以针对每一业务，生成该业务的业务图形，并在该业务图形中标示出相应的业务障碍点，从而，可以明确且直观地展示出某一业务中出现问题的环节所在。不同的是，如图4所示的方法中所得到的业务图形，反映了某一业务的业务障碍点，而不是针对每一用户所生成的业务图形。当然，这里并不构成对本申请的限定。

通过上述步骤，服务器可以获取各业务功能的日志，并在各日志中，确定出同一业务所对应的日志信息集，这样一来，对于每一种业务，均可以获取到各自的日志信息集，进一步可以根据日志信息集来确定出每一种业务中的业务障碍点，并以业务图形的方式展示。根据日志信息的方式，可以准确且全面的收集到业务功能出现问题的信息，从而可以准确的反映出业务功能的问题所在，以便后续对该业务功能进行优化。

在本申请实施例中的一种方式下，对于上述步骤S401而言，获取各业务功能对应的日志，具体包括：获取设定时间段内各业务功能对应的日志。例如：获取一天之内的各业务功能对应的日志、获取一周内的各业务功能对应的日志等等。

在实际应用中，某些业务可能由单一的业务功能即可实现，在此情况下，根据获取到的各日志，确定各日志中属于同一业务的日志信息，具体包括：针对任一业务功能所对应的日志，确定该日志中含有相同业务标识的日志信息，将确定出的所述日志信息作为属于同一业务的日志信息。

相应地，某些业务需要由多种业务功能实现，在此情况下，根据获取到的各日志，确定各日志中属于同一业务的日志信息，具体包括：在所述各业务功能对应的各日志中，确定具有调用关系的各日志信息，将具有调用关系的所述各日志信息，确定为同一业务的日志信息。

此外，需要说明的是，根据所述日志信息集，确定每一业务对应的业务障碍点，具体包括：针对任一业务所对应的日志信息集，确定该日志信息集中包含的各用户信息，以及与各用户信息对应的业务结果，其中，所述业务结果包括失败结果和成功结果；统计出现过失败结果的用户信息的数量，根据预设的阈值，将用户信息的数量超过所述阈值的失败结果，确定为所述业务障碍点。

举例而言：仍以账户注册业务为例，服务器会分别获取用户信息注册功能和认证功能的日志，并确定出账户注册业务对应的日志信息集。并根据日志信息集，确定出如下信息：

身份证号码认证这一环节出现问题的用户量为2000；

驾驶证号码认证这一环节出现问题的用户量为200；

军官证号码认证这一环节出现问题的用户量为8；

验证码认证这一环节出现问题的用户量为800。

并假设，在线系统中，针对证件号码进行认证的阈值为500(该阈值表示可接受认证过程中出错的数量)。显然，身份证号码认证和验证码认证这两个环节出现了问题。所以，生成如图5所示的业务图形。

从上例中可见，通过如图4所示的方法所生成的业务图形，是某业务所对应的完整的业务流程图形，同时，根据该业务对应的日志信息集(日志信息集源于使用过该业务的所有用户，可以认为，数据量足够充分)，来确定出业务流程中出现了问题的环节(即，业务障碍点)，具有较高的直观性和客观性。

需要说明的是，本申请实施例中的一种应用场景下，通过上述方法所得到的业务图形可以提供给在线系统后台的开发人员，以便开发人员对业务功能进行优化。这里并不构成对本申请的限定。

以上为本申请实施例提供的基于日志的信息处理方法，基于同样的思路，本申请实施例还提供一种基于日志的信息处理装置。

如图6所示，基于日志的信息处理装置包括：

监测模块601，用于监测业务功能对用户发出的业务请求的响应结果。

日志获取模块602，用于当所述监测模块监测到所述响应结果为失败时，获取所述业务请求对应的各业务功能的日志。

日志信息模块603，用于在所述日志中，确定与该业务请求对应的日志信息。

确定模块604，用于根据所述日志信息，确定各业务功能对应的中间业务结果。

展示处理模块605，用于根据中间业务结果中的失败结果，生成标示有失败结果的业务图形，并展示。

作为本申请实施例中的一种方式，确定模块604，具体用于根据所述日志信息，确定各业务功能针对所述业务请求的处理结果，并将所述处理结果作为所述中间业务结果。

其中，中间业务结果包括成功结果和失败结果。基于此，展示处理模块605，具体用于根据所述失败结果以及成功结果，生成标示有成功结果以及失败结果的业务流程图形。

相应地，在本申请实施例中，还提供一种基于日志的信息处理装置，如图7所示。所述装置包括：

获取模块701，用于获取各业务功能对应的日志；

日志信息模块702，用于根据获取到的各日志，确定各日志中属于同一业务的日志信息，生成各业务对应的日志信息集；

确定模块703，用于根据所述日志信息集，确定每一业务对应的业务障碍点；

展示处理模块704，用于根据所述业务障碍点，生成与每一业务对应的、标示有业务障碍点的业务图形，并展示。

在本申请实施例中的一种方式中，获取模块701，具体用于获取设定时间段内各业务功能对应的日志。

在一种场景下，日志信息模块702，具体用于针对任一业务功能所对应的日志，确定该日志中含有相同业务标识的日志信息，将确定出的所述日志信息作为属于同一业务的日志信息。

此外，在另一种场景下，日志信息模块702，具体用于在所述各业务功能对应的各日志中，确定具有调用关系的各日志信息，将具有调用关系的所述各日志信息，确定为同一业务的日志信息。

确定模块703，具体用于针对任一业务所对应的日志信息集，确定该日志信息集中包含的各用户信息，以及与各用户信息对应的业务结果，其中，所述业务结果包括失败结果和成功结果；统计出现过失败结果的用户信息的数量，根据预设的阈值，将用户信息的数量超过所述阈值的失败结果，确定为所述业务障碍点。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (16)

1.一种基于日志的信息处理方法，其特征在于，包括：

监测业务功能对用户发出的业务请求的响应结果；

当监测到所述响应结果为失败时，获取所述业务请求对应的各业务功能的日志；

在所述日志中，确定与该业务请求对应的日志信息；

根据所述日志信息，确定各业务功能对应的中间业务结果；

根据中间业务结果中的失败结果，生成标示有失败结果的业务图形，并展示。

2.如权利要求1所述的方法，其特征在于，根据所述日志信息，确定该业务请求对应的中间业务结果，具体包括：

根据所述日志信息，确定各业务功能针对所述业务请求的处理结果，并将所述处理结果作为所述中间业务结果。

3.如权利要求1所述的方法，其特征在于，所述中间业务结果包括成功结果和失败结果；

根据中间业务结果中的失败结果，生成标示有失败结果的业务图形，具体包括：

根据所述失败结果以及成功结果，生成标示有成功结果以及失败结果的业务流程图形。

4.一种基于日志的信息处理方法，其特征在于，包括：

获取各业务功能对应的日志；

根据获取到的各日志，确定各日志中属于同一业务的日志信息，生成各业务对应的日志信息集；

根据所述日志信息集，确定每一业务对应的业务障碍点；

根据所述业务障碍点，生成与每一业务对应的、标示有业务障碍点的业务图形，并展示。

5.如权利要求4所述的方法，其特征在于，获取各业务功能对应的日志，具体包括：

获取设定时间段内各业务功能对应的日志。

6.如权利要求4所述的方法，其特征在于，根据获取到的各日志，确定各日志中属于同一业务的日志信息，具体包括：

针对任一业务功能所对应的日志，确定该日志中含有相同业务标识的日志信息；

将确定出的所述日志信息作为属于同一业务的日志信息。

7.如权利要求4所述的方法，其特征在于，根据获取到的各日志，确定各日志中属于同一业务的日志信息，具体包括：

在所述各业务功能对应的各日志中，确定具有调用关系的各日志信息；

将具有调用关系的所述各日志信息，确定为同一业务的日志信息。

8.如权利要求4所述的方法，其特征在于，根据所述日志信息集，确定每一业务对应的业务障碍点，具体包括：

针对任一业务所对应的日志信息集，确定该日志信息集中包含的各用户信息，以及与各用户信息对应的业务结果，其中，所述业务结果包括失败结果和成功结果；

统计出现过失败结果的用户信息的数量；

根据预设的阈值，将用户信息的数量超过所述阈值的失败结果，确定为所述业务障碍点。

9.一种基于日志的信息处理装置，其特征在于，包括：

监测模块，用于监测业务功能对用户发出的业务请求的响应结果；

日志获取模块，用于当所述监测模块监测到所述响应结果为失败时，获取所述业务请求对应的各业务功能的日志；

日志信息模块，用于在所述日志中，确定与该业务请求对应的日志信息；

确定模块，用于根据所述日志信息，确定各业务功能对应的中间业务结果；

展示处理模块，用于根据中间业务结果中的失败结果，生成标示有失败结果的业务图形，并展示。

10.如权利要求9所述的装置，其特征在于，所述确定模块，具体用于根据所述日志信息，确定各业务功能针对所述业务请求的处理结果，并将所述处理结果作为所述中间业务结果。

11.如权利要求9所述的装置，其特征在于，所述中间业务结果包括成功结果和失败结果；所述展示处理模块，具体用于根据所述失败结果以及成功结果，生成标示有成功结果以及失败结果的业务流程图形。

12.一种基于日志的信息处理装置，其特征在于，包括：

获取模块，用于获取各业务功能对应的日志；

日志信息模块，用于根据获取到的各日志，确定各日志中属于同一业务的日志信息，生成各业务对应的日志信息集；

确定模块，用于根据所述日志信息集，确定每一业务对应的业务障碍点；

展示处理模块，用于根据所述业务障碍点，生成与每一业务对应的、标示有业务障碍点的业务图形，并展示。

13.如权利要求12所述的装置，其特征在于，所述获取模块，具体用于获取设定时间段内各业务功能对应的日志。

14.如权利要求12所述的装置，其特征在于，所述日志信息模块，具体用于针对任一业务功能所对应的日志，确定该日志中含有相同业务标识的日志信息，将确定出的所述日志信息作为属于同一业务的日志信息。

15.如权利要求12所述的装置，其特征在于，所述日志信息模块，具体用于在所述各业务功能对应的各日志中，确定具有调用关系的各日志信息，将具有调用关系的所述各日志信息，确定为同一业务的日志信息。

16.如权利要求12所述的装置，其特征在于，所述确定模块，具体用于针对任一业务所对应的日志信息集，确定该日志信息集中包含的各用户信息，以及与各用户信息对应的业务结果，其中，所述业务结果包括失败结果和成功结果；统计出现过失败结果的用户信息的数量，根据预设的阈值，将用户信息的数量超过所述阈值的失败结果，确定为所述业务障碍点。