分布式系统中的识别根原因和确定问题的方法和设备

相关申请的交叉引用

本申请涉及如下共同申请的美国专利申请：“Methods AndApparatus for Managing Dependencies in Distributed Systems”(代理人文档号：YOR920020097US1)“Methods And Apparatus ForTopology Discovery and Representation of Distributed Applicationsand Services”(代理人文档号：SOM920020003US1)“Methods AndApparatus For Impact Analysis and Problem Determination”(代理人文档号：SOM920020004US1)、“Methods And Apparatus ForDependency-based Impact Simulation and Vulnerability Analysis”(代理人文档号：SOM920020005US1)，其公开内容收录于此，以供参考。

技术领域

本发明涉及分布式计算系统，更具体地说，涉及根据这种分布式计算系统的各种组件之间的相依性，分析并确定服务中断的根原因的方法和设备。

背景技术

对于综合故障管理来说，分布式系统的组件之间的识别和跟踪正在变得越来越重要。应用，服务和它们的组件依赖于服务提供商可外购的各种支持服务。此外，合并基于web(基于万维网)的业务体系结构允许在运行时间的基于web的电子商务的构成。

要明白的是术语“运行时间”一般指的是当一个软件正被执行并在计算机系统的存储器中活动的时段，与处于睡眠状态，仅仅位于计算机的硬盘驱动器上的存储区中相反。从而，在运行时间能够构成电子商务应用意味着具有这样做的能力，而不需要停止并重新启动系统/应用，也不需要重新编译应用。通常，计算机程序的生命周期是：写入程序代码→编译(转换成机器代码)→运行。从而，借助上述能力，能够集合几个软件在传输中(on-the-fly)形成一个新的应用，即，不需要停止/编译/重新启动应用。

但是，从而在一个服务中发生的故障会影响正向客户提供的其它服务，即，服务具有对其它服务的相依性(dependency)。单一系统的不同服务的组件之间存在相依性，在跨越多个系统和域的一个服务的客户机组件和服务器组件之间也存在相依性。这里，依赖于其它服务的服务被称为从属物(dependent)，而其它服务依赖于其的服务被称为前身(antecedent)。

重要的是注意服务通常扮演两个角色(例如许多应用和服务需要名称服务，但是名称服务本身依赖于其它服务，例如操作系统和网络协议及基础结构的正常工作)。此外，相依关系是可转移的，即，除了指定组件本身之外，指定组件的从属物组件的前身。

在分布式系统的各种组件，例如最终用户服务，系统服务，应用和它们的逻辑和物理组件之间存在相依性。但是，在目前的系统中，服务相依性并不清楚，从而使得确定、隔离和解决问题的任务特别困难。

软件开发领域中的现有技术(例如美国专利No.4751635和美国专利No.5960196)，软件维护领域中的现有技术(例如美国专利No.5493682)和软件打包领域中的现有技术(例如美国专利No.5835777)处理形成程序包的基本部分的单个软件部件和模块，为了建立软件并把它捆绑到软件产品中，需要程序源代码的可用性。软件开发人员可获得源代码，但是服务用户不能获得源代码。本发明主要集中在已打包的软件产品上。

电气和电子工程师协会标准1387.2(“Portable Operating SystemInterface(POSIX)system administration part 2：SoftwareAdministration”，IEEE，1995)致力于软件分发/部署/安装。该IEEE标准定义一种确保(将被安装的)新的软件组件不会与现有的软件安装冲突的机制。该IEEE标准识别简化这种兼容性检查的三种关系：先决条件、排斥条件、并置条件。这是对于新的软件需要安装于其上的每个系统单独进行的。借助该IEEE标准，不考虑存在于其它系统上的软件详细目录。此外，该IEEE标准不处理实例化的应用和服务，于是在运行时间，不表示确定组件之间的相依性的任何手段。

Open Group(Systems Management：Distributed SoftwareAdministration，CAE Specification C701，The Open Group，1998年1月)通过定义由特定系统上的软件安装工具调用的几个命令(swinstall，swlist，swmodify等)扩展IEEE 1387.2。Open Group还定义一种软件定义文件格式，以确保可从在其上调用上述命令的系统获得上述命令所需的信息。Open Group规范也存在IEEE 1387.2的缺陷(即，局限于单个隔离的系统，不存在确定在运行时间时的软件相依性的手段)。

目前的操作系统目录实现(例如IBM AIX Object Data Manager(ODM)，Linux Red Hat Package Manager(RPM)或MicrosoftWindows Registry)或者遵循OpenGroup规范和IEEE 1387.2，或者按照专用格式描述软件目录。

依据定义，整个软件包的电子软件分发技术(例如美国专利No.6009525和美国专利No.5721824)，或更新/改正/安装/修补技术(例如美国专利No.5999740，美国专利No.5805891和美国专利No.5953533)局限于(每个一个或多个)物理软件包的分发/部署/安装，并不考虑应用的运行时间阶段。另外，它们每次处理一个系统，并不考虑应用和服务的跨系统特征。

确定现有软件/硬件结构方面的冲突的技术(例如美国专利No.5867714)也局限于单个系统，并不考虑运行时间方面。

虽然通常在事件相关性的范围(例如参见Gruschke等的“Integraged Event Management：Event Correlation UsingDependency Graphs”，DSOM′98 1998和Katker等的“Fault Isolationand Event Correlation for Integrated Fault Management”，IM′97，1997)内的现有工作(例如美国专利No.5917831)已集中于识别和以专有格式描述服务相依性，它仍然不清楚如何能够在故障管理进程的不同实体之间实际交换相依性信息。由于外购应用的故障管理进程中涉及的不同各方不太可能使用相同的工具箱来跟踪相依性，因此定义一种规定并交换相依性信息的开放格式非常重要。

另外，由于与故障管理进程所涉及的分布式系统的组件相关的异质性，在现有技术的局限性的情况下，确定系统故障(例如服务中断)的根原因非常困难。

总之，现有技术中已说明和实现了少数几种与确定软件产品之间的关系相关的技术。这些现有技术存在一个或多个下述问题：

(a)它们只致力于一个软件产品的安装和部署阶段；即，它们并不试图解决设计和运行时间等方面；

(b)它们不处理跨越多个系统的端对端应用和服务；即，它们致力于存在于单个的隔离系统上的软件的特性；

(c)以专有格式描述软件目录信息，这使得很难在各种异质系统之间共享该信息；和

(d)它们不能有效地识别服务中断的根原因。

发明内容

本发明提供识别组件故障的根原因(root cause)并根据计算环境，执行恰当的问题确定程序的技术。例如，本发明的技术可应用于分布式计算环境。计算环境也可以是自主计算环境。

例如，在本发明的一个方面，一种基于计算机的确定计算环境中的至少一个对象组件(subject component)的状况(例如服务中断)的根原因(root cause)的技术包括下述步骤/操作。首先，识别在所述计算环境中至少一个对象组件依赖于其的一个或多个组件(例如前身(antecedent))。所述识别包括遍历表示与计算环境的至少一部分组件相关联的一个或多个关系的存在，并且能够说明与计算环境的至少一个组件相关联的全生命周期(例如包括部署、安装和运行时间)的模型的至少一部分。

随后，根据一个或多个识别的组件执行一个或多个程序，确定与一个或多个识别的组件中的每一个相关联的条件状态。所述程序可以逐步执行或者组合执行，并且可以包括，例如进程检查，训练，心跳和状态指示符。

举例来说，组件可以是服务，应用，中间件，硬件，设备驱动程序(driver)，操作系统或与计算环境相关的系统。不过，术语“组件”并不局限于这些例子。

结合附图，根据本发明的例证实施例的下述详细说明，本发明的这些及其它目的、特征和优点将变得显而易见。

附图说明

图1是图解说明本发明的特征能够与之交互作用，从而产生信息的客户机-服务器应用体系结构的一个例子的方框图；

图2A是图解说明根据本发明的一个实施例，提供相依性管理的系统的方框图；

图2B是图解说明根据本发明的一个实施例，适合于实现提供相依性管理的系统的计算机系统的一般硬件体系结构的方框图；

图3是图解说明根据本发明的一个实施例的服务的功能相依性模型的方框图；

图4是图解说明根据本发明的一个实施例的服务的结构相依性模型的方框图；

图5是图解说明根据本发明的一个实施例，由功能、结构和操作相依性模型论述的服务生命周期的方框图；

图6是图解说明根据本发明的一个实施例，功能、结构和操作相依性模型之间的关系的方框图；

图7是图解说明根据本发明的一个实施例，分析并计算服务中断的根原因所涉及的组件的方框图图；

图8是图解说明根据本发明的一个实施例的根原因分析器的组件的方框图；

图9是图解说明根据本发明的一个实施例，调用相依性服务并对操作模型进行根原因分析的步骤的流程图；

图10是图解说明根据本发明的一个实施例，产生并更新功能相依性模型的管理员的任务的流程图；

图11是图解说明根据本发明的一个实施例，通过在计算机系统上安装或除去硬件/软件组件，更新结构相依性模型的步骤的流程图；

图12是图解说明根据本发明的一个实施例，对操作模型的根原因分析的执行的流程图；

图13是图解说明根据本发明的一个实施例，对服务的前身的根原因分析的执行的流程图；

图14是图解说明根据本发明的一个实施例，确定服务的状态的步骤的流程图；

图15描述了根据本发明的一个实施例的根原因分析器应用编程接口的例子。

具体实施方式

下面将在例证的分布式计算环境的语境中说明本发明。但是，本发明显然并不局限于这样的特定计算环境。相反，本发明广泛适用于其中最好是管理(例如计算，查询等)相依性，以使确定、隔离和解决问题的任务明显更容易的任意计算环境。

取决于讨论的上下文，这里使用的术语“系统”可用于表示一个计算机系统，一个软件系统和/或它们的某种组合。术语“系统”也可用于表示一种应用(application)和/或一种服务。从而，短语“多个系统”表示几个系统的集合。另外，术语“组件”可表示系统本身，或者系统的一个或多个部分。

如上所述，在目前的系统中，服务相依性并不清楚，从而使确定、隔离和解决问题的任务特别困难。解决该问题需要确定和计算跨越不同系统和域的服务和应用之间的相依性，即，建立“全局”服务相依性模型，并使系统管理员能够从上到下和从下到上浏览所得到的有向图(directed graph)。最好用下述两种情形举例说明对这种机制的需要。

第一种情形涉及管理一般由因特网或应用服务提供商(ISP/ASP)提供的外购服务。外包服务导致分层的服务层次，例如ASP的服务依赖于ISP提供的IP连通性(因特网协议连通性)，ISP又依赖于电信运营公司的广域网。在每一层，通过服务接入点(SAP)访问服务。SAP划定不同组织域之间的边界，并且是定义和观察服务级协议(SLA)的地方。通常，在每一层这是通过监视提供商揭示的一组具体参数来实现的。就上层服务中的中断或性能退化来说，必须从上到下遍历服务层次，以识别问题的根原因。

第二种情形涉及不能在传输中完成，于是影响服务和它们的客户的常规维护任务：例如，用电子邮件服务器的操作系统的新版本更新电子邮件服务器，用新的固件版本交换或升级网络设备等。在所有情况下，对于网络和服务器管理员来说，重要的是事先确定有多少，更具体地说哪些服务和用户受到维护的影响。我们把这种任务称为影响力分析。

下面的因素进一步恶化了上述任务。

相依性模型提供一种识别所观察到的问题的可能根原因的直接手段。如果已知系统的相依性图，那么从受损服务朝其前身(或者共同位于相同的主机上，或者位于不同的系统上)浏览该图将显示哪些实体可能已发生故障。朝着其根源(即沿向上方向)遍历该图得到服务的从属物，即，如果该服务中断，那么可能失效的组件。需要解决下述问题。

(a)缩放：许多涉及的系统之间的相依性的数目可被计算，不过可能变得很大。从工程的观点来看，通常不希望(有时不可能)在单一地点保存一个完整的实例化(instantiated)相依性模型。于是，由于所涉及的相依性的绝对数和动态特性，因此网络管理平台中使用的传统机制，例如把实例化的网络图保存在平台数据库中不能被应用于相依性。

这两个事实使得阻止遵循部署应用、服务和中间件相依性模型的“网络管理风格”方法。例如，服务外包商的典型数据中心宿主(host)大量的(几千个)web应用和数据库服务器。这意味着例如web应用和数据库服务器的数目巨大的同时运行的程序实例。能够构成相依性模型的系统应提供通过横跨管理进程中涉及的系统，分配相依性的存储和计算，允许恰当的缩放性的特征。

(b)动态特性：宿主的应用(在web应用服务器内运行)具有很短的生命周期，通常只有几秒。当收到请求时，web应用的业务逻辑(通常实现成一个或多个Java Servlet)被应用服务器的servlet引擎实例化，执行其任务，随后被servlet引擎除去。从而，计算这些动态实体之间的相依性的系统应解决数据的准确性和为取回该数据而产生的工作负载之间的折衷。

(c)异质性：异质性以三种不同的方式出现。首先，向客户提供的服务在较大程度上不同。其次，向客户提供服务可能涉及各种提供商。最后，实现服务的产品可能源自各种厂商。计算相依性的系统应提供一咱与特定的操作系统，网络协议，软件产品和向客户提供的服务无关的语言。

(d)相依性数据的手工维护：即使局限于单一主机系统，服务相依性模型的采集也是对它自己的挑战，因为目前的系统通常不提供恰当的管理手段。术语“手段”指的是通过良好定义的(有时甚至是标准化的)接口，揭示(被管理)资源的管理特性和能力，以致它可被管理应用访问的程序代码。此外，即使可从被管理资源获得，目前的系统也不使用相依性数据。相反，相依性信息不仅不得不被手工输入特定的管理组件，而且还得采用专有的格式。于是，相依性信息不完整，过时(归因于容易出错的手工处理)，有时甚至不一致，因为不同的操作员独立输入规则，没有办法自动地关于一致性检查规则库。

(e)相依性的分类法：相依性的概念很粗，需要推敲，以便有用。这样的例子是相依性的强度(表示如果其前身发生故障，那么某一组件受影响的可能性和程度)，关键程度(就企业的目标和政策来说，这种相依性有多重要)，形式化的程度(即，获得相依性有多困难)和更多。需要把允许更恰当地限定相依性的属性加入相依性中；因此，需要在相依性表现中反映这些属性。

(f)问题确定特征：需要更多的把保存在每个系统中的本地相依性图组合成统一的相依性模型的设施。另外，这些设施应提供允许管理应用相对于相依性模型发出查询的API(应用编程接口)。这些查询应被允许取回特定服务直接与之相关的实体，或者递归确定整个一组节点，包括子前身。管理应用收到的节点列表使其能够执行特定的问题确定例程，来检查这些服务是否可操作。

前面的讨论表明重要的是建立服务生命周期的三个不同阶段之间的映射：

(a)提供给客户的一个(抽象)服务，例如“Web宿主”、“被管理的存储器”、“IP连通性”、“被管理的数据库”等；

(b)服务的实现，即用于提供服务的产品，例如“IBM通用数据库版本7.1”、“WebSphere应用服务器版本3.2”；和

(c)实现的运行实例，即进程或任务，例如“db2后台驻留程序”、“nfs后台驻留程序”。

虽然单独获得可在每个单一阶段得到的信息的任务可行，不过把这三个阶段组成到一个统一的相依性模型中具有挑战性，在以前的工作中一直没有进行。另外，需要在消除对人类交互作用和相依性数据的维护的需要的同时，建立致力于底层环境的缩放、动态特性和异质性的要求的可有效计算的相依性模型。

如同下面在附图的语境中举例说明的那样，本发明致力于这些及其它需要。即，本发明具有代表管理应用计算分布式系统的组件之间的运行时间相依性(“相依性模型”)的特征。本发明提供从计算机系统取回相依性信息的类属统一方法，所述计算机系统提供取回单个计算机系统的配置信息的机构，或者以机器可读格式提供这样的数据。

上述系统的一个益处在于能够从这些计算机系统获得大量的应用/服务管理信息，而不需要改编单个的应用/服务。但是，如果存在这样的应用/服务改编，那么本发明可使用这样的应用/服务改编。

本发明描述的系统的执行可由特定的管理应用(例如影响力分析器，根原因分析器)，网络管理平台(例如IBM/Tivoli Netview，HPOpenView或Aprisma Spectrum)或者基于传统的网络管理系统和平台的管理应用触发。

除了别的以外，本发明提供用于实现下述功能的特征：

(a)观察预订服务的性能退化和中断；

(b)通过从上到下遍历相依性模型的不同层，查获问题的根原因(由于可向其它服务提供商外购各种服务，相依性模型的这种(递归)遍历越过域边界)；和

(c)通过从下到上浏览相依性模型，分析服务中断的影响。

本发明组合可在某一应用或服务的生命周期内获得的相依性信息(即，从应用/服务的设计到部署、安装和运行时间阶段)。该信息被保存在下述模型之内：

(a)功能模型：在一个优选实现中，功能模型定义不同的类属服务(数据库服务、名称服务、web应用服务、连通性服务等)之间的相依性。功能模型不描述特定服务内的客户机/服务器关系。另外，功能模型既不考虑哪些具体的产品已被选择来实现服务，也不考虑它们的实际配置。功能模型建立主要的约束条件，其它模型(下面说明)被捆绑到所述主要约束条件上，即，其它模型可相对于具体的系统基础结构，改进在功能模型中定义的相依性，但是不应在服务类别之间引入新的相依性。该模型非常紧致和普通，并且最好保存在管理系统上。

(b)结构模型：在一个优选实现中，结构模型包含实现在功能模型中定义的服务的软件组件的详细描述。结构模型提供在安装/部署阶段内捕捉的细节，并通过考虑具体系统的软件目录，补充功能模型。结构模型提供与在特定系统上安装和配置了哪些服务相关的信息，并且对于每种服务，系统是起客户机的作用还是起服务器的作用的信息。可能数目极大的系统和服务使得难以从远程位置跟踪这些相依性。从而最好是把该模型保存在被管理的资源附近或其上。

(c)操作模型：在一个优选实现中，当软件包被实例化，并且建立了服务和应用之间的绑定时，产生相依性的操作模型。该模型的高度动态特性和涉及的大量系统限制了完整模型可被实例化和保存的程度。定义并保存这样的模型不切实际，相反，必须动态地逐步计算该模型。于是应要求计算操作模型，并且操作模型依赖于功能模型和结构模型。

在大规模分布式系统中，相依性的数量和它们的动态特性极高。本发明的特征使它们对分布式系统(就资源和带宽利用率来说)的影响尽可能地小，并给用户留下同样多的可能影响性能的配置选项。这样的配置选项的例子是：取回更新的相依性模型的时间间隔，应跟踪其相依性的系统的范围，相依性模型的深度(仅仅立即受影响的服务-指定服务的传递闭包-整个服务层次)。

本发明最好使用相依性信息的下述特征：

(a)不同服务之间的相依性被分层。此外，它们的相依性图是有向的，不是循环的。后一陈述还反映基于IP的连网服务，例如DNS(域名系统)，NFS(网络文件系统)，DFS(分布式文件系统)，NIS(网络信息系统)等方面的经验，但是可能具有在一些系统中发生彼此相依性的情况。这种彼此相依性的一个习以为常的例子是从远程系统安装其中保存其DNS配置的文件系统的DNS服务器。虽然这样的配置在技术上是可行的，不过它反映了系统设计中的缺点，因为这导致其自举可能不确定的不稳定系统，从而应被避免。发现循环相依性的相依性检查应用应向管理员发出警告。

(b)在客户/提供商域边界，每个相依性是可见的，并且借助SLA使之清楚。它遵循可观察的相依性的数目是有限的。

(c)相依性模型允许相依性链的自顶向下的遍历。

(d)不同系统之间(“系统间”)的相依性被理解成相同服务的客户机部分和服务器部分之间的相依性。服务A的客户机不可能向提供不同的服务B的服务器发出请求。

本发明的一个目的是主要从少数公知/良好定义的地方(例如系统管理员)取回信息，以便最大程度地实现与具体的服务/应用手段的无关性。为此，本发明定义最少限度并且足量的公共可用的相依性信息。

本发明包括持久保存相依性模型，或者把相依性模型交给管理应用或使用本发明的另一服务自行决定。

允许本发明具有历史的概念，以便检测和确定相依性模型中的变化。这种情况下，本发明提供一个公布/预订接口，用于通知先前已记录相依性模型内的变化的软件组件。本发明的另一种可能应用是把相依性模型中的变化的检测交给定期调用本发明的管理应用(或者变化管理服务)自行决定，以便确定在相依性模型中是否发生了变化。

此外，如下举例说明的那样，本发明提供识别服务中断的根原因，并执行恰当的问题确定程序的技术。找出服务中断的根原因涉及从上向下遍历服务相依性图，从而识别可能已经历某一问题(该问题随后被传播给所考虑的服务)的候选服务。从观察到中断或退化的服务朝其前身的这种遍历取回特定服务直接相关的实体，或者递归选择为了正确地工作，该服务需要的完整一组节点(包括子前身)。根原因分析器收到的节点列表使其能够在第二步骤中执行特定的问题确定例程来检查这些服务是否可供使用。这些问题确定程序涉及确定某一服务是否正确地工作。可按照下述任意一种方式执行问题确定程序：

(i)逐步地，即，对返回的每个单个服务进行功能测试，或者

(ii)组合地，即，首先获得前身服务的整个列表(或者操作模型的子集)，同时对所有前身服务进行问题确定程序。进行这些测试的顺序可由根据服务之间的相依性的强度计算的优先值来确定，服务之间的相依性的强度又被表示成与这种相依性相联系的权重。

如上所述，为了确定服务是否正在正确地工作，可使用问题确定程序。用于分布式服务和应用的问题确定程序的例子包括(但不限于)：

(i)进程检查：对于实现服务的应用软件来说，确定它们是否正确工作的一种方式是核实它们的进程(后台驻留程序)是否正在运行。这可通过检查操作系统的进程表(或任务列表)，以非侵入的方式来实现，不需要应用的任何改编。如果应用的进程正在运行，那么认为该应用处于健康的状态。

(ii)训练某一应用是一种侵入式的并且更准确的确定应用是否充分工作，即运行，并执行应用的业务功能的方式。“训练者”是从应用外部调用的事务或命令，所述事务或命令以相当完全的方式训练该应用，以确定应用是否真正有效，并且能够即时地传递其功能性。所训练的是应用本身的某一功能。连网方面的类推是借助ICMP(因特网控制消息协议)“ping”命令测试连通性，所述“ping”命令向资源发送打上时间戳记的IP(因特网协议)分组。这些分组由资源返回，从而允许系统确定资源是否有效，并测量往返路程时延。

(iii)心跳允许应用证明它有效并且情况良好。通过自动并且重复产生事件，应用定期宣布它处于良好的工作状态。监听心跳的系统必须明白如果在心跳事件之间超时周期期满，那么应用可能没有正确地工作。

(iv)状态指示符是应用的专用管理变量，它反映实现某一服务的应用的当前状态。查询一个或多个状态变量可指出服务的总的健康状况。但是，这种方法要求通过向外界揭示该信息，恰当地改编应用。

此外，可基本同时地对一个或多个对象组件(例如每次对一个组件，或者并行地对多个组件)执行本发明的根原因确定方法。本发明的根原因确定方法的至少一部分结果可被持久保存，但是，可以不持久保存这样的结果。另外，可保持与本发明的根原因确定方法相关的结果的历史。这样的历史可被用于得到试探法，所述试探法用于随后确定判定根原因的一系列步骤。例如，根据历史可确定最常见的中断的分级，下次调用根原因分析时，首先检查过去最频繁发生故障的那个组件。

在根据本发明产生的上述实现和与本发明相关的一般特征下，剩余的详细说明将在图1～15的语境中，举例说明用于完成这样的实现和特征的技术。

首先参见图1，图1的方框图图解说明呈客户机-服务器应用结构的电子商务系统的例子，本发明的特征能够与所述客户机-服务器应用结构交互作用，从而产生信息。下面将说明图1的结构，举例说明在不存在本发明的技术的情况下，这样的结构如何处理交易。

如图所示，客户机系统105被用于发起请求，例如借助键盘。但是，可借助任意常规方法，例如借助鼠标点击、语音命令、读条形码等发出请求。客户机系统105的例子是个人计算机，信息站，数据输入终端，扫描仪，电话机，寻呼机，手持式或可佩戴的装置，无线装置，个人数字助手，具有网络功能的手表等。

在请求被明确表述和通过网络110，以及通过一个或多个网络接入设备115被转发给web应用服务器120的情况下，在本地对请求起反应。网络110和通信协议的一个例子是依靠越过局域网(LAN)的TCP/IP(传输控制协议/因特网协议)传送的基于套接字的通信，所述局域网(LAN)借助网络接入设备115(例如路由器和交换机)与广域网连接，所述广域网包含产生到服务提供商，最终到web应用服务器120的虚拟线路的许多交换位置。web应用服务器120的例子是高端个人计算机，基于RISC的PowerPC，基于UNIX的工作站，运行即时回复来自客户机的请求，并且在适当的时候，把请求分发给恰当的后端数据库服务器的微型计算机或大型计算机。

为了便于举例说明，现在将说明在(运行于客户机系统105上的)web浏览器内启动的，利用因特网购买物品的电子商务交易。要明白本发明的技术可以和任意形式的交易一起工作。web应用服务器的例子包括(但不限于)可从IBM公司获得的商标为WEBSPHERE的web应用服务器，可从BEA Systems公司获得的商标为WEBLOGIC的web应用服务器，或者可从Lotus获得的商标为LOTUS DOMINOSERVER的web应用服务器。

在例证的交易中，web应用服务器120的业务逻辑处理输入的请求，并验证和/或识别客户机系统105。一旦web应用服务器120实现的业务逻辑确定客户机可继续进行所述购买，那么它通过网络123把另一请求传递给数据库服务器125，以便递减库存。数据库服务器125处理该请求，访问其数据库130，并准备给web应用服务器120的响应。数据库服务器的例子包括(但不限于)Microsoft销售的商标为SQL/SERVER或TRANSACTION SERVER的数据库服务器，和IBM公司销售的商标为DB2 UNIVERSAL DATABASE SERVER的数据库服务器。

web应用服务器120接收来自数据库服务器125的响应，并通过网络110把所述响应返回给客户机系统105。客户机系统105随后处理所述响应，格式化该响应以便显示，并向交易发起者呈现该响应以便检查。

管理员100观察位于服务提供商的地点的处理商业交易的各个软件和硬件组件，确定它们是否正确工作。如果在数据库130发生服务中断135，例如被破坏的表空间或者数据库运行时间系统的故障，那么管理员100的任务是查找所述服务中断的原因，纠正该问题，并核实整个系统是否再次正确地工作。要明白本发明意图处理任意形式的服务中断或性能退化。

管理员100直接地或者通过管理系统与软件和硬件组件交互作用，所述管理系统在良好定义的管理接口，处理由软件和硬件组件暴露的管理信息(例如状态和健康数据)。在任何一种情况下，重要的是注意硬件和软件组件被管理员理解为隔离的资源，而不是服务于特定商业用途的整个系统的一部分。

特别地，在一个组件中发生的错误可能不被注意，因为由于缺少连续监视的缘故，管理员不知道所述错误。另外，在缺少本发明的技术的情况下，管理员不能直接获得有关各个组件之间的相互依存的明确信息。从而，在故障传播到被监视的组件之前，未被连续监视的组件内的错误可能被忽视。

就上面提及的数据库中断135来说，只有如果web应用服务器120不再正确地工作(例如，web应用服务器上的负载急剧增大，因为它持续重试连接数据库服务器125，并且不能完成客户机系统105发送的请求)，管理员才在最终知道该中断。从而，管理员100会首先检查web应用服务器120，随后确定是否存在网络123连通性问题，最好核实数据库服务器125是否正在经历可能起源于数据库130中的内部错误的困难。

上述客户机-服务器应用结构可被看作合并被IBM公司称为“自主”计算环境的计算环境的先驱。P.Horn的“Autonomic Computing：IBM′Perspective on the State of Information Technology”(IBMResearch，October 2001，其公开内容作为在此引为参考)把自主计算定义为对于具有最少人类干预的自我管理计算系统的全面并且完整的方法。该术语来源于身体的自主神经系统，自主神经系统在不存在有意识的知晓或牵涉的情况下控制关键功能。更具体地说，自主计算的目的之一是使管理员100通常会执行的一些或全部任务自动化。这样做的动机如下。

随着计算的发展，重叠的连接、相依性和交互作用的应用要求比任何人所能传递的更快的管理决策和响应。查明故障的根原因变得更困难，同时增大系统效率的查找方式产生具有比任何人能够希望求解的变量更多的变量的问题。可用下述方式表征识别并跟踪自主计算环境的不同系统之间的相依性的问题。由于系统能够存在于许多层次，因此为了管理自身，自主系统需要有关其组件，当前状态，最终容量，以及与其它系统的所有连接的详细信息。本领域的技术人员会认识到可在自主计算环境中实现本发明。

现在参见图2A，图2A的方框图图解说明根据本发明的一个实施例，提供相依性管理的系统。更具体地说，图2A描述致力于上述问题的相依性管理系统。该系统包括四层(应用层200，服务层205，中间件层210和资源层215)和一个管理员图形用户界面285，管理员100借助管理员图形用户界面285与系统交互作用。

最下面的一层是资源层215。资源层215包括被管理的资源220，资源相依性仓库225和仓库代理230。被管理的资源220包括(但不限于)物理和逻辑硬件组件(前者的例子是硬盘、随机存取存储器、中央处理器、网络适配器、通道控制器等；后者的例子是磁盘分区、文件系统等)，和软件组件(例如操作系统，类似于打印后台处理或名称服务之类的系统服务，以及最终用户应用)。

资源相依性仓库225包含每个被管理资源220的硬件和软件组件的目录，和基于每一资源的相依性信息(即，被管理资源220内的组件之间的相依性)。资源相依性仓库225可和每个单独的被管理资源220位于同一位置，或者存在于集中的位置。通过仓库代理230可查询、更新和修改资源相依性仓库225，仓库代理230使系统的其它组件能够获得资源相依性仓库225的信息。

中间件层210包含管理通信基础结构235，例如协议和对象请求中介，系统的不同组件通过所述协议和对象请求中介交换(管理)信息。

服务层205包含可被各种管理应用使用的各种类属管理服务250，例如策略、事件和目录。一种特别重要的服务是相依性服务245，相依性服务245既从被管理的资源220，又向仓库代理230取回信息，并处理所述信息，建立整个资源环境的端对端相依性模型。根据相依性服务245的需要(例如高速缓存，以便更快地取回)，该模型(或其多个部分)被保存在端对端相依性仓库240中。注意相依性服务245是所描述的系统中直接与端对端相依性仓库240交互作用的唯一组件。

要认识到可根据在上面引用的并且同时提交的美国专利申请(代理人案卷号no.YOR920020097US1)“Methods And Apparatus ForManaging Dependencies in Distributed Systems”中公开的技术产生上述相依性模型及其各个部分，下面提供其的一些例证细节。但是，可以采用其它模型产生技术。

应用层200包含使用类属管理服务250和/或相依性服务245的各种管理应用。这种管理应用的例子包括(但不限于)故障管理器260、拓扑产生器265、影响力分析器270、影响力模拟器275和根原因分析器280。

如同下面所述，根原因分析器280根据从受中断影响的组件朝着其前身经过(相依性服务245提供的)相依性模型，确定中断的根原因(即，最初导致该中断的组件)。

影响力分析器270根据从经历中断的组件朝着其前身经过(相依性服务245提供的)相依性模型，确定中断的影响力(即，可能受到该中断的影响的组件)。影响力分析器可采用在上面引用的并且同时提交的美国专利申请(代理人案卷号no.SOM920020004US1)“Methods And Apparatus For Impact Analysis and ProblemDetermination”中公开的技术。不过，也可采用其它影响力分析技术。

根据影响力分析器270，影响力模拟器275通过模拟整个系统上的特定组件的停机的影响，允许管理员进行假设分析。这使得能够预备恰当的故障修复解决方案。影响力模拟器可采用在上面引用的并且同时提交的美国专利申请(代理人案卷号no.SOM920020005US1)“Methods And Apparatus For Dependency-based Impact Simulationand Vulnerability Analysis”中公开的技术。不过，也可采用其它影响力模拟技术。

故障管理器260对已由根原因分析器280或影响力分析器270识别成故障候选者的组件执行恰当的“健全性检查”或测试。即，故障管理器能够依据根原因分析器280或影响力分析器270的指导进行这样的测试(即，充当这些模块的接口)，并向它们返回结果。但是，根原因分析器280或影响力分析器270能够自己进行测试，不依赖于故障管理器。

要明白故障管理器最好由许多应用专用或资源专用工具组成，所述应用专用或资源专用工具允许确定正被测试的组件是否正确地工作。故障管理器可返回一个消息，指示组件是在“工作”还是“没有工作”。这些工具可以是自动的和/或手动的。作为自动化的一个例子，所谓的“ping”程序检查网络连通性。如果对象远程系统答复ping，那么该远程系统在线，其网络协议栈(以及所有的底层硬件，例如网络适配器，电缆，中间网络组件等)工作。如果远程系统不答复，那么知道至少某物出错，可采用另一(组)工具来确定该问题。从而，故障管理器可采用ping程序，以及所需的任意数目和类型的其它工具来测试分布式计算环境的组件(例如，心跳检测，状态指示等)。

拓扑产生器265建立分布式系统的总体拓扑(的子集)，分布式系统包括大量高度动态的组件，例如web应用，数据库实例和交易。使用拓扑产生器265的一个例子是显示与完成特定客户机系统105的请求有关的分布式系统的组件。根据拓扑产生器265的需要(例如高速缓存以便更快地取回)，相依性模型(或相依性模型的多个部分)被保存在拓扑数据库255中。注意拓扑产生器265是所述系统中直接与拓扑数据库255直接交互作用的唯一组件。拓扑产生器可采用在上面引用的并且同时提交的美国专利申请(代理人案卷号no.SOM920020003US1)“Methods And Apparatus For TopologyDiscovery and Representation of Distributed ApplicationsandServices”中公开的技术。不过，也可采用其它拓扑产生技术。

现在参见图2B，图2B表示了图解说明了计算机系统的一般硬件体系结构的方框图，所述计算机系统适合于实现提供附图中描述，并在这里详细说明的相依性管理的系统的各种功能组件/模块。显然相依性管理系统的各个组件，即，与图形用户界面285，应用层200，服务层205和中间件层210(图2A)相关的组件可在具有如图2B中所示的体系结构的一个或多个计算机系统上实现。图2A中所示的其它组件，例如与资源层215相关的组件也可在类似的计算机系统上实现。

如图所示，可根据处理器290、存储器292和I/O装置294实现计算机系统。要认识到这里使用的术语“处理器”意图包括任意处理装置，例如包括CPU(中央处理器)和/或其它处理电路的一个处理装置。这里使用的术语“存储器”意图包括与处理器或CPU相关的存储器，例如RAM、ROM、固定存储装置(例如硬盘驱动器)、可拆卸的存储装置(例如磁盘)、快速存储器等。另外，这里使用的术语“输入/输出装置”或“I/O装置”意图包括例如把数据输入处理单元的一个或多个输入装置(例如键盘)，和/或呈现与处理单元相关的结果的一个或多个输出装置(例如CRT显示器和/或打印机)。

另外要明白术语“处理器”可以指的是一个以上的处理装置，并且与处理装置相关的各种部件可被其它处理装置共享。

因此，如同这里所述，包括用于实现本发明的方法的指令或代码的软件组件可被保存在一个或多个相关的存储装置(例如ROM、固定存储器工可拆卸存储器)中，并且当准备好被使用时，由CPU部分或整体装入(例如RAM中)并执行。

现在参见图3，图3的方框图图解说明根据本发明的一个实施例的服务的功能相依性模型。更具体地说，图3描述了诸如图1中所示的电子商务系统中的各个组件之间的功能应用相依性图。该功能相依性模型表示了分布式系统的功能组件以及它们的相依性。从而，该模型定义类属服务之间的相依性，从商业的观点来看，所述类属服务被认为是基本的。这意味着功能模型不与在商业服务内发生的相依性有关。这样的分解在被用于实现服务的特定产品的范围中讲得通，下面将参考图4更详细地讨论。

组件之间的相依性被描述成箭头。箭头总是从从属物指向前身。功能组件是服务提供商需要部署，以便向客户提供端对端服务的(子)服务，在服务级协议中定义了端对端服务。功能模型集中于端对端服务的设计，并从端对端服务的技术实现的细节，例如用于服务提供的产品，它们的位置(本地或远程系统)，提供商域(即，提供商本身是否向对客户透明的另一服务提供商外购其一些服务)等抽取。

如图所示，电子商务应用300服务依赖于用于宿主业务逻辑的web应用服务305。为了正确地工作，web应用服务需要另外两种服务。电子商务网站的静态内容由web服务310提供，而后端数据库服务330保存正向客户提供的电子商务应用300的动态内容(例如产品说明，用户和制造商数据，购物卡，用户简介和偏爱，付款信息等)。web服务310本身依赖于两种服务，即，把主机名称变换成IP地址的名称服务315，和用于网络连通性的IP服务320。

相依性关系是可可传递的，即除了指定组件本身之外，指定组件的从属物还需要该组件的前身。从而，除了IP服务320和数据库服务330之外，所有所述服务都需要操作系统(OS)325服务的存在。为了简洁起见，没有描绘OS 325对硬件组件的相依性关系，不过在功能模型中存在这样的相依性关系。

现在参见图4，图4的方框图图解说明根据本发明的一个实施例的服务的结构相依性模型。更具体地说，图4描述诸如图1中所示的电子商务系统中的各个组件之间的结构应用相依性图。

结构相依性模型按照下述方式扩展功能模型(图3)。结构相依性模型涉及商业服务的实现，并且集中于具体产品和它们的逻辑(模块、组件)和物理(文件、共享库)体系结构。结构相依性模型捕捉软件组件的详细描述，即系统详细目录，所述软件组件的详细描述通常记录在各种系统仓库中，或者记录在良好定义的地方，例如被管理资源220的配置文件中。

注意虽然结构模型涉及单个系统的组件，它可保持对其它系统宿主的服务和应用的引用，因为位于该系统上的配置文件可包含该信息。系统仓库的例子包括(但不限于)IBM AIX Object Data Manager(ODM)，Linux Red Hat Package Manager(RPM)或MicrosoftWindows Registry。通常在软件包的安装和布置期间捕捉与软件组件相关的信息。另外，结构模型包含各种系统组件之间的描述成箭头的相依性。为了清楚起见，在图4中，不带引号地记录商业服务的名称，而带引号地记录结构模型的部件的名称。

具有完全合格的域名wslab8.watson.ibm.com 400的系统宿主下述组件：电子商务应用(在功能模型中定义的商业服务)，它被实现成铺面servlet 410，后者封装该应用的业务逻辑。web应用服务由IBMWebSphere版本3.5 415实现，而web服务由IBM HTTP Server版本1.3.6 420实现。IP服务由默认的IP协议栈430实现，操作系统(OS)是Win(dows)NT版本4 425。

具有完全合格的域名rslab2.watson.ibm.com 405的系统宿主下述组件：由(IBM)DB2 Universal Database(UDB)版本5.2 435实现的数据库服务，和操作系统，这里是(IBM)Advanced InteractiveExecutive(AIX)版本4.3.3 440。

现在参见图5，图5的方框图图解说明根据本发明的一个实施例，由功能、结构和操作相依性模型论述的服务生命周期。更具体地说，图5描述上述功能模型500和结构模型510之间的关系，并且引入第三种相依性模型，即操作模型520。这三种模型使本发明能够在服务的整个生命周期，即从设计阶段到安装和部署阶段，再到操作或运动时间阶段内跟踪服务。

如上所述，功能模型500与商业服务的设计相关，从而在设计商务系统时被捕捉。一旦由功能模型500描述的系统被实例化或部署(步骤505)，那么就建立结构模型510。当结构模型510的各种组件被实例化(步骤515，并且当建立了它们之间的运行时绑定时，产生操作模型520。操作模型表示前面描述的组件在运行时间的特征。现在描述举例说明上述概念的几种情形。

web应用服务305由IBM WebSphere 415实现；后者的一个或多个实例被称为websphere-daemon 545。这里，web(或WWW)服务310由两种产品，即Apache 1.3.4 525和Lotus Domino 530实现。这些产品的运行实例可被识别成http后台驻留程序“httppd”550。数据库服务330由两种产品实现，即，Oracle v7 535和DB2 UDB 435；但是，Oracle v7 535的实例都无效，因为在操作模型520中看不到任何服务器进程。相反，从操作模型520中四个DB2后台驻留程序“db2d”555的存在可看出，DB2 UDB 435的四个实例正在运行。名称服务315由BIND版本5.6 540实现；BIND的运行实例可被视为操作模型520中的“被命名”560。

注意相依性从功能模型传播到结构模型和操作模型。这是必然的，因为不可能从运行的应用实例确定为了正确地工作，它需要哪些其它应用实例。

由于一些应用实例的生命周期较短，操作模型520高度动态，并且可能很大。与功能和结构相依性模型相反，操作模型520并不保存在仓库或数据库中，而是应要求和在所需的程度上被计算。

现在参见图6，图6的方框图图解说明根据本发明的一个实施例，功能相依性模型、结构相依性模型和操作相依性模型之间的关系。更具体地说，图6举例描述用于这三种相依性模型的数据模板和把这三种模型绑在一起的手段的细节。该例子详细说明了在名称服务的生命周期内，描述名称服务的模板及其关联值。

用于功能模型500的功能模板605包含“hostname”(宿主服务的计算机系统的唯一名称)，“serviceName”(服务的名称)和“componentType”(该服务扮演的角色，即客户机或服务器)。借助该信息，在分布式环境中能够唯一地识别服务。但是，在不脱离本发明的精神的情况下，可以增加包含描述数据的其它字段(例如服务用途的说明，预订该服务的客户等)。最后，“Antecedent”字段包含为了正确地工作，该服务所需的其它服务。

用于结构模型510的结构模板610包含功能模板的所有字段，这允许链接功能模板605和结构模板610，以便从功能模型500行进到结构模型510，反之亦然。另外，结构模板610包含“componentName”(产品组件的名称)，“identifier”(用于识别组件的全局唯一名称)，“version”、“release”和“modification”(例如，维护或修补/安装级别)号，“installState”(指示组件是否已被成功并且完整地安装)，和“processName”(在运行时间识别该产品组件的进程的名称)。此外，“Antecedent”字段列举为了能够工作，该组件所需的其它组件。

用于操作模型520的操作模板615包含字段“hostname”(宿主服务的计算机系统的唯一名称)和“processName”(在运行时间识别该产品组件的进程的名称)。这两个字段连接结构模板610和操作模板615，以便从结构模型510行进到操作模型520，反之亦然。另外，操作模板615包含字段“operState”(进程的操作状态，即，运行、中断、僵等)，“portNumber”(通过其应用能够与该进程连接的TCP/UDP端口的号数)，和“instanceID”(用于区分计算机系统的范围内的各种应用实例)。

在不同的地方保存和计算这三种相依性模型，以便获得最大程度的效率。功能模型500被收集并保存在管理系统620，即，管理员100通过其与分布式环境交互作用的控制中心点。这种选择的一些原因如下。从图3和图5的说明中可看出，功能模型500相当紧致，因为可能的商业服务的数量有限。另外，功能模型不会经历过度频繁的变化。在商业服务被提供给客户时定义功能模型，并且在服务提供周期结束之前保持不变。由于管理员100负责设置并更新功能模型500，因此自然选择把功能模型500保存在管理系统620附近。

相反，如同在图4和图5的说明中所述，结构模型510捕捉软件组件的详细描述，即系统详细目录，它通常被记录在各种系统仓库中，或者记录在良好定义的地方，例如被管理资源220的配置文件中。从而，结构模型510规模既大(系统仓库的内容往往会在数百千字节到几兆字节之间)，并且还频繁变化。于是，把系统的结构模型510保持在被管理资源220本身消除了更新该模型的通信开销，又避免了对大量存储空间的需要，如果所有被管理资源(220)的结构模型510被保存在中央位置，那么会产生这种需要。

在图5中，操作模型520已被描述成非常动态，并且还极大，因为它可能覆盖存在于分布式环境的计算机系统上的每个应用的多个实例，以及它们之间的相依性关系。在已知因特网/应用/存储服务提供商和外包商的当前数据中心由几千个计算机系统组成，每个计算机系统宿主接近100个应用和系统服务的事实的情况下，包含所有当前实例化的应用和它们的相依性的操作模型可能不切实际。从而，一种实际的方法是应要求计算操作模型的相关部分(步骤625)。这是相依性服务245的目的。

现在参见图7，图7的方框图图解说明根据本发明的一个实施例，与根据动态信息技术(IT)服务相依性，分析和计算服务中断的根原因有关的组件。更具体地说，图7描述了用于分析和计算这样的根原因的各个组件之间的数据流。假定被管理的资源220能够提供它们的系统详细目录，配置文件和它们的各种相依性的XML(可扩展置标语言)描述。但是，应注意根据本发明可使用任意数据描述格式。如何能够获得该信息的细节如下所述。

一种直接的方式是提供系统内的适当instrumentation，及其应用和服务。在普通的XML文件740中描述该信息，并且通过web服务器725，系统的其它组件能够获得该信息。

另一方面，相依性服务245利用保存在系统仓库745中的信息产生恰当的服务相依性信息。通过web服务器730，系统的其它组件能够获得该信息。

第三，被管理资源220借助称为CIM(公共信息模型，它是一种标准化的管理架构)提供者750的instrumentation代理揭示它们的信息，CIM提供者750与CIM对象管理器(CIMOM)735交互作用，如同分布式管理任务组(DMTF)提出的那样。CIMOM随后向感兴趣的组件揭示必需的信息。

在图7的中央，描述了作为服务层205一部分的各种管理服务。这些服务是：名称服务700，交易者服务710，事件服务715和相依性服务245。由利用通信协议(例如Java远程方法调用(RMI))，管理员100的查询通过根原因分析器280，其管理系统或位于应用层200中的任意管理应用触发的相依性服务245处理所述查询，并把结果回送给根原因分析器280，根原因分析器280再把结果转发给管理员100以便进一步处理。相依性服务245的主要任务如下：

(a)与管理系统或位于应用层200中的任意管理应用交互作用。管理系统向相依性服务(245)的应用编程接口(API)发出查询。

(b)揭示“下钻”方法，当收到服务的标识符时，所述方法返回：

(i)其直接前身，即表现该服务的节点之下的第一级的描述，或

(ii)表现该服务的节点这下的整个子图，

(iii)相依性图的任意子集(指定节点之下的第m级～第n级)。

(c)以服务的相依性为目标，提供具有相同功能的“上钻”方法。

(d)提出收集和过滤被管理对象的类别和性质信息的其它方法。

(e)通过发出HTTP(超文本传送协议)查询，并对其应用过滤规则(由管理员100规定)，从被管理资源220获得相依性信息。

(f)把信息组合成以XML文档的形式，回送给管理系统的数据结构。

如上所述，由于它的充分分布本质，本发明的目的在于使每个所涉及的系统上的负载尽可能地低。本发明把管理系统和被管理资源220分离开来，并把费时的过滤和结合操作封装在可在各个系统上复制的相依性服务245中。于是，对于查询操作，能够实现最大程度的并行化，因为管理系统能够灵活地选择相依性服务245的实例。

另一重要优点在于(很大并且高度动态的)操作模型520并不保存在特定的地方，而是应要求逐步计算。结构模型510的不同部分被保存在被管理资源220。于是，管理系统总是收到最新的信息，不过仍然可以根据精心设计的高速缓存策略，自由地保存收到的最新信息。

现在参见图8，图8的方框图图解说明根据本发明的一个实施例的根原因分析器的组件。如图所示，起整个根原因分析进程的流程协调器作用的根原因相关器870从管理员100接收提供已观察到或报告问题的服务的名称和主机名称的服务问题报告880。根原因相关器870与相依性服务245交互作用，以便获得存在问题的服务所依赖的基本服务的列表。基本服务的例子可以是：城名服务，IP连通性服务等。

相依性服务245的任务是找出所考虑的服务的前身，即使电子商务环境跨越不同的被管理域800。为了应付多个域，相依性服务245的各种(级联)实例可一起共同工作。在图8中，电子商务环境由虚线矩形表示。一般，这样的环境包含一个或多个被管理域，最后每个域具有它自己的相依性数据库810和相依性服务245。相依性服务245把前身的名称和标识符返回给根原因相关器870，根原因相关器870随后启动另外的问题确定程序来核实是否一个或多个前身正在经历困难。这可通过许多方法来实现，下面举例说明其中的一些方法。

第一种方法假定由事件监视器820提供的事件监视和分配功能的存在。这种事件监视器的例子包括(但不限于)HP OperView EventServices和Tivoli Enterprise Console。事件监视器820接收与电子商务环境内的资源相关的事件/警报，并把相关的那些事件/警报转发给事件数据库830。一些事件在本质上是信息，或者与域管理服务自动解决的错误相关。这些事件通常被滤除，不被转发给事件数据库830。实际上，事件监视器820可包括多个事件监视器的分层排列，每个事件监视器用于一个被管理域。

事件服务相关器870的主要功能是关于指定服务或资源，提供与该资源或服务相关的未解决的警报的列表。它通过与事件监视器820交互作用来提供所述列表，并把事件保存在事件数据库830中以便未来取回。当相依性服务245返回的服务是怀疑的根原因之一时，根原因相关器870使用事件-服务相关器840，通过获得关于怀疑的服务或资源报告的事件的列表，估计被怀疑的原因正是问题的根原因的可能性。如果存在不合需要的事件，例如缓冲器溢出，那么该资源是根原因的可能性较高。

根原因相关器870还关于每个被管理域，与相依性服务245交互作用，以便获得存在于该域内的一组可能根原因。相依性服务245与域相依性数据810交互作用，域相依性数据810在部署期间构成，并在电子商务设置的操作阶段内被定期重新。

第二种方法是从状态监视器860获得服务或资源的当前状态，状态监视器860直接与服务交互作用，核实它们是否正在正确地工作(例如，发生故障，未发生故障，退化等)。如上所述，如果系统包括故障管理器(如图2A的系统那样)，那么状态监视器可充当根原因分析器和故障管理器之间的接口，以便除了其它优点之外，还使根原因分析器与任意特定的测试程序无关。状态监视器860于是可充当根原因相关器870确定所考虑的服务的健康状态的单独联系点。

一般，不能假定总是存在外部故障管理器。但是，由于确定服务状态的功能对根原因分析器来说至关重要，因此该功能必须存在，并由状态监视器860提供，状态监视器860可扩展故障管理器提供的功能。从而，外部故障管理器可以：

(a)提供所有所需的功能(从而，状态管理器将“包裹”故障管理器执行的功能，并把接口修改成根原因相关器870希望的那样)；

(b)可提供所述功能的一部分(例如只提供网络连通性的测试，而不提供应用和中间件状态核实)，从而，所需的功能必须由状态监视器提供；或者

(c)根本不提供任何功能；它要么不存在，要么不通过编程接口把它的功能提供给其它组件。这样，虽然用户能够通过GUI(图形用户界面)与故障管理器交互作用，但是没有程序(例如相关器870)能够使用它。

另外注意故障管理器意欲指的是具有完全不同接口的松散的一批系统管理工具。从而，状态监视器用于在统一的接口下整合这些各种工具。即，状态监视器最好说明对于状态来说，预期一切都是可测试的根原因相关器和可提供介于0％和100％之间的这种所需功能的故障管理器之间的任意失配。

从而，根原因相关器870具有两种方式来确定某一服务是否正在正确工作或者存在问题，即，相关器能够关于与服务相关的问题事件报告查询事件-服务相关器840，或者直接从状态监视器860查寻服务的状态。根原因相关器870可以自由地选择它借助这些至少两种方法中的哪一种来确定服务的健康状态。此外，根原因相关器870可选择从事件-服务相关器840获得信息，和从状态监视器860获得信息。

在根原因已被缩小到最小的一组可能服务和资源之后，根原因相关器870把该信息890返回给管理员100。

现在参见图9，图9的流程图图解说明根据本发明的一个实施例，调用相依性服务，并对操作模型执行根原因分析的步骤。更具体地说，图9描述了调用相依性服务(例如相依性服务245)，收集其结果，并对所述结果应用根原因分析的方法。该方法或者由管理员100启动，或者由作为如图2A中所述的应用层200一部分的管理应用启动。

该方法开始于方框900，并如下继续进行。首先，选择商业服务(步骤905)，一般从功能模型中选择，因为管理员对分布式系统提供的商业服务感兴趣。当选择了商业服务时，查询结构模型，以便提供对与提供该商业服务有关的主机的选择。这可通过查找存在于分布式系统的每个主机上的结构模型来实现，或者(出于效率的目的)通过查询保存在管理系统的(定期更新的)服务/主机查寻表来实现，所述服务/主机查寻表包含服务和存在于分布式系统中的主机之间的映射。管理员随后自行选择某一主机(步骤910)。

另外，管理员构成一个查询(步骤915)。查询参数的例子包括(但不限于)行进的方向(朝着服务从属物，或者朝着其前身)，行进的深度(例如，只是紧邻的前身/从属物；所有可能的前身/从属物，即，操作模型的完整传递闭包；只是操作模型的第m层和第n层之间)，或者与属性的存在相关，或者与它们的值相关的过滤准则。

这里规定选择服务(步骤905)，主机(步骤910)和构成查询的选项的步骤的顺序的事实强调本发明的“以服务为中心”方法(与现有技术的“以主机为中心”方法相对)。但是，本领域的技术人员会认识到在不脱离本发明的精神和范围的情况下，可对步骤的顺序做出修改(步骤905、910和915)。

这种修改的例子是：向用户提供(例如借助图形用户界面)以任意顺序执行选择进程的这三个步骤的机会；允许首先选择主机，随后通过查询结构模型，查寻存在于该主机上的服务，从而限制供选择的可能的候选服务。

在选择服务和主机以及构成查询之后，利用这些参数调用相依性服务(步骤920)。注意调用的模式可以是同步(即，阻止调用器，直到相依性服务返回结果为止)或者是异步(从而允许调用器在计算期间执行另外的任务)。

相依性服务计算操作模型的恰当部分，并根据调用的模式，或者把结果回送给调用器，或者向调用器通知结果可用。调用器随后收集结果，并对结果应用根原因分析和恰当的问题确定程序(步骤925)。随后在方框930结束该方法。

现在参见图10，图中的流程图图解说明根据本发明的一个实施例，管理员的产生和更新功能相依性模型的任务。如果部署和提供了新的(商业)服务，或者现有模型被改变，或者撤消提供现有的(商业)服务，那么这是必需的。

该方法开始于方框1000，并如上继续进行。管理员或管理应用评估是否应增加新的商业服务，或者某一现有服务是否要被删除(步骤1005)。如果不必增加或删除某一服务，那么该方法直接进行到方框1025。否则，在步骤1010中，在图6中说明的功能模型的模板605中输入(或者删除)该服务及其描述。

随后，在步骤1015中，服务相依性，即它的关于其前身的关系需要被加入功能模型的模板605中(或者从中删除)。就删除来说，注意自服务从属物的相依性需要被调整，以指向将被删除的服务的前身。这可涉及检查前身的相依性内的可能发生的重复描述。最后，更新后的功能模型被保存在管理系统的仓库中(步骤1020)。随后在方框1025结束该方法。

现在参见图11，图中的流程图图解说明根据本发明的一个实施例，通过在计算机系统上安装或除去硬件/软件组件，更新结构相依性模型的步骤。如果在主机上部署并安装了新的组件，或者从主机上除去了现有组件，那么这是必需的。

该方法开始于方框1100，并如下继续进行。如果新的硬件组件被安装/除去，那么通常由操作系统核实并调整它们的相依性，从而这里不再赘述。相反，下面的描述集中于添加/删除软件组件的任务。执行软件分发和安装的管理员或管理应用评估是否应增加新的软件组件，或者某一现有软件组件是否要被删除(步骤1105)。如果不需要，那么该方法直接进行到方框1125。否则，在步骤1110中，在图6中说明的结构模型的模板610中输入(或者删除)软件组件的描述。随后，在步骤1115中，软件组件的相依性，即它的关于其前身的关系需要被加入结构模型的模板610中(或者从中删除)。

就删除来说，注意自软件组件的从属物的相依性需要被调整，以指向将被删除的软件组件的前身。这可涉及检查前身的相依性内的可能发生的重复描述。最后，更新后的结构模型被保存在主机的资源相依性仓库中(步骤1120)。随后在方框1125结束该方法。

现在参见图12，图中的流程图图解说明根据本发明的一个实施例，对操作模型的根原因分析的执行。该方法开始于方框1200，并如上所述继续进行。对操作相依性模型执行根原因分析的系统持续监听其中执行该系统的主机的特定端口上的请求，它由连接步骤1205和它本身的循环表示。这是实现可由应用在任何时候调用的服务的服务器进程(“后台驻留程序”)的标准行为。

当收到请求时，系统从请求抽取输入参数(步骤1210)。如同在图9的说明中所述，输入参数的例子包括(但不限于)所考虑的服务和主机的名称，行进的方向，行进的深度，或者与属性的存在相关，或者与它们的值相关的过滤准则。这些输入参数随后被用于调用操作模型的计算，在步骤1215中调用所述计算。

另外，计算的结果，即操作模型被收集。随后对该操作模型进行根原因分析(步骤1220)。根据调用时规定的调用模式，根原因分析的结果被返回给调用应用(步骤1225)。在该步骤之后，释放其上运行该系统的主机上的任意已分配资源(步骤1230)。主机资源的例子包括(但不限于)存储器、磁盘空间或CPU寄存器。最后，系统返回其初始阶段，并监听后续的输入请求(返回步骤1205)。

现在参见图13，图中的流程图根据本发明的一个实施例，对服务的前身的根原因分析的执行。该方法开始于方框1300，并如下所述继续进行。

首先，获得目标服务和主机的名称(步骤1305)。这些参数由调用管理应用提供，调用管理应用或者直接从管理员，或者从到达管理控制台的事件消息获得这些参数。另外，规定与前身的状态相符的搜索标准。它们指示系统是应返回已遇到问题的服务(“有缺陷的服务”)还是应返回执行情况良好的服务。通常，管理应用对前者，即有缺陷的服务感兴趣。此外，规定搜索路径。管理应用可能对服务的直接前身感兴趣(搜索路径长度＝1)，对该服务直接(或间接)依赖的整个一组服务感兴趣(搜索路径＝递归)，或者对某一服务依赖的最底层前身，即基本服务感兴趣(搜索路径＝max)。

随后，根据参数“服务名称”、“主机名称”、“前身状态”、“搜索路径”，由相依性服务执行操作模型的计算(步骤1310)。随后，在步骤1315中，从相依性服务获得结果，即前身服务部件的列表(“候选者列表”)。

在候选服务部件的列表为空(1320)之前，执行下述步骤：

选择候选者列表的每服务部件(步骤1325)，并检查以确定它是否正确地工作(步骤1330)。在图14中详细描述了该状态检查程序的步骤。如果所考虑的服务部件正确地工作(状态＝“OK”)，那么把它加入工作服务部件的列表(即“OK”列表)中(步骤1335)。但是，如果证明服务部件正存在问题，那么它被加入“有缺陷”列表(步骤1340)。最后，从候选服务部件列表除去所考虑的服务部件(步骤1345)，方法随后返回步骤1320。

如果候选服务部件的列表为空，那么该方法随后直接进行到步骤1350，把工作服务部件的列表，或者缺陷服务部件的列表返回给调用器。结果内容取决于在步骤1305中，调用器是要求工作服务还是缺陷服务。随后在方框1355结束该方法。

现在参见图14，图中的流程图图解说明根据本发明的一个实施例，确定服务的状态的步骤。更具体地说，图14图解说明图8中描述的根原因相关器870与事件-服务相关器840和状态监视器860的交互作用。该方法开始于方框1400，并如下所述继续进行。

首先，获得目标服务部件的名称(步骤1405)。如同可由根原因相关器870完成的那样，从检查单个服务部件的状态的观点来描述该问题确定程序。要明白对所考虑的每个服务重复该程序。还要明白该程序在图13的步骤1330中执行。

另外，就步骤1405来说，目标服务部件的名称由调用管理应用提供，调用管理程序或者直接从管理员，或者从到达管理控制台的事件消息获得这些参数。

随后，根原因相关器870关于与所考虑的服务相联系的事件的存在，查询事件-服务相关器840(步骤1410)。这些事件指示是否已观察到关于该服务的任何问题。如果是，那么该服务部件被标记为“有缺陷”(步骤1415)，并且结果被返回给调用器(步骤1430)。

如果步骤1410确定关于该服务，没有发生任何故障事件，那么必须执行另外的工作来确定服务的状态。这是通过关于服务的状态，查询状态监视器860来实现的(步骤1420)。状态监视器860的任务包括向分布式系统中的每个服务的状态信息提供统一的接口，而不管服务的状态如何被确定。

如上所述，确定服务的状态的四种例证方式可包括：(i)进程检查；(ii)训练者；(iii)心跳；和(iv)状态指示符。如果对状态监视器860的查询(步骤1420)产生所考虑的服务正在正确工作(状态＝“OK”)，那么表现该服务的服务部件被标记为“OK”(步骤1425)。总之，结果被返回给调用器(步骤1430)。随后在方框1435结束该方法。

现在参见图15，描述了根据本发明的一个实施例的根原因分析器应用编程接口(API)的例子。该表包括能够产生、发送和请求接收指定服务的恰当工作模型和主机名称的基本API。本领域的技术人员会认识到API可使用一个或多个参数(未示出)来识别API使用的特征(在功能描述中规定)。

具体地说，“getDirectAntecedents(parameters)”API取回位于特定主机上的服务的直接前身，而不考虑它们的当前状态。“getAntecedentsRecursive(parameters)”API执行递归“下钻”，即，它取回位于特定主机上的指定服务的所有前身(而不管它们的当前状态)。于是，它返回相依性分级结构中存在于指定服务之下的所有服务。“getLowestAntecedents(parameters)”API取回位于特定主机上的某一服务的最底下的前身。这种方法产生本身不具有任何前身的服务(即，它们存在于指定服务的相依性分级结构的最下层)。

“getWorkingDirectAntecedents(parameters)”API取回位于特定主机上的某一服务的具有状态“up”的直接前身。“getWorkingAntecedentsRecursive(parameters)”API执行递归“下钻”，即，它取回位于特定主机上的指定服务的具有状态“up”的所有前身。于是，它返回相依性分级结构中存在于指定服务之下的所有工作服务。“getWorkingLowestAntecedents(parameters)”API取回位于特定主机上的某一服务的具有状态“up”的最底下的前身。这种方法产生本身不具有任何前身的服务(即，它们存在于指定服务的相依性分级结构的最下层)。

“getDefectiveDirectAntecedents(parameters)”API取回位于特定主机上的某一服务的具有状态“down”的直接前身。“getDefectiveAntecedentsRecursive(parameters)”API执行递归“下钻”，即，它取回位于特定主机上的指定服务的具有状态“down”的所有前身。于是，它返回相依性分级结构中存在于指定服务之下的所有故障服务。“getDefectiveLowestAntecedents(parameters)”API取回位于特定主机上的某一服务的具有状态“down”的最底下的前身。这种方法产生本身不具有任何前身的服务(即，它们存在于指定服务的相依性分级结构的最下层)。如果用户或管理应用打算快速确定任意“基本”服务(例如网络连通性服务)是否已发生故障，而不必核实“中间”服务(例如名称服务)的状态，那么这种API特别有用。

虽然参考附图说明了本发明的例证实施例，不过本发明显然并不局限于这些具体实施例，在不脱离本发明的范围或精神的情况下，本领域的技术人员能够做出各咱其它变化和修改。