使用分布式执行跟踪的故障管理系统和方法与流程

本发明涉及一种用于管理业务故障的跟踪系统和方法。本发明还涉及一种存储程序代码的计算机可读存储介质，程序代码包括用于执行该方法的指令。

背景技术：

分布式系统越来越复杂、庞大且具有异构性。这类大规模分布式系统的一个示例为公有云。公有云可以包括众多在平台上运行的分布式业务，这些平台托管于操作人员需要确保高可靠性业务的各种云化基础设施上。大规模系统的运行在故障处理上面临着一些挑战。现有的故障管理技术包括调试、剖析，以及日志分析。虽然这些方法提供有关故障的重要信息，但它们仅关注软件部件层面，忽视了基础业务发放。

多租户、面向消费者、以业务为导向的现代大规模分布式系统，例如公有云平台(德国电信的开放电信云、microsoftazure，以及googleappengine等)，日益复杂，分布在网络中，并由拥有不同技能和知识的专业人员开发和操作。这种设定使得故障处理极其困难。在较小的自包含环境中处理故障比较简单，因为重现故障所需的条件相对简单。然而，在业务繁多且服务器并行运行的复杂系统内，由于环境不容易再现，所以很难管理故障，包括分析根本原因和解决故障。

在这种复杂的分布式系统中，客户上报的故障通常无法由开发人员或操作人员独立修复。故障修复需要借助新的故障处理方法和工具，这些新的故障处理方法和工具使开发人员和操作人员都参与故障解决。因此，几家公有云供应商使用devops范式促使其开发和操作团队进行协作。devops增进了信息交流，提高了开发、质量保证和操作方面的业务水平。

尽管分布式系统的规模和复杂度达到了前所未有的水平，但是很多工程师仍然依赖于日志设施，并使用一些“printf”指令来记录系统状态和发生的异常情况，或者标注丢失的资源。

所有基于日志的方法对于软件开发人员来说是十分有用的技术，但对于操作人员而言无足轻重。当故障发生时，将开发人员编写的错误消息发送给操作人员。然而，在云环境中，例如，操作人员如何能够理解业务发放过程中的错误是什么原因导致的，并创建用户请求的新虚拟机？

2016-09-1920:26:336619errornova.openstack.common.rpc.common[-]localhost:5672的amqp服务器不可达：[errno111]econnrefused.在23秒内重试。

操作团队需要查看端到端业务发放，以快速了解业务故障。操作人员要了解基础业务发放中的操作过程，从而有效识别和定位故障。开发人员要了解部件的故障、错误以及失败之间的关系，以快速恢复业务的可用性。因此，需要新的方案。尤其需要关注软件故障管理和软件可靠性。具体而言，本发明的目的可以包括通过分析根本原因来提高分布式系统的可靠性、识别性能瓶颈和缺陷、检测软件执行过程中的异常行为，以及修复故障。

技术实现要素：

本发明旨在提供一种用于管理业务故障的跟踪系统和方法，其中，所述用于管理业务故障的跟踪系统和方法解决了现有技术的上述一个或多个问题。

本发明的第一方面提供了一种用于对分布式系统提供的业务发生的故障进行管理的跟踪系统，所述跟踪系统包括：

-状态机存储器，用于存储分布式执行状态机(distributedexecutionstatemachine，desm)，其中，所述desm的状态对应于所述业务的预定里程碑，所述desm的转变对应于所述业务的一个或多个指令；

-日志单元，用于在日志存储器中记录所述分布式系统的事件，其中，事件指示所述desm的状态和/或转变；

-进程重构子系统，用于从存储于所述日志存储器中的所述事件重构desm跟踪；以及

-关联单元，用于将所述分布式系统的日志信息关联至所述状态。

所述分布式系统可以是例如云，其在位于若干数据中心的多个服务器上运行。

存储desm可以指存储描述所述desm的可能状态和转变的信息。所述进程重构子系统可以使用所述信息来重构跟踪。

所述日志单元可以为所述分布式系统提供应用程序接口(applicationprogramminginterface，api)，包括所述分布式系统的所述服务器可以调用的方法。

所述关联单元用于将所述分布式系统的所述日志信息关联至所述状态。所述日志单元可以用于记录状态和转变，而所述关联单元所关联的所述日志信息可以是与故障、问题和/或未预见事件相关的日志信息。所述状态可以涉及重大里程碑，而所述日志信息可以涉及编程器级别的细节。所述日志信息可以是传统的(未必被结构化或标准化的)日志信息。所述日志信息可以例如从一个或多个日志文件和/或日志流中获取。

在实施例中，所述日志存储器也可以称为事件存储器。所述日志存储器可以用于存储多个预先定义的事件。在另一方面，所述日志信息可以为任意类型的信息。

所述跟踪系统可以作为业务在所述分布式系统中实现，例如，在所述分布式系统的服务器上运行。在其它实施例中，所述跟踪系统用于在独立于所述分布式系统的服务器上运行。

所述进程重构子系统可以用于在线重构所述跟踪，例如，在所述分布式系统运行时自动重构。这种重构方式的优势在于，重构的跟踪易于使用。

所述第一方面的所述跟踪系统在故障定位、根本原因分析和/或故障解决这些领域中取得了重大进展。其通过使用分布式执行状态机并重构分布式执行跟踪来达到目的。响应用户请求的业务发放作为软件代码执行的主要抽象。

所述跟踪系统在以下领域也能够发挥作用：应用性能监测(applicationperformancemonitoring，apm)、实时系统监测、用户交易跟踪和监测，以及发现分布式系统的部件互动并为其建模。

所述第一方面的所述跟踪系统能够改变软件应用程序处理故障的方式，尤其是在大规模分布式系统中。所述方法使用分布式执行状态机来描述和跟踪业务发放。运行过程中的所述分布式跟踪为devops提供业务发放的基于状态的可视化，从而实现快速高效的故障处理。

根据所述第一方面，在所述跟踪系统的第一种实现方式中，所述事件包括：

-业务发放事件，指示业务发放的开始和/或结束；

-进程事件，指示一个进程的进入和/或退出；

-状态事件，指示一个状态的进入和/或退出；

-任务事件，指示属于进程的任务的执行；

-控制流事件，指示影响进程的控制流的决定；

-相关性事件，指示第一进程和第二进程之间的相关性；

-并行执行事件，指示进程的并行执行；和/或

-同步，指示进程之间的同步。

记录一个或多个上述事件的优势在于，所述跟踪为所述分布式系统的操作提供有价值的分析。

根据如上所述第一方面或所述第一方面的所述第一种实现方式，在所述跟踪系统的第二种实现方式中，所述desm的开始状态对应于用户提交创建新虚拟机的请求。

分布式系统可为用户提供成百上千的业务。针对这些业务中的任一业务的请求可以是desm的开始状态。然而，虚拟机的创建可以是尤为重要的开始事件，而且与所述分布式系统的操作分析紧密相关。

根据如上所述第一方面或所述第一方面的任意一种前述实现方式，在所述跟踪系统的第三种实现方式中，记录事件包括写独立跟踪语言(independenttracinglanguage，itl)的语句，其中，所述itl包括行，所述行指示进程的标识符、进程相关性和/或上下文元数据。

所述独立跟踪语言(independenttracinglanguage，itl)应定义为：使得desm跟踪可以从itl日志中自动确定性地重构。

优选地，实施所述日志单元使得所述分布式系统的不同服务器和不同业务的事件通过统一itl的语句来记录。所述itl可以在系统中进行标准化。

根据所述第一方面的所述第三种实现方式，在所述跟踪系统的第四种实现方式中，所述上下文元数据包括调试消息、时间戳、部件或模块标识符、系统度量、方法名称、文件名称，和/或进行处理时对应的行号。

所述第四种实现方式的优势在于，基于所述itl的跟踪重构更加简易。

在所述跟踪系统的第五种实现方式中，所述itl以开始标识来指示进程的开始和/或以停止标识来指示进程的停止。

所述第五种实现方式的优势在于，所述标识易于解析，因此所述进程的开始和结束可被迅速识别。

在所述跟踪系统的第六种实现方式中，所述分布式系统的第一服务器响应于请求所生成所有事件接收同一个标识符；若所述第一服务器调用第二服务器的函数，则通过所述itl的相关性语句来指示所述第一服务器的第一进程和所述第二服务器的第二进程之间的相关性。

itl日志包括相关性语句的优势在于，在desm跟踪的重构过程中，若涉及多个不同的服务器(甚至可能位于不同的数据中心)，所述跟踪依然可以继续执行并完成。

根据如上所述第一方面或所述第一方面的任意一种前述实现方式，在所述跟踪系统的第七种实现方式中，所述日志信息包括时间戳，所述关联单元用于基于所述时间戳将所述分布式系统的所述日志信息关联至所述desm的所述状态。

日志信息可以例如包括以printf()等函数编写的简单的日志语句。

根据如上所述第一方面或所述第一方面的任意一种前述实现方式，在所述跟踪系统的第八种实现方式中，所述日志存储器包括消息队列。当目的地(例如，运行在一个服务器上的程序)处于繁忙状态或不可达时，消息队列临时存储消息。因此可以确保没有事件从所述日志存储器中丢失。

根据如上所述第一方面或所述第一方面的任意一种前述实现方式，在所述跟踪系统的第九种实现方式中，所述分布式系统包括仪器应用程序接口(applicationprogramminginterface，api)，用于：当调用所述仪器api的函数时，生成事件并将所述事件传输至所述消息队列。

根据如上所述第一方面或所述第一方面的任意一种前述实现方式，在所述跟踪系统的第十种实现方式中，所述dems可以通过(σ，s，t，s，a，m，l，f)进行描述，其中，

●σ是任务集合，其中，一个任务包括一个或多个指令；

●s是所述dems的状态集合；

●s∈s是所述desm的开始状态和结束状态；

●t:sc×σ→sn是所述desm的转变函数；

●是接受状态的集合；

●m:ssub→ssup是将状态ssufb∈s和转变tsub∈t指派到超状态ssup∈s的映射函数；

●l:s→(st,sl)是为状态s指派状态类型st∈{sequence,split,join}和状态逻辑sl∈{xor,or,and}的映射函数；以及

●f:t→n是为每个转变t∈t指派一个自然数以指示转变的执行流的映射函数。

所述desm因而可以视为分层状态机的子类。实验表明，这些desm尤其适合描述分布式系统中业务请求的跟踪。

根据如上所述第一方面或所述第一方面的任意一种前述实现方式，在所述跟踪系统的第十一种实现方式中，所述跟踪系统还包括可视化子系统，用于为所述重构的desm跟踪生成图示，其中，所述图示具体包括树形视图。

所述第十一种实现方式的优势在于，例如，操作人员能够快速确定错误发生的大体位置。

本发明的第二方面涉及一种用于对分布式系统提供的业务发生的故障进行管理的方法，所述方法包括：

-存储分布式执行状态机(distributedexecutionstatemachine，desm)，其中，所述desm的状态对应于所述业务的预定里程碑，所述desm的转变对应于所述业务的一个或多个指令；

-在日志存储器中记录所述分布式系统的事件，其中，事件指示所述desm的状态和/或转变；

-从存储于所述日志存储器中的所述事件重构desm跟踪；以及

-将所述分布式系统的日志信息关联至所述状态。

根据本发明所述第二方面的方法可以由根据本发明所述第一方面的跟踪系统来执行。根据本发明所述第二方面的方法的其它特征或实施方式可以执行根据本发明所述第一方面的跟踪系统的功能及其不同的实施形式。

根据所述第二方面，在所述业务故障管理方法的第一种实现方式中，记录事件包括写独立跟踪语言(independenttracinglanguage，itl)的语句，其中，所述itl包括行，所述行指示进程的标识符、进程相关性和/或上下文元数据。

本发明的第三方面涉及一种存储程序代码的计算机可读存储介质，所述程序代码包括用于执行所述第二方面或所述第二方面的任意一种实现方式所述的方法的指令。

附图说明

为了更清楚地说明本发明实施例中的技术特征，下面将对实施例描述中所需要使用的附图作简单地介绍。下面描述中的附图仅仅是本发明的一些实施例，这些实施例在不违背本发明如权力要求书中所定义的范围的情况下，可以进行修改。

图1是示出跟踪系统的框图；

图2是业务故障管理方法的流程图；

图3是分布式系统的框图，该分布式系统包括用于对其提供的业务发生的故障进行管理的系统；

图4是故障管理方法的流程图；

图5是desm对“虚拟机创建”业务的发放进行建模的示意图；

图6是与超状态相关联的进程的示意图；

图7是示出将状态和任务与进程相关联的示意图；

图8是示出将进程与业务相关联的的示意图；

图9是示出通过itl将desm与日志进行关联的示意图；

图10是通过分布式执行跟踪生成的序列图。

具体实施方式

图1示出了用于对分布式系统提供的业务发生的故障进行管理的跟踪系统100。在本文中，分布式系统可以是一个软件系统，在该软件系统中，位于网络计算机上的服务器(例如，为其它程序提供功能的计算机程序)通过传递信息(例如，使用http、rpc类连接器、插座，以及消息队列)进行通信。

跟踪系统包括状态机存储器110、日志单元120、进程重构子系统130，以及关联单元140。

状态机存储器110用于存储分布式执行状态机(distributedexecutionstatemachine，desm)，其中，desm的状态对应于业务的预定里程碑，desm的转变对应于业务的一个或多个指令。

日志单元120用于在日志存储器中的记录分布式系统事件，其中，事件指示desm的状态和/或转变。

进程重构子系统130用于从存储于日志存储器中的事件重构desm跟踪。

关联单元140用于将分布式系统的日志信息关联至状态。

基于通过图1所示的跟踪系统获得的跟踪，尤其可以解决以下问题。

●当业务发放失败时，如何确定该失败发生在哪种状态下？

●记录在日志系统的错误对业务发放有什么影响？

●如何将业务发放故障追溯至日志错误及软件代码？

服务化架构(service-orientedarchitecture，soa)是一种连接以业务为表现形式的系统的方法。soa系统是复杂的分布式系统，在该分布式系统中，为终端用户提供业务需要在多个业务之间进行通信和交互。每个业务提供一种特定的重要软件功能。终端用户的业务可以由终端用户直接调用。业务发放是指完成终端用户请求的业务。业务发放可以表现为有限状态机，其确定业务发放过程中涉及的所有业务及其逻辑/时间上的相关性。以openstack为例，终端用户可用的业务包括“虚拟机创建”或“删除卷”。这些业务的调用触发其业务发放，而业务发放转而请求执行终端用户不可见的其它业务。

系统故障可以定义为“交付业务为非正确业务时发生的事件”。故障指用户能够观察到的不合适的动作。故障尤其会发生在服务器或业务层面上。例如，当服务器发生故障时，提供给终端用户的业务通常也会发生故障。

有限状态机(finitestatemachine，fsm)表示由状态、输入字母、转变规则组成的计算模型，其中，状态表示机器在某时刻所处的状态，输入字母使转变能够被触发，转变规则用于基于输入符号确定下一状态。fsm在形式上是多元组(σ，s，t，s，a)，其中，

●(σ)是转变函数所使用的符号的字母；

●(s)是代表状态机的状态集合；

●(s∈s)是开始状态；

●(t:sc×σ→sn)是基于当前状态(sc∈s)和输入符号σ的转变函数，其计算下一状态(sn∈s)；以及

●是接受状态的集合。

分布式系统等软件程序能够计算，因此可以视为状态机。有限状态机广泛应用于数字电子学和编程。

分层有限状态机(hierarchicalfinitestatemachine，hsfm)是状态的子集可以通过以下属性划分为超状态的fsm：一个超状态的所有转变都适用于其子状态，且其中一种子状态定义为表项子状态。hfsm还代表和获取分布式系统在业务发放过程中的不同状态，并在业务发放过程中定位故障。

用于处理软件系统中的故障的现有机制不足以处理云平台等大规模分布式系统中出现的故障。现有方法仅将软件开发人员使用自然语言规定的调试、错误或告警消息记录在日志文件中。传统日志与35年前相比基本相同，可以通过单一的、集中式的小软件程序有效应用，但这些软件程序不适于对大型分布式系统提供的业务发放进行管理，因为大型分布式系统具有并行、多租户、异构、同步及异步特性。

图1所示的跟踪系统100通过跟踪技术将分布式系统的行为具体化，以监测端到端业务发放过程中的各种状态。术语端到端业务发放指对从终端用户向系统请求业务到将结果返回至用户的发放过程进行跟踪。在业务发放过程中，状态可达十几种(甚至上百种)且存在转变。

管理故障的现有技术包括调试、剖析以及日志分析，这些技术均基于软件开发人员单独管理的传统日志机制而建立。这些技术专注于确定软件、库以及中间件中发生的错误和故障。更现代的使用新仪器原语来跟踪软件执行的方法面向跟踪功能调用。尽管开发人员认为该信息十分有用，但对于操作团队而言，该信息级别过低且技术性强，并且无法获知业务发放的行为。

跟踪系统100通过比传统消息日志更高的抽象层来解决该问题。该系统通过分层有限状态机抽象的扩展来监测业务发放进度，以及通过分布式跟踪来定位故障。

现有技术中的方法依赖于低层次仪器原语(例如，“log_event(string)”、“pushdown()”，以及“pushnext()”)来记录描述软件指令的执行是否成功的独立信息。跟踪系统100通过从计算理论、状态机，以及分布式跟踪领域借鉴的理论贡献和技术发展来使用语义形式更为丰富的跟踪，以监测业务发放。这是一种从指令层面到抽象状态机层面来进行故障处理的基本转变。

跟踪系统100因此可以提供一个新的方法，通过在以下两个抽象层跟踪业务发放来帮助操作和开发团队处理以soa为导向的大规模分布式系统中的故障：操作团队易于理解的较高抽象层、软件开发人员易于理解的较低具体层。各层从不同的视角指示同一信息，但使用仅应用于特定域或相关方的不同对象和组成部分。通过抽象化提供给devops的可视化简化了复杂的故障管理任务。

在优选实施例中，跟踪系统可以包括以下特性：

●使用状态机语义的仪器：为了将跟踪具体化，分布式系统需要使用具有状态机语义的特定仪器api来记录业务发放过程中所触发的转变和所处的状态。

●独立的跟踪语言：为了使外部工具能够访问和分析分布式执行跟踪，需要使用独立的表示语言。

●跟踪与日志相关联：为了支持devops，需要集成开发人员视图(dev)和操作人员视图(ops)。换言之，表示业务发放的抽象状态机需要对齐，并连接传统日志设施。

在实施例中，跟踪系统100并未替代传统日志设施。相反，跟踪系统100通过分布式执行状态机(distributedexecutionstatemachine，desm)，即分层有限状态机的扩展，来提供业务发放过程中的状态机视图，并建立从它们的状态和转变与现有日志记录的关联。该关联能够快速确定故障的根本原因并定位故障。

图2示出了用于对分布式系统提供的业务发生的故障进行管理的方法200。该方法可以例如由图1所示的跟踪系统100实现。

方法200包括第一步骤210：存储分布式执行状态机(distributedexecutionstatemachine，desm)，其中，desm的状态对应于业务的预定里程碑，desm的转变对应于业务的一个或多个指令。

该方法包括第二步骤220：在日志存储器中记录分布式系统的事件，其中，事件指示desm的状态和/或转变。

该方法包括第三步骤230：从存储于日志存储器中的事件重构desm跟踪。

该方法包括第四步骤240：将分布式系统的日志信息关联至状态。

图3是系统300的框图，系统300包括用于对分布式系统330提供的业务发生的故障进行管理的跟踪系统。该分布式系统包括第一网络计算机332和第二网络计算机334。第一网络计算机具有存储日志333的第一存储器，第二网络计算机3334具有存储日志335的第二存储器。

故障管理系统包括图3所示的5个子系统：

●desm设计子系统310：使业务发放模型的设计能够获取分布式系统响应于业务请求所触发的转变和所达的状态。desm子系统310包括业务发放desm存储库312，该存储库存储通过desm设计子系统310创建的desm模型；

●仪器子系统336、第一仪器库338a、第二仪器库338b：为api提供desm语义，供分布式系统330监测它们的行为并将行为具体化。第一仪器库338a由第一网络计算机332访问，第二仪器库338b由第二网络计算机访问；

●业务跟踪子系统340：接收、存储来自仪器子系统336的关于业务发放进度的事件并为这些事件编索引；

●跟踪重构子系统350：从有索引的跟踪事件中重构分布式执行跟踪；以及

●跟踪分析和可视化子系统320：将重构的分布式执行跟踪转换为devops团队易于了解和分析的图示，例如树状表现形式。

上述子系统和模块可以通过下述方式交互。

开发人员和操作人员使用desm设计子系统310模拟业务发放，应用分布式执行状态机来确定在运行过程中需要具体化的重大里程碑(状态)。模型存储于业务发放deam存储库模块312中，以便分享和重复使用。

仪器子系统336及其仪器库模块338a和338b用于使分布式系统将原语插入软件代码中，以跟踪业务的开始、所处的状态，以及业务发放过程中执行的任务。这是一种白盒类仪器。仪器库模块338a将信息以事件的形式发送至业务跟踪子系统340。这可以通过使用消息队列342，最好是快速队列系统、数据库、文件或任意其它介质来实现，从而能够进行信息分享。

业务跟踪子系统340及其desm跟踪模块344具有三大作用。其跟踪终端用户的业务请求。每当用户请求业务时，仪器库338a将获取该事件并将该事件发送至desm跟踪模块344。进程跟踪模块和任务跟踪模块具有相似的目标，但分别用于跟踪进程和任务事件。

一旦业务请求被收集后生成发放事件，跟踪重构子系统350及其分布式执行跟踪重构模块352会将这些事件存储于基于时间的数据库，并开始重构业务发放过程中的端到端进程。任务将与各自的进程相关联，并且进程将与各自的业务相关联。针对用于重构业务发放的各个事件，将事件与分布式系统330的(传统的)日志中的记录(通过时间信息)进行关联。由desm/日志关联模块进行的这一关联集成了操作团队的较高抽象层和软件开发人员的较低抽象层。该关联能够实现双程监测和业务发放分析。例如，根据指示故障的日志记录，所建立的关联能够快速确定受影响的业务发放的状态和转变。该关联还可能通过检查所关联的日志记录来快速确定业务发放的状态和转变中可见的故障的根本原因。跟踪被存储于跟踪存储库模块356中，以便后续进行分析和可视化。

跟踪分析和可视化子系统320访问跟踪存储库356并从中检索跟踪，并使用几种技术和图形化语言来显示业务发放中的desm。操作和开发团队能够可视化地处理和解决故障。

图4是故障管理方法400的流程图。

方法400在初始步骤405进行初始化。

在第一步骤410中，设计desm。操作和开发团队都应该参与设计。优选地，该步骤由提供图形用户界面的desm设计子系统来执行。

在第二步骤420中，提供仪器子系统。

在第三步骤430中，执行端到端业务发放。

当在步骤435中删除新业务请求时，该方法继续执行步骤440，重构跟踪。

之后，在步骤450中，将跟踪关联至日志记录。

然后，在步骤450中，对所关联的跟踪进行分析和可视化。例如，desm可以被可视化为图表视图和故障，如从日志记录所见，desm可以靠近图表的节点或边缘进行可视化。

该方法结束于步骤465.

图5是desm对openstack的“虚拟机创建”业务的发放进行建模的示意图。具体而言，desm被建模为hfsm的扩展。desm在形式上是多元组(σ，s，t，s，a，m，l，f)，其中，

●(σ)是任务集合。任务代表(例如python或者c++中的)一个或多个编程语句，这些语句在执行时使业务发放从一种状态转变为另一种状态。任务名称通常以动词形式表示，例如，“获得认证令牌(getauthenticationtoken)”；

●(s)是代表分布式系统执行过程中的与业务发放相关的特定里程碑的状态集合。状态经常通过以“ing”结尾的动词或以动词的过去式来标识，例如，“认证用户(authenticatinguser)”或“已获得令牌(tokenacquired)”；

●(ss,se∈s)：ss是开始状态，其始终为业务端点。se是结束状态，其始终为业务端点。此外，ss＝se。例如，openstack借助客户端应用来使用url端点，其中，终端用户能够在该url端点处访问业务；

●(t:sc×σ→sn)是基于业务发放的当前状态(sc∈s)和执行的任务集合σ的转变函数(t∈t)，用于计算发放的下一状态(sn∈s)；

●是接受状态，其始终为状态se；

●(m:ssub→ssup)是将状态ssub∈s和转变tsub∈t指派到(分组到)超状态ssup∈s的映射函数。超状态是称为进程的特定状态；

●(l:s→(st,sl))是为状态s指派状态类型st∈{sequence,split,join}和状态逻辑sl∈{xor,or,and}的映射函数。l指示业务发放流。状态可以是序列、分解或参与。“序列”状态使其输出和输入转变能够按序进行。其代表序列流。“分解”是将流分解为多个并行转变的控制状态。“分解”状态具有多个输出转变。“参与”是将多个输入转变进行同步的控制状态。“异或”、“或”、“和”指示多少转变能够将一个或多个转变作为一组而触发；

●(f:t→n)是为每个转变t∈t指派正自然数的映射函数，以指示转变的执行流。分解状态的输出转变和参与状态的输入转变被指派相同的流号，表示它们并行执行或者仅执行转变的非空子集。流号在进程之间和各进程内有一定的范围。

在图5中，所示的11种状态标识了业务发放过程中的重要里程碑。每个转变表示一个编程语句集合，该集合的执行使desm从一个状态转变为另一个状态。每个转变具有一个流号，指示该转变的激活时间。分布式执行状态机描述如下：

●终端用户提交创建新虚拟机的请求(1)。对于该请求，desm的开始状态为dashboard_s1。

●仪表盘业务联系keystone业务，以生成认证令牌(2)。分布式系统的新状态为keystone_s1。

●keystone业务将令牌返回至仪表盘(3)。状态又变为dashboard_s1。

●仪表盘发送创建虚拟机的请求至novaapi业务(4)。新状态为nova-api_s1。

●novaapi业务将用于验证的令牌发送至keystone业务。新的状态为keystone_s1(5)。

●novaapi业务接收验证信息(6)。新状态为nova-api_s1(若令牌无效，则将通知用户该请求被拒绝)。

●novaapi业务为新虚拟机创建数据库条目(7)。新状态为nova-db_s1。

●数据库返回数据库访问的代码(8)。新状态为nova-api_s1。

●novaapi业务将请求发送至novascheduler业务(9)。新状态为nova-scheduler_s1。

●novascheduler业务与nova-db_s1交互，以确定在哪个主机上运行新服务器(10，11)。新状态为nova-scheduler_s1。

●novascheduler业务通过rpc.call将虚拟机创建请求发送至选出的novacompute业务主机(12)。新状态为nova-compute_s1。

●然后执行步骤(13-18)。

●一旦图像准备就绪，novacompute业务就请求新ip(19-20)。

●接着执行步骤(21-25)。

●用户接收所创建的虚拟机的参考(26)。

为了简化desm，仅示出“获取图像(getimage)”任务来进行转变(15)。同样为简单起见，将不示出详细的过程。

图6是与超状态glance-api_s1相关联的进程的示意图。第一节点610与用户认证相关。状态从版本协商和用户认证的转变612转变为请求已被接受的状态614。然后，将节点616转变到加载图像的节点618。若需要检索远程图像，则从节点620a转变到节点622a，节点622a所对应的状态是“发现url图像”。或者，若需要检索本地图像，则从节点620b转变到节点622b，节点622b所对应的状态是“发现dir图像”。之后的节点624a和624b将转变到节点626，节点626所对应的状态是“参考已加载”。

为了将desm跟踪具体化并使之透明化，开发人员可以使用仪器来增加代码指令，以记录已到达的状态和进程以及已执行的任务。该步骤被称为仪器软件代码，由仪器子系统执行。

表面上看，代码跟踪、调试、记录等现有方法可以提供一种合适业务发放跟踪方案。然而，通过更加仔细的检查，发现现有方法仅提供了“write(string)”、“writeif(string)”、“assert”、“log.info(string)”、“log.warning(string)”、“log.error(string)”等通用函数来记录以下文本消息：

●调用的功能；

●数据负荷；

●回调例程；

●数据持久化于数据库；以及

●错误条件及异常状况。

这些原语在日志中记录信息，但忽略了与以状态为中心的业务发放相关的语义。因此，跟踪重构基于定时信息、可变相关性、启发式方法以及假设，但由于异步行为、并发性以及缓存效应等，它们未完全获得业务发放过程中的具体细节。

通过使用仪器的desm语义，有可能再进一步：

●业务发放的开始和结束；

●进程的进入和退出；

●状态的进入和退出；

●属于进程的任务的执行；

●影响进程的控制流的决定；

●不同进程之间的相关性；

●进程的并行执行；

●进程同步。

清单1：说明仪器的基于desm的语义的使用的一组函数。

清单1提供了一组函数来说明下述语义的级别：

ctx＝create_context(request_id,user_id,…)

ctx＝get_context(…)

start_service_tracing(ctx,service_name,…)

end_service_tracing(ctx,service_name,…)

enter_process_tracing(ctx,process_name,…)

exit_process_tracing(ctx,process_name,…)

enter_state_tracing(ctx,state_name,…)

exit_state_tracing(ctx,state_name,…)

xor_split_state_tracing(ctx,state_name,…)

or_split_state_tracing(ctx,state_name,…)

and_split_state_tracing(ctx,state_name,…)

xor_join_state_tracing(ctx,state_name,…)

or_join_state_tracing(ctx,state_name,…)

and_join_state_tracing(ctx,state_name,…)

horizontal_process_correlation(ctx_from,ctx_to,…)

清单1：说明仪器的基于desm的语义的使用的一组函数。

这些函数是仪器库(一个api)的组成部分。当仪器函数被调用时，其生成一个事件，该事件被发送至业务跟踪子系统。事件通过独立跟踪语言来表示。

仪器库的容量应当足以保存desm跟踪，以便后续重构。待保存的内容包括并发行为、分叉、参与。这些元素支持诊断与过度并行或不并行相关的问题、诊断在同步点等候时间过长，以及确定关键路径。

跟踪端到端业务发放(图4所示的步骤3)是跟踪业务请求及其业务发放的活动。在发放过程中，响应于来自σ的编程语句的执行，仪器子系统生成事件来指示desm经历了一系列状态s。由分布式系统执行的语句触发转变(t∈t和t:sc×σ→sn)，这些转变使desm从状态sc转变到状态sn。状态序列{(si,sj),(sj,sk),…,(sm,sn)},{si,…,sn}∈s称为分布式执行跟踪或简称为跟踪。

独立跟踪语言(independenttracinglanguage，itl)使可视化和分析工具等可以携带跟踪信息。该中间表示语言提供软件代码行为与业务发放之间的集成层。

上一章节描述的仪器库的函数与中间跟踪语言的事件之间具有清楚的映射关系。仪器库的各个函数被调用时时会生成特定事件，该事件对分布式执行跟踪重构子系统后续重构状态机和跟踪至关重要。

以下摘录阐述了当执行图6所示的部分desm时会生成的中间跟踪语言。其示出了跟踪事件的示例，这些跟踪事件指示业务发放的开始、系统何时进入或退出进程、何时执行任务、何时达到某种状态。跟踪语言必须获取后续重构desm所需的所有信息。

service_id4service“virtualmachinecreate”startuser_idctx

…

service_id4process_corr(service_id4,process_id7)ctx

process_id7process“processingimagerequest”enterctx

ctx.service＝'glanceapi'

process_id7state“authenticatinguser”enterctx

process_id7task“negotiateversion”ctx

ctx.funcname＝‘brk.version_negotiation‘

process_id7task“authenticateuser”ctxctx.funcname＝’keystoneclient.session'

process_id7state“requestallowed”exitctx

process_id7state“loadingimage”enterxor.splitctx

process_id7task“retrieveremoteimage”ctxctx.funcname＝‘get_rmt_img‘

process_id7state“urlimagefound”exitxor.joinctx

…

process_id7process“processingimagerequest”exitctx

service_id4service“createvm”endctx

清单2：使用独立跟踪语言表示的端到端业务发放跟踪的摘录。

每行可以对到达哪种状态和进程、执行什么任务进行跟踪。业务请求和进程具有128位的通用唯一识别码(universallyuniqueidentifier，uuid)。这些识别码可以通过处理请求的各部分，从接收初始请求的服务器或对业务发放起作用的服务器的所有区域中获得。若线程每次处理一个请求，则将uuid存储于本地线程存储器中是一个简易且有效的方案。在上述itl摘录中，service_id4和process_id7是uuid的示例。这些识别码用于将与相同业务请求和相同业务发放相关的事件汇集在一起。

当业务发放过程中将执行由一个服务器转移到另一个服务器时，接收该执行的服务器生成新的唯一识别码，并且进入新的进程状态。指令process_corr(process_idx,process_idy)能够在与进程(超状态)相关的识别码之间建立逻辑关联和相关性。在服务器接收控制流时生成新的uuid对于跟踪(由具有异或或者分解类型/逻辑的状态生成的)并行执行是必要的。由业务请求启动的第一个进程也通过process_corr(…)进行关联。process_corr建立了业务与进程之间的相关性。上述itl示例说明了以下业务/进程相关性：

service_id4process_corr(service_id4,process_id7)ctx

上下文元数据(通过itl摘录中的ctx表示)包括通常在跟踪架构中显示的若干信息。上下文元数据模式的一个示例表示为：

ctx＝timestampmsgcomponentfuncnamefilenamelineno

itl应该被设计拥有以执行流来传播上下文元数据的能力。上下文元数据可视为将执行流的上下文信息进行聚集的数据结构，上下文信息包括调试消息(msg)、时间戳(timestamp)、部件或模块(component)、系统度量(cpu和mem)、方法名称(funcname)、文件名称(filename)、进行处理时对应的行号(lineno)等。

时间戳标示仪器事件生成的时间。由于时间戳可以用于定义总顺序，所以时间戳可以用于推断仪器事件在同一服务器中的生成时间。在服务器中，相关性原语可以用于定义进程之间的逻辑顺序。

来自仪器库且根据itl进行格式化的事件存储于快速传输媒介(例如，消息队列)中，等候处理。通过流处理技术分析事件，并将事件发送至业务跟踪、进程跟踪、任务跟踪以进行检索和分析。

itl所表示的各种事件包括具有时间戳的上下文元数据，因此，有可能发现可跟踪事件之间的因果联系。各事件记录如下事实：在特定时刻，到达业务发放过程中的特定状态。在步骤4中，建立事件之间的因果联系，以确定在不同时间的业务发放进度。该步骤称为跟踪重构，由跟踪重构子系统(分布式执行(distributedexecution，de)跟踪重构模块)执行。

需要执行以下四个流程来重构端到端业务发放：(1)将任务与进程相关联；(2)将进程与业务相关联；(3)将各进程相关联；(4)重构端到端跟踪。

(1)将任务与进程相关联

当服务器接收到来自其它服务器的请求时，创建标识符为process_id(uuid)、名称为pname的新的进程状态process。服务器响应于同一请求而生成的所有状态state和任务task都接收该标识符process_id。因此，为了处理该请求而生成的所有状态和任务具有相同的process_id，从而易于将这些状态和任务与其父进程相关联。

该方法如图7所示。网络计算机710包括第一服务器712和第二服务器714。第一服务器712接收来自另一服务器(未在图7中示出)的请求req。第一服务器创建标识符为process_id7的新状态，并将进程命名为pname7.为了指示进程的开始，该事件具有标识enter：

process_id7procespname7enter

在跟踪用于处理请求req的所有状态和任务后，通过生成事件exit来标志进程跟踪完成：

process_id7processpname7exit

状态和任务指定其所属进程及其名称。各状态和任务还可以包括其自身的标识符，以便后续能够对业务发放进行更加细致的分析。

图7是示出将状态和任务与进程相关联的示意图。

(2)将进程与业务相关联

当用户提出业务请求时，通过以下流程发起业务发放跟踪。发放用户所请求的业务的服务器生成标识符为service_id的事件service和process_id，以确定即将开始的进程。服务器通过事件process_corr(service_id,process_id)将service_id与process_id相关联。该流程在图8中示出。

图7还示出了将进程与业务相关联的的示意图。

运行在网络计算机c1上的服务器s11接收业务请求s_req。服务器s11生成新标识符service_id4，并通过生成事件(1)开始跟踪业务请求，其中，sname1是已开始业务的名称：

service_id4servicesname1start

当需要另一服务器参与业务发放时，生成相关性事件(2)，并建立service_id4和process_id7之间的关联：

service_id4process_corr(service_id4,process_id7)

在图8中，服务器s21将继续进行处理并运用“将任务与进程相关联”流程。上述流程将生成事件(3)-(5)。调用方或被调用方可以根据以上实施方式生成相关性事件。

当业务发放完成时，生成事件(8)：

service_id4servicesname1end

(3)将各进程相关联

若一个服务器调用另一服务器，则业务发放跟踪将由一个服务器转移到另一服务器。换言之，当网络计算机的一个服务器向另一网络计算机的另一服务器请求业务时，生成进程相关性事件：

process_corr(process_id1,process_id2)

process_id1是调用方的标识符，process_id2是被调用方的标识符。调用另一进程包括在部件之间传递上下文元数据。

该流程如图8所示。当控制流由服务器s11转移到服务器s21时，建立相关性并生成事件(6)。服务器s21将继续进行处理并运用“将任务与进程相关联”流程。该流程将生成事件(7)(未示出其它可能生成的事件)。

(4)重构进程模型跟踪

在该阶段，进程已与业务相关联，进程已与业务及进程相关联，且任务已与进程相关联。因此，有可能重构基于desm的完整的端到端业务发放跟踪。以下流程中描述了重构：

●输入：

○service_id：用于重构的业务请求的标识符；

○correlations：要考虑的进程相关性process_corr(x_id,y_id)的集合；

○all_events：要考虑的事件的集合。

●输出：分布式执行跟踪。

●流程：

○通过相关性集合correlations计算service_id的传递闭包(transitiveclosure，tc)：

■tc(service_id,correlations)

○对于具有tc(service_id,correlations)中的标识符id的各个事件，用具有标识符id的all_events中的事件来创建新列表id_list；

○通过来自ctx上下文的时间戳timestamp对id_list排序；

○若correlations中存在进程相关性process_corr(process_id1,process_id2)，则建立两个集合id_list1和id_list2之间的关联；

○通过进程相关性process_corr(service_id,process_id1)建立service_id和集合set_list之间的关联。

流程1：分布式执行跟踪重构流程

由于事件是通过时间戳来排序的，因此需要考虑网络计算机之间的同步差异。网络计算机不具有完全同步的时钟。在同一计算机中，由于物理时钟相同，所以跟踪事件通过本地时间戳进行排序。在不同的网络计算机中，两个进程跟踪通过相关性事件process_corr(process_id1,process_id2)进行排序，从而明确表示进程process_id1先于prcoess_id2开始。这要求使用逻辑时钟。

重构跟踪存储于跟踪存储库中，以进行分析和可视化。

操作和开发团队在功能上通常相互独立。统一的环境可以将操作和开发团队联系起来以弥合这两个团队之间的差距，从而诊断业务发放过程中可能出现的问题。为了支持devops，可以提供desm和适用于操作团队的分布式执行跟踪之间的联系，以及desm和适用于开发人员的传统日志设施之间的联系。步骤5是将跟踪与日志记录相关联，由跟踪重构子系统的desm/日志关联模块执行。该集成通过图9所示的中间跟踪语言来实现。

图9是示出通过itl将desm与日志进行关联的示意图。

操作层910通过以上所述的desm获取业务发放。开发层930获取通常由日志设施记录的详细的系统执行信息。集成层920通过itl将这两层连接在一起。

使用中间跟踪语言不仅为操作人员提供业务发放视图，还将基于desm的高层跟踪集成到存储于日志系统中的低层记录。当操作团队确定故障时，开发团队能够很容易地访问关于发生故障的各软件部件的详细低层信息。这能够快速定位业务发放故障。由于软件故障定位是系统运营和维护中最昂贵的活动之一，因此快速定位故障极其重要。中间跟踪语言中使用时间戳，因此时间戳可以用于将来自传统日志记录的一些记录关联起来。

自动化关联通过以下流程来实现：

●输入：

○te：带有时间戳ctx.timestamp的跟踪事件：

■例如，process_idtask“name”…ctx.timestamp；

○w：具有w(tm,tp)结构的窗口，其中，tm和tp分别是窗口的下界和上界；以及

○lr：带有时间戳timestamp的日志记录lr。

●输出：分布式跟踪事件和日志记录之间的联系。

●流程：

○建立lr和teiff之间的联系：ctx.timestamp-tm<timestamp<ctx.timestamp+tp

该联系基于事件发生的时间点。可以将若干日志记录lr与跟踪事件te相关联。通过控制窗口大小可以管理关联数量。

良好的分析和可视化对于故障管理十分重要。可以使用多种类型的图表对端到端业务发放跟踪进行分析和可视化。步骤6为对业务发放进行分析和可视化，由跟踪分析和可视化子系统(分布式执行跟踪模块的可视化)执行。可以通过简单的流程进行跟踪分析，该流程评估分布式执行跟踪是否为业务发放过程中生成的分布式执行状态机的有效实例。该章节描述了如何从跟踪生成序列图。

序列图通常用于表示复杂业务和操作的逻辑流，还可用于有效地对业务发放进行可视化。图10示出了从跟踪创建的序列图的一个示例。该图示出了参与业务发放的三个服务器：服务器s11“glance-api”、服务器s22“keystone-admin”、服务器s23“glance-registry”。service_id4指示业务请求的入口点。业务、进程、状态以及任务与其生命线相关联。每个激活框对应于具有唯一process_id的一个不同进程。进程中所有执行的任务和到达的状态都位于进程的生命线中。竖直进度指示执行任务的逻辑(及物理)顺序。

图10所示的可视化能够实现对业务发放的详细分析。另外，由于itl与日志信息关联，所以有可能从序列图“行进”到步骤5中所关联的日志记录。

从跟踪构建序列图的高层流程如下所示：

●输入：

○pbt：为service_id重构的跟踪。

●输出：序列图

●流程：

○为pbt中的进程process_id的各个不同ctx.component创建参与者participant(对象)。每个部件的生命线示为一个框，有一条虚线从框底边的中心向下延伸，代表部件在业务发放过程中的寿命；

○将与生成参与者的进程相关的所有事件放置于各participant的生命线中；

○相同id_list中的所有事件创建从participant到participant的时间循环消息(方法调用)。这使得属于相同process_id的事件能够在相同的生命线和激活框下聚集起来。这些方法调用框用于指示部件为了支持业务发放所进行的处理；

○为所有相关性事件process(process_id1,process_id2)创建从process_id1生成的component1至process_id2生成的component2的定向消息。消息在序列图中以所标箭头来指示。这些横向箭头表示与业务发放相关的逻辑的序列属性，并按照消息的顺序来显示。

这些步骤将用作指南，因为序列图的创建取决于用于对图表进行可视化的工具。

对于大型云平台等复杂而重要的分布式系统的故障管理，操作团队和开发团队需要共同参与、相互协作。本发明实施例可以实现以下一种或多种益处：

●作为状态机进行运作：对于操作团队，使用分层有限状态机的扩展来获取复杂的大型分布式系统中的业务发放所触发的执行流能够更加有效地管理业务故障。

●集成操作和开发：将操作的进程与软件代码和日志记录相关联，能够在业务发放过程中有效定位故障，并且更加高效地进行根本原因分析。这种明确的相关性使得能够从业务发放转到具体的软件执行，最后到详细的日志信息，反之亦然。

●领域专用仪器化语义：使用仪器代码的特定语义提供了分布式系统的执行的状态视图，而非低层调用跟踪或部件之间的消息传递视图。

●状态机抽象：与传统日志和调试系统相比，状态机抽象与操作团队知识之间的匹配更严密。

●独立跟踪语言：独立跟踪语言能够生成来源于desm的同一跟踪的各种视图。序列图、网络图、业务进程及其它常见图表可以很容易地从同一跟踪生成；以及

●性能分析：通过将简单的、易于删除的、良好隔离的仪器指令添加到分布式系统的代码中，有可能迅速增强业务发放的可视化并进行故障定位。

上文描述仅仅为本发明的实施方式，本发明的范围并不仅限于此。本领域技术人员可以容易地做出任何改变或替换。因此，本发明的保护范围应以所附权利要求的保护范围为准。