CN105095052A - Soa环境下的故障检测方法及装置 - Google Patents

Abstract

本申请提出一种SOA环境下的故障检测方法及装置。其中，该方法包括：获得所述第一业务的第一日志，并从所述第一日志中提取出输入数据；获得所述第二业务的第二日志，并从所述第二日志中提取出输出数据；以及将所述输入数据和所述输出数据进行比对，定位出发生故障的业务。本申请实施例的SOA环境下的故障检测方法及装置，通过从所述第一日志中提取出输入数据和从所述第二日志中提取出输出数据，并将所述输入数据和所述输出数据进行比对，定位出发生故障的业务，从而在线上有BUG的前提下，能够及时发现故障。

Description

SOA环境下的故障检测方法及装置

技术领域

本申请涉及故障检测技术领域，尤其涉及一种SOA环境下的故障检测方法及装置。

背景技术

随着计算机技术的快速发展，出现很多新的服务架构，例如，面向业务的架构(Service-OrientedArchitecture，SOA)就是一种新的服务架构，它是一种粗粒度、松耦合的服务架构，服务之间通过接口进行通讯，不涉及底层编程接口和通讯模型，因此，SOA系统能够更加从容地面对业务的急剧变化。

目前，在线上的SOA环境中，由于上线的代码都经过回归测试确保了功能没有问题，故通常假设线上环境的代码没有错误(BUG)。基于这个假设，导致系统不可用的原因就只剩下容量不足，例如系统负载过高、数据库(DB)负载过高等；物理资源异常，例如磁盘故障、机器断电、网络设备故障等，故可以采用传统的监控方式监控线上的环境。

但是，在互联网级别的SOA环境里，确保线上环境没有错误是非常困难的，具体原因包括但不局限于以下几点：

(1)在互联网级别的SOA环境里，量变导致质变的场景很多，需要投入大量的代码来做异常情况的容错和恢复，比如DB(Database)挂了，应用要自动切换(failover)，网络异常套接字(socket)要断线重连，主机(master)挂了,要重新选举，吞吐量过大,要缓冲排队等等，这些逻辑在各种异常输入的场景下无法保证互相配合没有BUG，尤其在业务量大增的情况下无法保证没有BUG。

(2)大部分系统都有后台的管理、规则的配置、动态的调控，这些需要高级管理员、运营、运维人员进行操作，这些操作用例即使全部被测试100％覆盖，也难以杜绝人为误操作。

(3)即使自身没有BUG，但无法保证合作的第三方没有BUG，例如支付宝下游的各大银行，他们的BUG会影响到支付宝的业务成功率。

(4)不是所有的容量问题都能通过物理机的性能指标，例如负载(LOAD)来发现，并且可能存在噪声和盲点。

由此可见，上述假设不能成立。当上述假设不成立时，传统的监控方式就无法检测故障。

另外，在传统的监控方案中，运维人员每天都要收取大量的报警，少则几百，多则几千，在这样规模的报警下，报警已经丧失了本身的价值。而公有云的机器故障其实都是可以自动化恢复的，但是运维人员却不敢取消报警——因为他并不知道在机器自动恢复之后，程序是否恢复正常，没有一个指标告诉运维人员业务和服务的健康状态，而误报、滥报、漏报都可能会影响监控效果。

因此，迫切需要提供一种故障检测方法，在线上有BUG的前提下，能够及时发现故障并找到故障原因。

发明内容

本申请旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本申请的第一个目的在于提出一种SOA环境下的故障检测方法，该方法在线上有BUG的前提下，能够及时发现故障。

本申请的第二个目的在于提出一种SOA环境下的故障检测装置。

为达上述目的，本申请第一方面实施例提出了一种SOA环境下的故障检测方法，所述SOA环境包括位于同一业务链的第一业务和第二业务，且所述第一业务位于所述业务链的起点，所述第二业务位于所述业务链的终点，所述方法包括：获得所述第一业务的第一日志，并从所述第一日志中提取出输入数据；获得所述第二业务的第二日志，并从所述第二日志中提取出输出数据；以及将所述输入数据和所述输出数据进行比对，定位出发生故障的业务。

本申请实施例的SOA环境下的故障检测方法，通过从第一日志中提取出输入数据和从第二日志中提取出输出数据，并将输入数据和输出数据进行比对，定位出发生故障的业务，从而在线上有BUG的前提下，能够及时发现故障。

为达上述目的，本申请第二方面实施例提出了一种SOA环境下的故障检测装置，所述SOA环境包括位于同一业务链的第一业务和第二业务，且所述第一业务位于所述业务链的起点，所述第二业务位于所述业务链的终点，所述装置包括：第一提取模块，用于获得所述第一业务的第一日志，并从所述第一日志中提取出输入数据；第二提取模块，用于获得所述第二业务的第二日志，并从所述第二日志中提取出输出数据；以及第一定位模块，用于将所述第一提取模块提取出的所述输入数据和所述第二提取模块提取出的所述输出数据进行比对，定位出发生故障的业务。

本申请实施例的SOA环境下的故障检测装置，通过第一提取模块从第一日志中提取出输入数据和通过第二提取模块从第二日志中提取出输出数据，并通过第一定位模块将输入数据和输出数据进行比对，定位出发生故障的业务，从而在线上有BUG的前提下，能够及时发现故障。

附图说明

图1是本申请一个实施例的SOA环境的结构示意图。

图2是本申请一个实施例的SOA环境下的故障检测方法的流程图。

图3是本申请一个实施例的获取输入和输出的示意图。

图4是本申请一个实施例的用于推断业务是否正常的报表的示意图。

图5是本申请一个实施例的预期输出和实际输出的对比曲线的示意图。

图6是本申请一个实施例的确定故障原因的流程图。

图7是本申请一个实施例的确定故障原因的示意图。

图8是本申请一个实施例的异常日志的示意图。

图9是本申请另一个实施例的异常日志的示意图。

图10是本申请一个实施例的SOA环境下的故障检测装置的结构示意图。

具体实施方式

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

目前，针对线下单机环境，可以通过单元测试、调试(debug)、查看日志、卸出(dump)内存等方式，检测出环境故障。但线上SOA环境和线下单机环境完全不同，线上SOA环境包括多种业务，每种业务对应一个集群系统(cluster)，而每个集群系统由多个系统组成，

如图1所示。具体地，从故障排查的角度看，二者的区别如表1所示：

表1线上SOA环境和线下单机环境的区别

由此可见，线上SOA环境和线下环境的差别主要体现在以下两个方面：

首先是安全、条件等因素。线下很多可以做的操作，在线上是禁止的，例如debug、从DB中取数据(很多测试用例都会从DB中取数据作为输出校验)、dump(线上的dump会影响性能)、日志操作(曾经有运维人员对一个重要系统的日志执行了VI(Visualinterface，VI编辑器)操作导致严重故障)等等。

其次体现在量变导致质变上。机器的数量从1个变为成千上万，要考虑的依赖关系从内部的模块变成了成百上千个集群之间错综复杂的业务。换言之，可以对单机的程序做debug，但即使有一万个工程师能够同时对线上的一万台机器(即服务器)做debug，也很难将各自的分析结果汇总聚合输出有价值的信息。

所以在SOA的分布式环境下，检测故障的难点在于：

1)单机上的经验很难简单地复用，由于SOA系统对侵入性的不可容忍，所以debug、dump等分析方式都无法施行。即使是日志分析也要小心翼翼不能耗费CPU、内存资源。

2)机器数量众多，依赖关系复杂，导致关键的数据容易被淹没。例如在发生故障时，不知从几万台机器中的哪一台来查看指标，也不知道选择哪些系统来分析故障原因。

综上所述，单机指标数据难以直接参考，比如我们希望确认当前的关键业务有无故障，但是单机上仅仅能够推断出此台机器的业务量，无法得知整个SOA环境的业务健康状况。在单机发现一个异常的指标时也难以推断它是故障根源还是受害者。在单机上分析出一种故障行为时也难以判断它是单机特例还是集群的普遍现象。针对上述情况，本申请实施例利用日志来实现和线下单机环境检测效果类似的故障检测方案。

下面参考附图描述本申请实施例的SOA环境下的故障检测方法及装置。

图2是本申请一个实施例的SOA环境下的故障检测方法的流程图，在该实施例中，SOA环境包括位于同一业务链的第一业务和第二业务，且第一业务位于业务链的起点，第二业务位于业务链的终点，如图2所示，该方法包括：

S201，获得第一业务的第一日志，并从第一日志中提取出输入数据。

从第一日志中提取出输入数据可以为：根据第一日志获得匹配的第一日志模型，使用第一日志模型从第一日志中提取出输入数据，其中，该第一日志模型包括解析规则，还可以包括解析权限等信息。

S202，获得第二业务的第二日志，并从第二日志中提取出输出数据。

在线下单机环境，利用测试用例来检查是否存在故障，其本质是将输入和输出进行比对，也就是为其能够提供的业务全部准备一个测试用例，模拟(mock)它的输入，检查输出和预期是否相符。它的输出可以从DB等各种渠道获取，即使在非自动化场景下，也可以用肉眼检查输出内容。线上SOA环境可以模仿线下单机环境的检测方法，因此，需要找到自己的输入和输出。如图3所示，输入包括用户的操作，例如浏览网页、提交表单等，也可能包括系统行为，例如淘宝调用支付宝进行付款操作，则在入口处记录下日志即第一日志，从第一日志中提出数据作为输入数据；另外，在第二业务结束后输出第二日志，从第二日志中提出数据作为输出数据。

其中，第一日志和第二日志的粒度相同。从第二日志中提取出输入数据可以为：根据第二日志获得匹配的第二日志模型，使用第二日志模型从第二日志中提取出输入数据，其中，该第二日志模型包括解析规则，还可以包括解析权限等信息。

S203，将输入数据和输出数据进行比对，定位出发生故障的业务。

找到输入数据和输出数据后就可以进行分析统计，输出如图4所示的报表，通过该报表即可推断业务是否正常。

具体地，报表中曲线a代表用户的输入，曲线b代表业务输出，用户的输入即可理解为“输入数据”，例如，在某个时刻有1000个用户提交了“下单”表单，那在一切正常的情况下就应该产出1000笔下单业务，图4中箭头所指位置很可能发生异常，因为用户的行为(输入)在增多，而成功的业务(输出)却有所下降，这可能预示着某些用户经过多次重试才完成操作。

然而，随着业务的日趋复杂，很难保证第一日志和第二日志完全一一匹配，具体原因是：SOA业务的特点是下游业务稳态、通用，上游业务灵活应变，再加上日志本身就不严谨，输入输出很难保证严格匹配。而且让检测人员花费巨大的精力去梳理错综复杂的业务链路，找到每种业务的入口和出口也是一项繁重的工作，尤其是那些正处于发展阶段、变更频繁的业务，更是如此。

所以，一个改进的方案就是放弃“输入数据”，只在下游业务覆盖出口处的日志(越下游越稳态)，即只需要第二日志的数据。然后对它们的历史数据做线性回归，预测未来的数值(作为预期输出)，再与实际输出进行对比，定位出发生故障的业务。具体地，获得第二业务在当前时间的当前第二日志，从当前第二日志中提取出实际输出；获得第二业务自当前时间起预定时间段内的历史第二日志，从历史第二日志中提取出数据，对提取出的数据进行线性回归处理，将处理结果作为预期输出，若预期输出和实际输出一致，则无故障，若二者不一致，则位于该业务链上的业务均有故障。其中，上述预定时间段可根据需要动态调整，例如可以为3周-8周，优选地为5周，还可以为其他数值。例如，获得A业务在今天的业务量为10000；获得A业务过去五周的业务量，对过去五周的业务量做线性回归，获得预期业务量为10000；二者一致，则确定A业务正常。

如图5所示，曲线c是实际输出业务量，曲线d是根据历史数据做线性回归预测的量(俗称基线，预期输出)。这种解决方案比较适合有规律的业务(比如电子商务的交易量，是一种与用户作息规律匹配的稳态曲线，白天量大、夜里量少)。在实际场景中，绝大部分业务都是有规律的(比如“打车软件”在接近上下班高峰期时业务量会明显上涨)。规律不明显的业务主要有两种，一种是“成长中”的业务，用户刚刚开始接触，还没有形成稳态的用户群体和使用习惯，甚至业务量极少，不适合作为线性回归算法的输入；另一种是非用户行为，比如系统自动执行的后台任务。对于这种少数场景，可以有针对性的用阈值、分时间段检测等方案来弥补。

至此，我们已经可以证明利用日志能够在线上SOA生产环境中实现和线下单元测试接近的检测效果，随着业务点覆盖的全面，就越能保障绝大部分故障都能够被及时有效的发现。至于工作量，其实等量于上文多次提到的测试用例。理论上，回归测试时的用例其实就是要覆盖所有的业务点，甚至是一一对应的关系。所以理想场景下，有N个回归测试用例，就应该有N个对应的业务点需要覆盖监控。

本申请实施例在定位出发生故障的业务之后，还需要确定故障原因，如图6所示，确定故障原因的过程包括：

S601，自动获取每个发生故障的业务的调试日志。

其中，自动获取每个发生故障的业务的调试日志包括：自动获取每个发生故障的业务所包含的服务器的调试日志，该调试日志的粒度小于上述第一日志和第二日志的粒度。

S602，对自动获取的所有调试日志进行聚合处理，定位出故障原因。

对调试日志进行聚合处理，可以确定发生故障的服务器，另外，可以获得对应每个发生故障的业务的日志分析结果，对日志分析结果进行聚合递归分析，确定出故障源，即确定出真正发生故障的业务。

通常情况下，线下单机环境通过debug可以非常轻松地发现故障原因，那是因为在debug时可以跟随每一行代码逐步运行，能够检查每一行代码的输入和输出是否符合预期，比如调用一个函数时，可以在debug过程中检查传入的参数是否符合预期，函数的返回值是否符合预期，以此来定位故障是否发生在函数内部。

为了达到接近于debug的效果，在本实施例中，可以模仿线下的debug过程，例如，可以在每个函数的开始位置用日志输出它接收到的参数内容，在结束位置用日志输出对应函数返回的结果，通过检查日志，可以定位到哪个函数出现了问题。

具体地，以以下一段代码为例描述通过日志定位故障原因的过程：

上述代码的日志输出结果为：

add函数调用开始，参数：[3,4]

add函数调用结束，result＝7

square函数调用开始，参数：[7]

square函数调用结束，result＝14

需要说明的是，上述内容仅为日志的部分内容，通过对输入参数[7]和输出result＝[14]的检查，可以定位出bug出现在square函数的调用环节，虽然该定位过程不如debug方便直观，但是日志中的信息也足够定位出故障。并且，这种日志记录的粒度越细(即粒度由粗到细依次为：系统>模块>函数>代码)，能够定位的异常点就越准确(在一个函数内部还可以将代码分为多个部分(part)，通过检查每个part的输入和输出，就能确定每个part是否出现异常)，分析的难度也就越大(日志量太大)。

另外，在现实的场景中，还可以提供debug日志开关机制，即设置输出调试日志的开关按钮，以开启或关闭输出调试日志的功能。具体地，在特殊情况下需要动态控制线上是否输出细粒度的debug日志，以用于排查故障原因(平常情况下为了避免输出过多的日志而关闭)。Log4j等日志框架也都提供了debug输出模式。

如果能将人工在单机上的分析过程翻译为程序对几万台机器的自动化分析过程，即将人工分析的过程转换为自动分析的过程，可以大大提高处理的效率，并且实现并不难(就是通过各种匹配规则、统计规则、关联规则来实现)，然后，对单机分析结果进行聚合，就可以定位出故障原因。

如图7所示，A1、A2、A3代表集群系统A的各台服务器，A、B、C是SOA环境里的三个集群系统。对单机分析结果的聚合最常发生在以下两个场景：

1)将服务器的分析结果聚合为集群系统的分析结果

对集群系统内各台服务器的聚合，其实就是对单机的分析结果进行汇总统计，比如汇总得到：

A1、A2、A3三个服务器上通过日志都推断出目前的故障模块是在调用M函数时发生异常(M函数十分可能是故障源，假如M函数都是在访问某个分布式缓存，那么分布式缓存的嫌疑就很大)；或者

A1、A2日志分析结果一切正常，但是A3的N函数处发生异常(N函数可能是故障发生点，但也有可能仅仅是A3这台机器的单机现象，比如分布式缓存没有问题，但是A3单机的网络连接断开了)。

2)将各个集群系统(简称集群)的分析结果聚合为整个链路、甚至整个SOA环境的分析结果

集群之间的聚合其实就是结合集群之间的服务依赖关系，递归的处理整个链路的日志分析结果。

比如A的分析结果是在调用xxx函数时异常，xxx函数是调用B系统的yyy服务；B的分析结果是在自身yyy服务处理中发生异常，而异常发生的环节是调用C系统的zzz服务；C的分析结果是在自身zzz服务处理中发生异常，异常发生的环节是执行某个结构化查询语言(SQL)语句时获取不到数据源连接(connection)；于是大致推断C系统与DB之间的connection有问题，接下来需要详细检查DB当前的各项指标、C系统的数据源配置是否正常等等，而系统A和B仅仅是受害者，即系统A和B因调用C，故出现故障。

上述方式虽然可以定位出故障原因，但在实现的过程中会存在两个问题：首先是日志量过大造成的输入或输出(I/O)性能损耗；其次是各系统不一定都能严格遵循日志规范，尤其在大型SOA环境中，经常会出现日志的不规范、不合理、不输出，导致排查线索缺失。

针对第一个问题，本申请实施例可以通过日志框架(中间件)代为执行通用的日志输出，以降低I/O性能损耗。日志框架能够覆盖的环节包括：跨系统RPC服务调用、消息收发、访问DB、访问缓存等。这些环节已经足够定位到粗粒度的故障源；而且日志框架还可以加入追踪标识(traceid)等内容来帮助更加精准的日志分析，如果日志中包含了traceid等标识，通过traceid可以将某一笔业务从头到尾串联起来，就能明确地看出这笔业务流经了哪些系统、服务、DB和缓存，以及它在每一个环节的耗时和成败，从而可以推导出故障源。

另外，本申请实施例可以通过输出异常(ERROR)日志的方式来解决第一个问题和第二个问题。当输出的正常日志太多时，可以选择输出异常日志，但有一个重要的前提：所有的异常都必须能被捕获、被有效的传递。以下代码是不能容忍的：

上述代码要么丢失了底层重要的异常(exception)信息、要么用无关痛痒的文案代替了重要的exception、要么直接吞掉了异常。这些都是导致异常信息丢失、传递失效的恶劣编码行为。即使我们不知道b.yyy()和c.zzz()到底会抛出何种异常，也要负责任地立刻处理掉，或者无损往上传递，很有可能exception中就带有“socketconnectiontimeoutto192.168.1.1”这样重要的异常信息。

由此可见，采用异常日志的方式可以大大降低日志输出编码成本，日志的输出量更是下降了好几个数量级，由于ERROR日志远远小于正常日志，而且即使ERROR日志数量飙升，也可以采样分析，足以提供参考。

下面以ERROR日志作为数据源，描述找到故障源的过程：首先，对所有集群的异常日志进行分析、排序；其次，从异常日志中提取出异常信息，推导出故障源。

具体地，如图8所示，排名第一的poscore集群的异常主要是“服务化接口出现未知错误”，另外，从异常日志中还提炼出了IP(由于安全问题这里不便展示)以及“katongprod”、“katongprodsign”等集群的名称，于是可进一步递归查看这些可能的“故障源”：从图9可以看出katongprod与甲骨文(oracle)的connection出现了问题，导致了Java数据库连接(JDBC)执行SQL时的异常，从而导致了整条链路处理业务的失败。而排名第一的poscore集群只是受害者。

由此可见，通过异常的调试日志来确定故障源，可以大大降低日志的数量，提高检测的效率。

需要说明的是，在定位出发生故障的业务之后，可以发送报警信息，在找到故障原因之后，也可以发送报警信息；但为了减少报警信息的数量，可以取消“找到故障原因”环节的报警，即系统ERROR升高、远程过程调用协议(RPC)链路耗时升高、LOAD升高、磁盘故障这些都可以不用发送报警信息。其根本原因在于“故障”一词的定义，本申请实施例中“故障”的定义是“业务受到影响、用户无法正常完成业务的行为”。和这种定义吻合的正是本申请实施例中提出的粗粒度(即业务粒度)的故障检测。在业务点故障检测100％覆盖的前提下，公有云里的LOAD、CPU、磁盘、网络都可以不发送报警，因为如果它们影响了业务，那业务点故障检测自然会报警，不需要它们发送报警信息；如果它们没有影响业务(被弹性调度自动修复)，那就更没有必要发送报警信息。但是，不报警不代表可以舍弃，依然需要这些数据来和链路分析、ERROR分析的结果做关联配合，例如图9对应的实施例中katongprod的ERROR日志透露出oracle有异常，此时如果物理资源监控产品里也展示出这个oracle的CPU出现明显波动，那就可以互相佐证各自的监控效果。

通过上述过程，可以将线下单机测试时证明可行的方案实施到线上，让SOA环境也具备自动发现故障、定位故障原因的能力。

上述SOA环境下的故障检测方法，通过从第一日志中提取出输入数据和从第二日志中提取出输出数据，并将输入数据和输出数据进行比对，定位出发生故障的业务，从而在线上有BUG的前提下，能够及时发现故障。

为了实现上述实施例，本申请还提出一种SOA环境下的故障检测装置。

图10是本申请一个实施例的SOA环境下的故障检测装置的结构示意图，在该实施例中，上述SOA环境包括位于同一业务链的第一业务和第二业务，且上述第一业务位于上述业务链的起点，上述第二业务位于上述业务链的终点，上述装置包括：第一提取模块11、第二提取模块12和第一定位模块13，其中：

第一提取模块11用于获得上述第一业务的第一日志，并从上述第一日志中提取出输入数据；第二提取模块12用于获得上述第二业务的第二日志，并从上述第二日志中提取出输出数据；第一定位模块13用于将上述第一提取模块11提取出的上述输入数据和上述第二提取模块12提取出的上述输出数据进行比对，定位出发生故障的业务。

具体地，上述第一提取模块11可以用于：根据上述第一日志获得匹配的第一日志模型，使用上述第一日志模型从上述第一日志中提取出上述输入数据；上述第二提取模块12可以用于：根据上述第二日志获得匹配的第二日志模型，使用上述第二日志模型从上述第二日志中提取出上述输出数据。其中，上述第一日志和上述第二日志的粒度相同，上述第一日志模型和上述第二日志模型可以包括解析规则，还可以包括解析权限等信息。

为了克服在第一日志和第二日志不匹配的情况下，无法准确地定位发生故障的业务的问题，上述第一定位模块，还用于：根据上述第二日志获得上述第二业务的预期输出和实际输出，将上述预期输出和上述实际输出进行比对，定位出发生故障的业务。具体地，第一定位模块13可以用于获得上述第二业务在当前时间的当前第二日志，从上述当前第二日志中提取出实际输出；获得上述第二业务自上述当前时间起预定时间段内的历史第二日志，从上述历史第二日志中提取出数据，对提取出的数据进行线性回归处理，将处理结果作为预期输出。

为了让用户可以及时地获知哪些业务发生了故障，该装置还可以包括：报警模块14，该报警模块14用于在上述第一定位模块13定位出发生故障的业务之后，发送报警信息。

另外，在定位出发生故障的业务之后，还需要确定故障原因，因此，该装置还可以包括：第二定位模块15，该第二定位模块15用于：在上述第一定位模块13定位出发生故障的业务之后，自动获取每个发生故障的业务的调试日志，对自动获取的所有调试日志进行聚合处理，定位出故障原因。

具体地，第二定位模块15具体用于：自动获取每个发生故障的业务所包含的服务器的调试日志，对上述调试日志进行聚合处理，确定发生故障的服务器，其中，上述调试日志的粒度小于上述第一日志和上述第二日志的粒度；也可以用于：获得对应每个发生故障的业务的日志分析结果，对上述日志分析结果进行聚合递归分析，确定出故障源。

为了控制是否输出调试日志，该装置还可以包括：设置模块10，该设置模块10用于：在上述第一提取模块11自动获取每个发生故障的业务的调试日志之前，设置输出上述调试日志的开关按钮。

另外，为了避免因日志量过大造成的输入或输出(I/O)性能损耗，该第二定位模块15可以用于：通过日志框架自动获取每个发生故障的业务所包含的服务器的调试日志。为了进一步定位出更细粒度的故障源，还可以在调试日志中增加标识，例如追踪标识(traceid)，通过traceid可以将某一笔业务从头到尾串联起来，就能明确地看出这笔业务流经了哪些系统、服务、DB和缓存，以及它在每一个环节的耗时和成败，从而可以推导出故障源。

进一步地，为了避免因日志量过大造成的输入或输出(I/O)性能损耗以及日志不规范的问题，该实施例可以采用仅输出异常日志，例如异常的调试日志，并通过异常的调试日志来确定故障源，从而可以大大降低日志的数量，提高检测的效率。

上述装置，通过将线下单机测试时证明可行的方案实施到线上，让SOA环境也具备自动发现故障、定位故障原因的能力，且具有较高的检测效率。

上述SOA环境下的故障检测装置，通过第一提取模块从第一日志中提取出输入数据和通过第二提取模块从第二日志中提取出输出数据，并通过第一定位模块将输入数据和上述输出数据进行比对，定位出发生故障的业务，从而在线上有BUG的前提下，能够及时发现故障。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (20)

1.一种SOA环境下的故障检测方法，其特征在于，所述SOA环境包括位于同一业务链的第一业务和第二业务，且所述第一业务位于所述业务链的起点，所述第二业务位于所述业务链的终点，所述方法包括：

获得所述第一业务的第一日志，并从所述第一日志中提取出输入数据；

获得所述第二业务的第二日志，并从所述第二日志中提取出输出数据；以及

将所述输入数据和所述输出数据进行比对，定位出发生故障的业务。

2.根据权利要求1所述的方法，其特征在于，所述从所述第一日志中提取出输入数据，包括：根据所述第一日志获得匹配的第一日志模型，使用所述第一日志模型从所述第一日志中提取出所述输入数据；或者

所述从所述第二日志中提取出输出数据，包括：根据所述第二日志获得匹配的第二日志模型，使用所述第二日志模型从所述第二日志中提取出所述输出数据。

3.根据权利要求2所述的方法，其特征在于，所述第一日志和所述第二日志的粒度相同，所述第一日志模型和所述第二日志模型包括解析规则。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

根据所述第二日志获得所述第二业务的预期输出和实际输出，将所述预期输出和所述实际输出进行比对，定位出发生故障的业务。

5.根据权利要求4所述的方法，其特征在于，所述根据所述第二日志获得所述第二业务的预期输出和实际输出，包括：

获得所述第二业务在当前时间的当前第二日志，从所述当前第二日志中提取出实际输出；

获得所述第二业务自所述当前时间起预定时间段内的历史第二日志，从所述历史第二日志中提取出数据，对提取出的数据进行线性回归处理，将处理结果作为预期输出。

6.根据权利要求1-5任一权利要求所述的方法，其特征在于，在所述定位出发生故障的业务之后，还包括：

发送报警信息；和/或

自动获取每个发生故障的业务的调试日志，对自动获取的所有调试日志进行聚合处理，定位出故障原因。

7.根据权利要求6所述的方法，其特征在于，所述自动获取每个发生故障的业务的调试日志，对自动获取的所有调试日志进行聚合处理，包括：

自动获取每个发生故障的业务所包含的服务器的调试日志，对所述调试日志进行聚合处理，确定发生故障的服务器，其中，所述调试日志的粒度小于所述第一日志和所述第二日志的粒度；和/或

获得对应每个发生故障的业务的日志分析结果，对所述日志分析结果进行聚合递归分析，确定出故障源。

8.根据权利要求6所述的方法，其特征在于，在所述自动获取每个发生故障的业务的调试日志之前，还包括：

设置输出所述调试日志的开关按钮。

9.根据权利要求7所述的方法，其特征在于，所述自动获取每个发生故障的业务所包含的服务器的调试日志，包括：

通过日志框架自动获取每个发生故障的业务所包含的服务器的调试日志。

10.根据权利要求9所述的方法，其特征在于，所述调试日志中包含追踪标识；或者，所述调试日志为异常的调试日志。

11.一种SOA环境下的故障检测装置，其特征在于，所述SOA环境包括位于同一业务链的第一业务和第二业务，且所述第一业务位于所述业务链的起点，所述第二业务位于所述业务链的终点，所述装置包括：

第一提取模块，用于获得所述第一业务的第一日志，并从所述第一日志中提取出输入数据；

第二提取模块，用于获得所述第二业务的第二日志，并从所述第二日志中提取出输出数据；以及

第一定位模块，用于将所述第一提取模块提取出的所述输入数据和所述第二提取模块提取出的所述输出数据进行比对，定位出发生故障的业务。

12.根据权利要求11所述的装置，其特征在于，所述第一提取模块，具体用于：根据所述第一日志获得匹配的第一日志模型，使用所述第一日志模型从所述第一日志中提取出所述输入数据；或者

所述第二提取模块，具体用于：根据所述第二日志获得匹配的第二日志模型，使用所述第二日志模型从所述第二日志中提取出所述输出数据。

13.根据权利要求12所述的装置，其特征在于，所述第一日志和所述第二日志的粒度相同，所述第一日志模型和所述第二日志模型包括解析规则。

14.根据权利要求11所述的装置，其特征在于，所述第一定位模块，还用于：

根据所述第二日志获得所述第二业务的预期输出和实际输出，将所述预期输出和所述实际输出进行比对，定位出发生故障的业务。

15.根据权利要求14所述的装置，其特征在于，所述第一定位模块，具体用于：

获得所述第二业务在当前时间的当前第二日志，从所述当前第二日志中提取出实际输出；

获得所述第二业务自所述当前时间起预定时间段内的历史第二日志，从所述历史第二日志中提取出数据，对提取出的数据进行线性回归处理，将处理结果作为预期输出。

16.根据权利要求11-15任一权利要求所述的装置，其特征在于，还包括：

报警模块，用于：在所述第一定位模块定位出发生故障的业务之后，发送报警信息；和/或

第二定位模块，用于：在所述第一定位模块定位出发生故障的业务之后，自动获取每个发生故障的业务的调试日志，对自动获取的所有调试日志进行聚合处理，定位出故障原因。

17.根据权利要求16所述的装置，其特征在于，所述第二定位模块，具体用于：

自动获取每个发生故障的业务所包含的服务器的调试日志，对所述调试日志进行聚合处理，确定发生故障的服务器，其中，所述调试日志的粒度小于所述第一日志和所述第二日志的粒度；和/或

获得对应每个发生故障的业务的日志分析结果，对所述日志分析结果进行聚合递归分析，确定出故障源。

18.根据权利要求16所述的装置，其特征在于，还包括：

设置模块，用于：在所述第一提取模块自动获取每个发生故障的业务的调试日志之前，设置输出所述调试日志的开关按钮。

19.根据权利要求17所述的装置，其特征在于，所述第二定位模块，具体用于：

通过日志框架自动获取每个发生故障的业务所包含的服务器的调试日志。

20.根据权利要求19所述的装置，其特征在于，所述调试日志中包含追踪标识；或者，所述调试日志为异常的调试日志。