用于因果关系模型的声明和消费的系统和方法专利检索-声明请求书国际申请第I章专利权专利检索查询-专利查询网

积极推动地理标志专门立法

2022-03-10 地理标志，立法，知识产权
保护知识产权是对创新最大的激励

2022-03-10 保护知识产权，创新，激励
谢商华：加快制定知识产权基本法

2022-03-10 知识产权基本法
擦亮“双奥之城”品牌

2022-03-10 双奥，知识产权
让冰雪运动“热”力全开

2022-03-10 冰雪运动，知识产权
携手共奋进　走好强国路

2022-03-10 强国，知识产权
坚持创新引领　方能稳中求进

2022-03-10 创新，稳中求进，知识产权
答好“两张卷” 奋进新征程

2022-03-10 知识产权
专家解读政府工作报告中的创新和知识产权相关部署

2022-03-10 政府工作报告，创新，知识产权
今年政府工作报告指出：加强知识产权保护和运用

2022-03-10 政府工作报告，知识产权保护

用于因果关系模型的声明和消费的系统和方法

阅读：1007发布：2020-06-20

IPRDB可以提供用于因果关系模型的声明和消费的系统和方法专利检索，专利查询，专利分析的服务。并且各实施例提供了一种用于表达系统实体的因果关系而不一定要求知道这些系统实体构成其一部分的特定系统的总体组成的因果关系模型。结合基于模型的管理技术使用的该因果关系模型能够允许按照特定系统实体所具有的与其他系统实体的关系来表达因果关系。这些其他系统实体可以是与对其表达该因果关系的实体共享一直接关系，或更一般地，共享一间接关系的实体。，下面是用于因果关系模型的声明和消费的系统和方法专利的具体信息内容。

权利要求

1.一种用于因果关系模型的声明和消费的系统，所述系统包括：由操作管理器接收或导入一个或多个管理包的装置，所述一个或多个管理包各自包括用于其基于模型的管理活动的组件，其中各个管理包的每一个包括：模型声明，所述模型声明表示描述管理包的组件及其特性以及它们是如何相关的抽象模型；

发现规则，所述发现规则描述了如何现实化所声明的模型并创建具有各个实体的具体模型；

监视策略，所述监视策略提供描述从模型声明中创建的具体模型的各个组成实体的状态以及各状态之间的转换的状态机；

因果关系模型，所述因果关系模型以不要求具体知道管理包构成其一部分的系统的实例的方式来表达管理包的特定系统中的因果关系；以及使根本原因分析引擎访问并利用由所述因果关系模型生成的数据来确定可观察的故障的根本原因的装置；

由所述操作管理器采用基于模型的管理系统来管理并监督一托管环境的装置，所述托管环境包括一个或多个计算设备能驻留于其中的任何合适类型的环境。

2.如权利要求1所述的系统，其特征在于，所述因果关系模型能声明对其他管理包的依赖性。

3.如权利要求1所述的系统，其特征在于，所述管理包包括描述与所述管理包相关联的一个或多个实体的状态的一个或多个状态机，并且其中，所述因果关系模型被配置成使用由所述状态机开发的状态信息来执行因果关系处理。

4.如权利要求1所述的系统，其特征在于，所述因果关系模型用XML来表达因果关系。

5.如权利要求1所述的系统，其特征在于，所述因果关系模型按照类模型来表达因果关系，并且其中，所述因果关系模型能用于通过对所发现的具体模型进行推断来计算因果关系。

6.如权利要求1所述的系统，其特征在于，所述因果关系模型可表达关于一特定可观察故障的多个不同的原因。

7.如权利要求6所述的系统，其特征在于，至少一个原因能与对其表达因果关系的相同的实体相关联。

8.如权利要求6所述的系统，其特征在于，至少一个原因能与不同于对其表达因果关系的实体的实体相关联。

9.如权利要求6所述的系统，其特征在于，至少一个原因能与不同于对其表达因果关系的实体的管理包中的不同实体相关联。

10.一种用于因果关系模型的声明和消费的计算机实现的方法，所述方法包括：由操作管理器接收或导入一个或多个管理包，所述一个或多个管理包各自包括用于其基于模型的管理活动的组件，其中各个管理包的每一个包括：模型声明，所述模型声明表示描述管理包的组件及其特性以及它们是如何相关的抽象模型；

发现规则，所述发现规则描述了如何现实化所声明的模型并创建具有各个实体的具体模型；

监视策略，所述监视策略提供描述从模型声明中创建的具体模型的各个组成实体的状态以及各状态之间的转换的状态机；

因果关系模型，所述因果关系模型以不要求具体知道管理包构成其一部分的系统的实例的方式来表达管理包的特定系统中的因果关系；以及使根本原因分析引擎访问并利用由所述因果关系模型生成的数据来确定可观察的故障的根本原因；

由所述操作管理器采用基于模型的管理系统来管理并监督一托管环境，所述托管环境包括一个或多个计算设备能驻留于其中的任何合适类型的环境。

11.如权利要求10所述的方法，其特征在于，单个管理包提供应用于其声明的类的各个实例的监视策略。

12.如权利要求10所述的方法，其特征在于，监视器是监视作为构成所述管理包的一部分的类的实例的实体的特定状态的状态机。

13.如权利要求10所述的方法，其特征在于，因果关系使用XML表达式来表达。

14.如权利要求13所述的方法，其特征在于，因果关系按照多个不同的原因来表达。

15.如权利要求14所述的方法，其特征在于，至少某些原因能与对其表达所述因果关系的实体相关联。

16.如权利要求14所述的方法，其特征在于，至少某些原因能与按照所建模的关系能够相距多于一跳的实体相关联。

17.如权利要求14所述的方法，其特征在于，至少某些原因能与来自与对其表达所述因果关系的实体相同的类的不同的实体相关联。

18.如权利要求14所述的方法，其特征在于，至少某些原因能与来自不同于与对其表达因果关系的实体相关联的管理包的管理包的不同的实体相关联。

说明书全文

用于因果关系模型的声明和消费的系统和方法

技术领域

[0001] 本发明涉及计算机系统，尤其涉及基于模型的管理系统。

背景技术

[0002] 当今网络化世界中的系统是高度分布式的且是相互依赖的。这意味着单个根故障(诸如计算设备上的特定组件)可导致跨网络的许多真实的且察觉到的故障。甚至更复杂的是，在任何给定时间，可能存在在系统中活动的许多真实问题，以及起源于可见性问题的许多未知组件状态。

发明内容

[0003] 在基于模型的管理系统的上下文中采用各实施例。在至少某些实施例中，使用一种因果关系模型来表达各系统实体的因果关系而不一定要求知道这些系统实体构成其一部分的特定系统的总体组成。该因果关系模型能够允许按照特定系统实体所具有的与其他系统实体的关系来表达因果关系。这些其他系统实体可以是与对其表达该因果关系的实体共享一直接关系，或更一般地，共享一间接关系的实体。

[0004] 此外，在至少某些实施例中，因果关系表达在某种意义上是与可用于分析因果关系数据的根本原因分析算法分离的。由此，知道并为特定系统构建这些因果关系表达式的那些人不必知道将用于进行因果关系分析的分析算法。于是在逻辑上，这可允许各种不同类型的根本原因分析算法消费由因果关系模型开发的数据。

附图说明

[0005] 图1示出了根据一个实施例的其中可使用本发明的各实施例的示例性系统。

[0006] 图2示出了根据一个实施例的包括操作管理器的特定实例的系统。

[0007] 图3示出了根据一个实施例的示例性系统。

[0008] 图4示出了根据一个实施例的示例性系统。

具体实施方式

[0009] 概览

[0010] 在基于模型的管理系统的上下文中采用各实施例。在至少某些实施例中，使用一种因果关系模型来表达各系统实体的因果关系而不一定要求知道这些系统实体构成其一部分的特定系统的总体组成。该因果关系模型能够允许按照特定系统实体所具有的与其他系统实体的关系来表达因果关系。这些其他系统实体可以是与对其表达该因果关系的实体共享一直接关系，或更一般地，共享一间接关系的实体。

[0011] 此外，在至少某些实施例中，因果关系表达在某种意义上是与可用于分析因果关系数据的根本原因分析算法分离的。由此，知晓并为特定系统构建这些因果关系表达式的那些人不必知道将用于进行因果关系分析的分析算法。于是在逻辑上，这可允许各种不同类型的根本原因分析算法消费由因果关系模型开发的数据。

[0012] 在以下讨论中，提供了题为“基于模型的管理”的小节，其描述了可对其使用本发明的各实施例的一种类型的基于模型的管理的各方面。随后，提供了题为“因果关系模型-实现示例”的小节，其根据一个实施例描述了因果关系模型的各方面。

[0013] 基于模型的管理

[0014] 图1概括地在100处示出了其中可使用本发明的各实施例的示例性系统。在该示例中，系统100包括操作管理器102和托管环境104。通常，操作管理器102可以是作为软件来体现并被配置成监督并管理组成环境104的多个不同的机器或计算设备的组件。

[0015] 环境104可包括一个或多个计算设备驻留在其中的任何合适类型的环境。例如，这样的环境可包括诸如内联网等可以是高度分布式的且相互依赖的网络化环境。

[0016] 在所示出及所描述的各实施例中，操作管理器102使用基于模型的管理系统来管理并监督环境104。可以使用任何合适类型的基于模型的管理系统，且以下给出了一个具体的、非限制性的示例。如将在以下变得显而易见的，本发明的基于模型的管理系统利用被设计成使得能够表达托管环境中的因果关系的因果关系模型。用于因果关系表达的方法是稳健的且灵活的，并且可使得博学的技术人员能够表达系统中的因果关系而不一定要求他们知道该系统的具体实例化。

[0017] 图2概括地在200处示出了包括操作管理器102的特定实例的系统。在此，该操作管理器被示为包括或以其他方式利用计算设备102a和存储102b。在该特定示例中，操作管理器102可接收或导入各自包括用于其基于模型的管理活动的组件的一个或多个管理包202。在该特定示例中，各个管理包可以是针对任何类型的系统设计的，诸如，作为示例而非限制，数据库、服务器、客户机和/或这些系统的子组件、分布式目录配置、分布式文件复制服务、备份服务、以及诸如网络访问保护服务等各种更高级的服务等等。不必说，可针对其设计管理包的系统的数量和类型简直太多以至于无法列出，如技术人员可以理解的。在实践中，管理包可由可能不一定知道由另一第三方设计的管理包的具体实例化的不同的第三方来设计。

[0018] 在所示示例中，示出单个管理包204，并且其包括模型声明模块206、发现规则模块208、监视策略模块210和因果关系模型模块212，每一个模块都将在以下描述。

[0019] 模型声明模块206表示描述管理包的组件及其特性以及它们是如何相关的抽象或抽象模型。在以下讨论中，由模型声明描述的管理包的各个组件可被认为是“对象”并且这些对象的各个实例被称为“实体”。例如，管理包可描述前端“F”对象、一个或多个业务逻辑层“B”对象和存储对象。

[0020] 发现规则模块208包括关于如何“现实化”所声明的模型并创建具有各个实体的具体模型的指令。具体而言，发现规则模块描述如何找到特定物理环境中的实体以及这些实体所具有的与其他实体的关系。在该具体示例中，来自抽象模型的前端“F”可由特定的所描述的机器上的与第一业务逻辑层B1进行通信的网站“WS”组成。另一个业务逻辑层B2可与第一业务逻辑层进行通信，并且每一个业务逻辑层都可与所示的两个不同存储中的每一个进行通信。

[0021] 监视策略模块210提供被称为“健康模型”的东西以及本质上提供描述从模型声明中创建的具体模型的各个组成实体的状态以及各状态之间的转换的状态机的知识规则。在该示例中注意，网站和业务逻辑实体各自包括表示每个实体都可采取的各种状态以及导致在各种状态之间的转换的事件的状态机，如技术人员可以理解的。通过使用该监视策略模块，可以在任何时间计算相关联的健康模型及其知识规则、具体模型的组成实体的状态，并且可以在例如实体进入了不合需要或故障状态的情况下生成适当的通知。

[0022] 因果关系模型模块212或简单地“因果关系模型”利用该监视策略和发现规则(及其对实体之间的关系的表达)来表达该管理包的特定系统中的因果关系。对因果关系的表达可不仅包括作为该即时管理包的一部分的实体，而且还包括作为不同的管理包的一部分的实体。通过由此方式表达因果关系，根本原因分析引擎或相关引擎可被设计成访问并利用由该因果关系模型生成的数据来帮助发现特定故障的根本原因-即使当待解决的故障是由不同管理包中的实体引起的时候。

[0023] 在图2示例中，如果业务逻辑层B1具有可由存储中之一的准备(grooming)状态引起的临界状态，则规则或因果关系表达式可被设计成表达如下概念：如果业务逻辑层B1进入该状态，则一个原因可能是该特定存储的准备状态。因此，知道其特定管理包及其对象的那些人可制定不仅描述源自其管理包的潜在原因，而且还描述源自其他管理包的潜在原因的因果关系模型。

[0024] 在以下讨论中，描述了因果关系模型的一个具体示例。应该明白和理解的是，以下的描述并不旨在将所要求保护的主题的应用只限于所描述的具体方法。相反，可以使用其它方法而不背离所要求保护的主题的精神和范围。

[0025] 因果关系模型-实现示例

[0026] 在描述一具体的因果关系模型之前，考虑以下当设计因果关系模型时所面对的挑战。

[0027] 首先，特定原因可能与所观察到的征兆有很大的差距。例如，技术人员一般都知道，特定问题的根本原因可能在另一个系统上或甚至在另一个问题域中，例如，网络或存储域。然而，在良好建模的系统中，原因和结果所处的托管实体以某种方式相关。因此，如将在以下变得显而易见的，本发明的因果关系模型利用这些关系来表达因果关系。

[0028] 第二，因果关系知识往往在缺少具体模型的某些系统中定义。即，在许多系统中，原因和结果被有效地硬编码到系统中。这导致不合需要的某种程度的不灵活性。本发明的方法通过按照类模型来表达因果关系，并通过对所发现的具体模型进行推断来计算因果关系来绕开该问题，如将在以下变得显而易见的。

[0029] 此外，通常可能存在对于可观察故障的多个同时发生的原因。即，多于一个条件正同时导致一特定问题是可能的。本发明的方法通过确保因果关系分析可返回基于一个或多个可能原因的一个或多个结果来解决该情况。

[0030] 此外，原因可隶属于一动态组的一个或多个成员。作为示例，考虑以下情况。在其中采用负载平衡、故障转移、冗余和合成的许多情况下，因果关系逻辑通常将必须处理可动态改变的组的一个或多个成员。本发明的方法通过使该组被建模并且使实体中的每一个的贡献由允许例如“任何”、“所有”、“至少”等聚集逻辑的上卷(rollup)算法来表示，来解决这一情况。所以，例如，单个路由上的从点A到点B的一组网络IP跳点将被建模为被称为“路由”的组的成员。并且从点A到点B的所有“路由”将都被建模为“网络访问”组的成员。

[0031] 因为本质上具有N平方问题，所以可利用“提供者”机制来动态地使该分组的所需实例从所发现的模型中出现。例如，在以上示例中，在具有100个节点的网络中，存在10,000个可能的网络访问组，每个组都由三个或四个替换路由组成，每个替换路由都各自由四到五个跳点组成。在本发明的方法中，不必预计算所有这些并将其表示为存储的实例。

[0032] 此外，另一挑战可由未知状态造成。具体而言，可期望在任何给定时间将不可访问某些实体的当前健康状况，例如，一代理的心跳停止，或合成事务超时。尽管只有部分数据，但因果关系的表达式也应当能够提供合理的结果。

[0033] 给定上述挑战，利用以下概念来帮助构建用于定义因果关系知识的结构。

[0034] 托管实体是在管理包中的模型中描述的并且可作为软件、硬件或固件组件驻留的实体。

[0035] 受影响的托管实体(IME)是正在研究的非健康状态中的托管实体，例如，网站或数据库。

[0036] 受影响状态是对其表达因果关系逻辑的IME的健康模型中的特定状态定义，例如，“首字节响应慢”。

[0037] 原因涉及受影响状态的起因。具有导致受影响状态的一种或多种类型的原因是可能的并且每个原因都可被独立表达。

[0038] 原语断言是以下类型：ME.状态＝常量。结果是真/假或未知。例如，原语断言可以是：

[0039] PrinterX.OnlineState＝Offline(打印机X.在线状态＝离线)

[0040] 或者

[0041] ClusterY.RollupHealthState＝Red(集群Y.上卷健康状态＝红色)

[0042] 抽象原语断言(APA)：抽象原语断言按照类模型而不是具体实例来表达，它始终使用IME作为参数来表达。它是以下类型：

[0043] XPath表达式(IME).状态＝常量

[0044] 一个示例如下：IME：Websiteclass.Computer.CPU.Load＝busy(IME：网站类.计算机.CPU.负载＝忙碌)

[0045] 对于IME的给定状态的原因集是一组命名的APA。作为示例，考虑以下情况：

[0046]

[0047]

[0048] 任何原因的任何实例都可以是将要变为它现在的样子的IME的状态的起因。

[0049] 因果关系结果集：在正在运行的系统中，当IME处于一特定状态时，基于因果关系的分析将返回以下类型的结果集：

[0050] 原因＝原因类型；RCA ME＝ME实例；状态＝状态值；确认的/猜测的；上卷/叶[0051] 该结果集可具有可递归地包含基于从上卷状态下钻的相同类型的行。成员可基于由XQuery返回的可疑元素。

[0052] 在RCA ME状态本身可由另一个下游ME处于特定状态的事实引起的情况下也使用相同的格式。

[0053] 实现示例

[0054] 在以下示例中，利用具有实体的系统，这些实体包括数据库、数据库文件组、数据库文件、和用于覆盖两个单独盘上的两个数据文件的数据库的逻辑盘。首先，描述系统，之后是对该系统的类、关系和监视器的表达式的描述。之后，提供数据库上的特定的所监视的状态的因果关系如何在管理包中表达的示例。

[0055] 图3示出了由以下实体组成的示例性系统300：数据库302、数据库文件组(DB文件组，DBFileGroup)304、两个数据库文件(DB文件，DBFile)306和两个逻辑盘308。在该示例中，假设数据库302是SQL Server数据库并且该数据库302、DB文件组304和DB文件306是SQL Server管理包中的类的实例，并且根据该管理包中的规则来发现并监视，并且该逻辑盘308是不同的管理包-Windows Server管理包中的类的实例，并且根据该管理包中的规则来发现并监视。

[0056] 在所示出及所描述的实施例中，管理包是强类型化的，并包括唯一的类ID和关系ID。所表达的关系也是强类型化的。

[0057] 在上述示例中，SQL Server管理包和Windows Server管理包声明其各自的类、关系和监视器。SQL Server管理包负责监视其声明的类的健康状况，并且该Windows Server管理包负责监视其声明的类的健康状况。然而，特定类的健康状况可取决于来自另一个管理包的实体的健康状况，如将在以下变得显而易见的。上述示例中的对于管理包(MP)的声明如下：

[0058] 类：

[0059] 在Microsoft.SQLServer.2005.MP中定义：

[0060] Microsoft.SQLServer.2005.Database

[0061] Microsoft.SQLServer.2005.DBFileGroup

[0062] Microsoft.SQLServer.2005.DBFile

[0063] 在Microsoft.Windows.Server.MP中定义

[0064] Windows.Server.LogicalDisk

[0065] 关系：

[0066] 在Microsoft.SQLServer.2005.MP中定义：

[0067] Microsoft.SQLServer.2005.DatabaseHostsDBFileGroup

[0068] Microsoft.SQLServer.2005.DBFileGroupHostsDBFile

[0069] Microsoft.SQLServer.2005.DBFileLivesOnLogicalDisk

[0070] 监视器：

[0071] 在Microsoft.SQLServer.2005.MP中定义：

[0072] 数据库类上的Microsoft.SQLServer.2005.Database.Database.DBResponse[0073] 数据库类上的Microsoft.SQLServer.2005.Database.BackupState

[0074] 数据库类上的Microsoft.SQLServer.2005.Database.DBPercentFreeSpace[0075] 文件组类上的Microsoft.SQLServer.2005.DBFileGroup.WriteHealth[0076] 在Microsoft.Windows.Server.MP中定义：

[0077] 逻辑盘类上的Microsoft.Windows.Server.LogicalDisk.DiskQueueLength[0078] 在此，在类声明下，存在四个类声明。前三个类声明涉及SQL Server管理包内的类-即，Database(数据库)、DBFileGroup和DBFile。最后一个类声明涉及来自另一个管理包的实体-Windwos Server管理包及其LogicalDisk(逻辑盘)类。

[0079] 关系声明描述实体如何彼此相关。例如，数据库具有与DB文件组的主存关系(即，“DatabaseHostsDBFileGroup”)。同样，DB文件组具有与DB文件的主存关系(即，“DBFileGroupHostsDBFile”)。类似地，DB文件具有与逻辑盘的“住在”关系(即，“DBFileLivesOnLogicalDisk”)。

[0080] 所声明的监视器是监视其相关联的实体的特定状态的状态机。在该示例中，存在五个监视器，其中四个在SQL Server管理包中声明，而其中一个在Windows Server管理包中声明。

[0081] 对于SQL Server监视器，三个监视器是为数据库类而声明的，例如，数据库响应(DBResponse)、备份状态(BackUpState)和空闲空间百分比(DBPercentFreeSpace)。一个监视器是为文件组类(DBFileGroupClass)而声明的-例如，写健康(WriteHealth)。

[0082] 对于Windwos Server监视器，一个监视器是为逻辑盘类(LogicalDisk)而声明的-例如，盘队列长度(DiskQueueLength)。

[0083] 每个监视器彼此独立地监视影响其特定类的各方面。维护所监视的状态并且操作管理器(图1)可通过该因果关系模型来查明可能存在特定问题的原因。

[0084] 现在考虑监视器Microsoft.SQLServer.2005.Database.Database.DBResponse具有与该数据库的一部分上的慢响应相关联的被称为“DBResponseSlow”(DB响应慢)的操作状态。该状态的根本原因可以是该系统中的多个其他监视器。例如，该操作状态的原因可以是以下的一个或多个：

[0085] ·Microsoft.SQLServer.2005.Database.BackupState 监视器处于BackupInProgress(正在备份)状态；

[0086] ·Microsoft.SQLServer.2005.Database.DBPercentFreeSpace 监视器处于CriticalSpace(临界空间)或WarningSpace(警告空间)状态；

[0087] ·Microsoft.SQLServer.2005.DBFileGroup.WriteHealth 监视器处于DiskWriteDegraded(盘写入降级)状态；和/或

[0088] ·Microsoft.Windows.Server.LogicalDisk.DiskQueueLength 监视器处于DiskWriteDelayed(盘写入延迟)状态。

[0089] 这四个因果关系可在一模式中表达，其一个示例就在以下示出。

[0090]

[0091]

[0092]

[0093] 在该示例中，因果关系表达式对应于所监视的操作状态DBResponseSlow，并为该操作状态定义了四个不同的原因(由标签断开)。

[0094] 起因或原因可以是“BackupRunning(正在运行备份)”、“DBLowOnSpace(DB空间少)”、“DiskWritePerformance(盘写性能)”或“DiskQueueHigh(盘队列长)”。表达式中的前两个原因与在该实体本身(即，数据库类)上发生的事情相关联。下一个原因指的是其所依赖的DBFileGroup-由此，XML跨越关系类型指向DBFileGroup类。在此，在该类上的监视器可能导致该问题。最后一个原因与LogicalDisk相关联。在此，XML定义多个跨关系“跳跃”以到达可能的原因。

[0095] 稍微更详细地探查XML因果关系表达式，考虑以下情况。回想管理包中的实体利用唯一的ID。这在某种程度上类似命名空间。在上述XML表达式中，标签标识强类型化的类-Database，以及监视器-DBResponse。此外，XML标识为其定义因果关系表达式的状态-此处为Database类上的操作状态DBResponseSlow。

[0096] 由此，标签本质上指向在该XML表达式的更下方的为其表达因果关系的类和监视器。

[0097] 现在，如可从以上描述中理解的，对于特定故障或有问题的状态可能存在许多不同的原因。在所示出及所描述的实施例中，给予每个原因(在其相应的标签中)一个ID和与该原因相关联的目标类。该目标类涉及该原因所源于或源自的实体。此外，每个原因还涉及可以是问题的可能原因的与该类相关联的监视器，以及该监视器为了成为作为因果关系表达式的主体的问题或故障的可能原因而必须进入的状态。

[0098] 拿第一个列出的原因作为示例。在此，对于DBResponse状态DBResponseSlow的一个可能的原因可以是存在正在运行的备份。该正在运行的备份条件源自Database类并且由BackUpState监视器监视。如果BackUpState监视器具有被标记为“True(真)”的操作状态BackUpInProgress，则该原因可被标记为DBResponse状态DBResponseSlow的可能原因。如果BackUpInProgress被标记为“False(假)”，则该可能的起因或原因可被排除。

[0099] 继续，第二个列出的原因(DBLowOnSpace)指向相同的Database类上的另一个监视器，并且定义其中任一个都可以是慢数据库响应的可能原因的状态。具体而言，如果DBPercentFreeSpace监视器使其CriticalSpace或WarningSpace中的任一个被标记为“True”，则分别标记的状态可以是DBResponse状态DBResponseSlow的可能原因。

[0100] 第三个列出的原因(DiskWritePerformance)指向不同的类(即，DBFileGroup类)以及与该类相关联的监视器-WriteHealth。在此，如果WriteHealth监视器使其操作状态DiskWriteDegraded被标记为“True”，则这就可被列为DBResponse状态DBResponseSlow的可能原因。此外，因为该原因指向不同的类，所以它还使用标签来指定到该类的路径。该标签在该路径的末端处定义了关系类型和类。该声明有效地定义了跨越该关系类型的“跳跃”并且指定应当找到DBFileGroup的任何实例并且应当检查其监视器的指定状态。

[0101] 对应于第四个列出的原因(DiskQueueHigh)的表达式类似于第三个列出的原因，不同之处在于存在多个定义的“跳跃”。然而，在该原因中，涉及不同的管理包。具体而言，在目标字段中，使用例如“Windows！”的指定来表示该声明涉及在该串上进一步指定的不同的管理包(即，Windows Server)。此外，如在上述示例中连同操作状态或可影响待解决的状态的状态一起指定监视器。在该示例中，指定该逻辑盘的盘队列长度，并且如果其操作状态“DiskWriteDelayed”被标记为“True”，则该原因可被列为DBResponse状态DBResponseSlow的可能的原因。

[0102] 此外，因为该原因涉及不同的管理包，所以该声明与上述声明略有不同。具体而言，在此存在嵌套路径关系，其有效地定义跨越指定类型(DatabaseHostsDBFileGroup)的所有关系类型的跳跃并找到所有指定的类实例(DBFileGroup)，并且然后定义跨越下一个关系类型(DBFileGroupHostsDBFile)的跳跃并找到所有类实例(DBFile)，并且然后定义跨越下一个关系类型(DBFileLivesOnLogicalDisk)的跳跃并找到指定类的所有实例(LogicalDisk)。

[0103] 通过使用上述灵活的因果关系表达式，实现以下事情是非常容易的。首先，可具有按照应用程序类型模型来声明地描述因果关系的能力，并且因果关系模型可实现以下事情。该因果关系模型可以将相同实体上的两个问题链接为原因-结果。这样的示例发生在上述前两个列出的原因中。该因果关系模型可以将直接相关的实体上的两个问题链接为原因-结果。这样的示例是第三个列出的原因。该因果关系模型可以将间接相关的实体上的两个问题链接为原因-结果。这样的示例是上述第四个列出的原因。

[0104] 此外，该因果关系模型即使在关系不是“包含”的情况下也可链接问题。即，关系可以是“主存”、“客户机-服务器”、“的副本”或任何其他可以想到的关系。此外，该因果关系模型可以将许多原因链接到相同的结果。这在其中四个不同的原因可以是在因果关系表达式中定义的特定故障的起因的上述示例中完成。此外，该因果关系模型可基于关系的特定类型来链接问题。

[0105] 此外，该因果关系模型可利用模型的可组成性来组成因果关系模型。具体而言，在上述示例中，每个单独的管理包都具有涉及其自己的实体的其自己的特定因果关系表达式。如上所见，这些因果关系表达式可伸展跨越并由此利用不同的管理包以及由这些包定义的因果关系模型。

[0106] 此外，该因果关系模型可与所利用的根本原因分析算法/引擎分开。这可允许不同的根本原因分析算法或引擎利用由该因果关系模型开发的因果关系信息。根本原因分析算法的一个这样的示例就在下文提供。

[0107] 在操作中，任何合适类型的系统可被设计成利用因果关系模型来使用任何合适类型的根本原因分析执行根本原因分析。作为这一系统的仅仅一个示例，考虑概括地在400处示出示例性系统的图4。

[0108] 在此，系统400包括如上所述管理环境104的操作管理器102。操作管理器可接收并处理多个不同的管理包202，每个管理包都可包括如上所述的各组成部分-具体而言，描述相关联的实体及其彼此之间的关系的某种类型的模型，以及诸如上述的因果关系模型等因果关系模型。此外，提供相关引擎402并且其操作上与操作管理器102耦合。在该示例中，操作管理器102展示可由相关引擎402调用以访问已使用因果关系模型来开发的数据的应用程序接口(API)。在实践中，相关引擎读取具体模型和状态，计算根本原因并将根本原因写回到操作管理器。操作管理器然后可使用控制台404来在拓扑状态图的上下文中显示根本原因。通过使用控制台，诸如系统管理员等用户可快速标识他或她的系统正在经历的特定故障的根本原因或原因。

[0109] 对于相关引擎，可以使用任何合适的算法来分析由该因果关系模型开发的数据。这些算法的某些特性可包括，作为示例而非限制，对模型和检测到的状态进行推断，并且使用一组托管实体类型的原因表达式来产生因果关系结果集的能力。

[0110] 作为根本原因分析算法如何处理由因果关系模型产生的数据的简单的示例，考虑以下计算。在以下描述中，已忽略了诸如可见性和可组成性等问题。

[0111] 对于每一个托管实体的每个状态，检查以查明该状态当前是否为“真”。如果该当前状态不为“真”，则该算法可退出或处理下一个状态。如果该当前状态为“真”，则接下来检查以查明该状态是否为“良好”。如果是，则该算法可退出或处理下一个状态。

[0112] 接下来，对于不是“良好”的状态，检查以查明是否存在分配给该状态的任何原因。如果不存在分配的原因，则将该状态标记为根本原因。

[0113] 如果存在分配的原因，则跟随该原因并且检查以查明对于至少一个原因该原因中的断言是否为“真”。如果原因中的任一个为“真”，则可得出正在研究的状态只是别处的原因的结果的结论。在这一情况下，可相应地标记因果关系(如用箭头)。

[0114] 然而，如果原因中没有一个为“真”，则可将该托管实体的该方面标记为根本原因。

[0115] 当对于所有托管实体完成该操作时，可显示整个拓扑结构，且根本原因用黑圈来标记并且用箭头串来从各坏状态引导至根本原因。

[0116] 现在考虑更高一级的复杂度。假设某些实体是合成实体(诸如集群等)。在这一情况下，在执行就在以上描述的算法之前，计算上卷状态。

[0117] 现在，假设某些托管实体变“盲”，即，它们的状态是未知的。在该情况下，可首先反跟踪因果关系。具体而言，该算法可找到已知的所有“结果”状态。对于该托管实体的该方面，该算法可找到应该为“真”，但是未知的所有“原因”以便引起非真状态中的任一个。所有这些未知状态都为假。即，如果它们为真，则可观察状态将会不同。以此方式，可在开始上述算法之前消除最多的未知状态。

[0118] 然而，用于计算“过失”的算法现在转换为统计方法。即，可由未知状态解释为将要进入特定状态的已知状态越多，则这为真的的可能性也越高。

[0119] 注意，在上述算法中，所有推断(确定未知状态、确定“过失”或确定“过失”的概率)并不取决于任何东西的过失值。它纯粹是基于当前状态值的。结果，当托管实体的状态改变时，可基于因果关系向外脉动传送(ripple through)该扰动(perturbation)。换言之，本地计算已足够，并且不必从头到尾计算所有关系的结构。

[0120] 结论

[0121] 上述各实施例可提供一种用于表达各系统实体的因果关系而不一定要求知道这些系统实体构成其一部分的特定系统的总体组成的因果关系模型。结合基于模型的管理技术使用的该因果关系模型能够允许按照特定系统实体所具有的与其他系统实体的关系来表达因果关系。这些其他系统实体可以是与对其表达该因果关系的实体共享一直接关系，或更一般地，共享一间接关系的实体。至少某些实施例将因果关系表达式与可用于分析因果关系数据的各种根本原因分析算法分开。由此，知晓并为特定系统构建这些因果关系表达式的那些人不必知道将用于进行因果关系分析的分析算法。于是在逻辑上，这可允许各种不同类型的根本原因分析算法消费由因果关系模型开发的数据。

[0122] 虽然已经用对结构特征和/或方法步骤专用的语言描述了本发明，但是应当理解，所附权利要求书中定义的本发明不必限于所描述的具体特征或步骤。相反，各具体特征和步骤是作为实现所要求保护的本发明的较佳形式来公开的。

标题	发布/更新时间	阅读量
翻译声明性模型-专利编号CN101836201A	2020-05-11	880
声明性工作流设计器-专利编号CN101689178A	2020-05-12	487
信任关系的声明变换-专利编号CN101438274B	2020-05-12	706
声明性视图对象-专利编号CN103186661A	2020-05-12	28
声明性管理框架-专利编号CN101467144A	2020-05-11	279
声明性管理框架-专利编号CN101467144B	2020-05-11	129
声明性配置元素-专利编号CN105493033A	2020-05-11	75
绑定单元声明文件-专利编号CN103761259B	2020-05-13	164
绑定单元声明文件-专利编号CN102067081A	2020-05-13	729
绑定单元声明文件-专利编号CN103761259A	2020-05-13	348

用于因果关系模型的声明和消费的系统和方法

用于因果关系模型的声明和消费的系统和方法

技术领域

背景技术

发明内容

附图说明

具体实施方式

IPRDB

热门服务

关于我们

友情链接

联系方式