事件标记关联优化模型实现

帕特里夏•马库

慕尼黑网络管理小组莱布尼兹超级计算机中心

玻尔兹曼一号街，85748，加尔兴，德国

marcu@mnm-team.org

 

吉拉迪•格拉，贝尼克劳拉•栾

丹妮拉•罗苏，拉里莎•施瓦提兹，克里斯•华特

IBM T. J. Watson 研究中心

天际19号大道，10532霍索恩，纽约

genady, luan, drosu, lshwart, cw1@us.ibm.com

 

 

摘要:在最近的几年里，IT服务管理（ITSM）已经成为IT领域的研究热点之一。事件和问题管理是IT基础设施标准库（ITIL）中的两个服务操作流程。这两个流程的目标是发现、记录、隔离和纠正出现在现实环境中,影响到了服务提供的错误。事件管理和问题管理构成了事件跟踪系统（ITS）中相关工具的基础。

       在ITS系统中，虽然最终用户和监控系统创建的看起来不相关的标记却常常并存且有着相同的根源属性。通常采用人工干预手动建立这些资源和服务故障之间的联系，而不是自动发现。需要人为的干预来完成明显降低了生产效率。自动化的引入可以提高效率，从而降低处理事件的开销。

       本文基于三个准则提出了一个事件标记关联的模型。首先，我们在使用相似性规则进行服务标识与关联资源标识匹配的基础上，建立一个基于类别的关联；其次，我们将对故障服务的关键配置项与最初发现的资源标记进行关联，以便优化拓扑对比；最后，我们通过增加具有约束自适应探测性的周期性资源数据采集来减少临时关联标记的时间间隔。我们最终提供了相关的实验数据论证了这个关联模型。

 

关键词:事件标记，事件管理

 

引言

       由于IT服务提供商专注于提供高质量、效率服务的方法学及相关工具的开发，IT服务管理（ITSM）近年来已经成为了IT中一个重要的研究领域。作为ITSM的重要组成部分，事件管理和问题管理提供了一种机制，用于发现、隔离、纠正和记录系统中出现的影响到服务提供的问题和事件。

       IT基础设施标准库（ITIL）是信息技术（IT）基础设施管理、开发和运营描述，IT事件管理及其他IT服务运营相关流程中的最佳规范。事件管理是与事件相关的流程，ITIL规范中事件定义为：“一个IT服务的计划外的中断或者IT服务质量的下降。一个尚未影响到服务的配置项的故障也是一个事件”^[2]。

       事件管理流程需要包括事件跟踪系统（ITS）在内的多种工具支持。这些软件系统用在负责记录服务故障、失效信息以及技术支持人员，代表报告事件的最终用户的第三方干预信息的部门中。这类记录被称做标记。标记由监控系统提出，反映了被监控IT系统的重要指标的下降。监控系统部署在主动管理系统运行状况和服务质量的计算设施中。通过检测预定义条件，监控系统会触发事件来自动创建标记。

       监控系统在ITSM中虽然很有用，但若期望IT基础设施中的所有元素都被持续监控显然不现实的。在一个大数据中心，通常对关键资源的监控是周期进行的。监控周期的变化取决于资源的重要性和稳定性。对一些资源来说，监控被设置为手动触发，避免增加网络的负载。

       由监控系统创建的一个标记通常从服务基于的底层资源的视角提供信息，比如服务故障和负载、网络路由失败的报告。因此，在一个问题跟踪系统中同时存在着两种相关的标记，即来自最终用户的标记以及来自监控系统的标记，但是它们之间的关系不是立即确定的。标记间的关系通常由人来判断，这个过程在人力和生产力方面的投入却是昂贵的。然而我们经过研究发现，识别冗余的或者可能同源的标记对高效事件管理来说是至关重要的。

       为了隔离最终用户报告的标记的错误原因，同时支持问题决策和根根源分析，标记的关联必须发生在标记创建时。标记关联的准确会给用户和服务提供商带来好处。它能更快地提供标记的解决方案，服务提供商可以享受到问题根源分析的更高效率，同时，将成本和资源利用控制在一个较低的限度。

       本文提出了一个关于最终用户生成的标记与监控系统生成的标记的有关资源问题关联的新方法。在第二部分中，我们将该领域中已取得的一些进展情况。我们的多阶段关联流程较相关成果有许多优势。首先，基于类的过滤和对失败服务的关键资源的初始关注，达到了通过限制昂贵的CMDB搜索的可能性来加速处理的目的。其次，通过限制接受监控标记的时间滞后影响，自适应资源轮询增加了结果的质量。第三部分提供了一个相关的例子。第四部分描述了标记关联的模型和方法。第五部分通过形式和实验结果验证了设想的关联模型。第六部分进行了总结并指出下一步工作方向。

 

相关工作

       本节大致回顾了事件、问题管理和故障诊断问题标记、症状、事件关联的相关研究进展。

       在与集中网络和系统管理^[3]中的故障诊断有关的重要文献中，Dreo提出了为标记发现使用问题标记关联和访问的问题解决专家库。他认为一个服务的良好功能和拓扑模型（即资源映射）是高质量关联的关键要素。本文中我们为关联的拓扑和时间等方面使用新的模型，即拓扑部分由CMDB关系来建模，暂态部分采用基于有约束的自适应资源轮询来灵活处理。另外，我们使用了一个基于类别的关联。

       [4]提出了关于事件关联的一个算法，[5]基于和[3]相同的服务模型进行了扩展。事件根据使用基于规则的推理（RBR）和主动探索的根源分析来建立关联。现在我们采用相似的方法，使用RBR规则的一个子集和自适应探索（主动探索的一个拓展概念）来触发相关资源标记的创建。

       [6]对自增进帮助台服务提出了一个使用基于案例的推理（CBR）的系统。这个技术通过对标记的描述来强调搜索的重要性。[7]描述了一个使用RBR技术发现故障标记数据的历史值和预期值的相似方法。这两种方法都使用关键词搜索。由于高度相关的关键词通常很难确定，所以得到不正确的关联结果的可能性相对较高。

       Gupta et al。 [8]基于CMDB关键词搜索提出了一个关联输入事件和CMDB配置项的自动化算法。这个算法可以用在我们的工作中，来降低CMDB搜索的负载。

       自适应探索技术[9]，[10]使用一种测量技术，允许通过主动从大部分相关信息调查中选择少量来在线快速推断当前系统状态。我们使用这种技术来触发关联资源标记的创建。我们认为，这个技术在探索执行的整体时间和同时运行的探索的数量上还有待改进。

       [11]提出了利用CMDB中定义的被管对象间的关系来关联事件强流中出现的征兆事件，从而来确定问题发生的根本原因。在发掘相似对象关系时，我们的方法还使用了其他的服务描述细节来提高事件关联器的准确性和响应时间。

       [12]探索了从CMDB中取得关于服务、组件和用户关系来确定网络中断对服务和用户的影响。同时，被网络中断阻塞的数据包中的数据标识了直接影响的服务和用户，CMDB关系有助于确定进一步的影响。

 

研究目的

       a)从一家大公司的账户系统的角度：通过故障标记分析验证了我们的成果。账户系统由大量的计算机系统，包括个人电脑以及服务器集群和框架。这些基础设施支持了从个人计算到企业服务（比如：电子邮件）以及商务服务（比如：应用服务提供商）等大量的服务。

假设每2。5年产生约650万故障标记。我们发现多种监控工具被使用了。一些监控工具关注与关键系统应用。样例系统关键包括CPU和文件系统利用率、网络接口状态和文件大小。样例应用关键包括Web应用服务响应时间、JDBC调用响应时间和数据库表空间利用率。在这项工作中，由这些工具产生的标记被看做“资源标记”。

对于资源和用户标记的关联关系的细节，比如关系体积和到达形式，我们关注于企业账户系统中大组织之一，并选择资源标记较高的30天的一段时间。分析基础的16000个标记，其中900个是资源标记。在剩下的标记中，大约100个是服务标记，剩下的与工作站、个人账户管理有关。我们确定了几个与标记关联问题相关的挑战：

       处理由于监控工具的细节和配置导致的资源标记的延迟递交。这促使我们提出了在资源关联过程中加入额外的资源池的方法。

       处理大量冗余的标记。冗余主要针对资源标记，产生于可能的紧急的状况的通知采用基于门限的策略。一旦系统的指标达到门限值，标记被周期性地创建，直到状况清除。因此，冗余标记的人工分析花费的时间较长，带来了标记关联的自动化的需求。

       处理可变的时间间隔中与相关的资源标记重复的服务标记。即使根本原因已经被解决，服务标记可能在距相关资源标记有几分钟，也可能是几天后带来。

       b)例子：图1描述了一个多层次的J2EE企业应用部署，包括前端HTTP服务器，请求调度，Web Sphere应用服务器（WAS）和后台数据库服务器。多个实例的HTTP服务器和WAS服务器用于负载共享。备用服务器配置为请求调度和数据库服务器的故障转移保护。这些数据库驻留在存储系统，并通过SAN的连接到数据库服务器。

       电子商务应用程序被打包为企业存档文件shopping。ear，其中包括购物车和目录搜索服务。购物车服务中采用两个数据库，一个用于目录记录和购物的交易记录。出于安全性和性能方面的原因，每个数据库部署在不同的数据库服务器。目录搜索服务是一个搜索引擎，打包作为企业档案文件search。ear并部署在购物车服务中不同的服务器上。已部署的应用程序访问索引数据库，以便为来自shopping。ear的搜索请求服务。

 

图 1 购物车和分类搜索电子商务服务实现

 

       图2给出了一个在图1所示的系统配置的细节。这个视图来自配置配置管理系统提供的数据。它形象地描述了有关系统部件（图中的圈）及它们之间的关系（箭头和注解）。例如，图1中WAS服务器由三个配置项来表示：

·计算机系统（例如：计算机系统3a）；

·操作系统（例如：OSLN3a）它与计算机系统是“安装于”的关系；

·WAS服务器（例如：WAS服务器3a）它与操作系统是“运行于”的关系；

其他值得一提的关系如下：

  ·影响WAS服务器的数据库服务器，例如：数据库服务器5a与Web服务器——“WAS服务器3a”、“WAS服务器3b”、“WAS服务器3c”、“WAS服务器4a”有着“影响”的关系；

·数据库驻留在SAN上，因此它们与SAN上的存储子系统有“驻留”关系；

·存储子系统安装在数据库服务运行的操作系统上，因此它们与操作系统有“绑定”关系；

·应用程序使用数据库，例如：search。ear与indexdb有“使用”的关系。

图2中的信息在接下来的部分被用来说明提出的算法如何关联最终用户标记与系统生成的标记，来帮助确定根本原因。

 

图 2 服务系统映射

 

关联事件标记的模型与算法

A.    概念和定义

本节介绍我们提出的标记关联的新算法所使用的概念。即我们约定标记的概念、服务和配置项（相关的和关键CI），并介绍有约束的自适应探索。

这部分我们将介绍用于新型标记关联算法的设计思想。亦即我们将形式化标记,服务和配置项的概念(相关并且关键的CIs),同时还将介绍限制型自适应探索。

通用标记定义:标记是事件的一条记录,包括与事件相关的所有信息,例如事件上报者(个人或软构件),上报事件,事件具有的优先级,处理事件的人员,标记状态和其他细节。

标记分为以下几类:1)源标记,当他们被监控系统上报时;2)服务标记,当他们被终端用户打开,呈现出用户感觉到的体验。

 

图 3 标记类层级关系

 

在图3中给出了标记类层级情况。其中提到的两类ResourceTicket和ServiceTicket是之前提到的GenericTicket类的子类。

GenericTicket类有以下属性：

·标识符，通常是一个字符串，代表事件上报的唯一引用号；

·源，拥有资源或服务的可能取值，标示出作为基于资源监视和终端用户服务各自标记的起源。

属性status，priority，时间戳对于我们现在讨论的不相关。

除了上面所说的一些属性，ResourceTicket和ServiceTicket分别拥有它们各自独有的一些属性。ResourceTicket另外有两个属性：

·资源，它作为终端用户所困扰服务的唯一标识符；

·服务类别，它是服务类别的唯一标识符；

·客户ID，它标示了受服务困扰的用户。

表-1给出了一个资源标记的实例以及一个服务标记的实例，都呈现了所定义的属性。

 

资源标记

服务标记

 

属性	值	值
标识符 源 状态 优先级 时间戳 资源 资源类别 服务 服务类别 客户ID	320054D resource pending medium 081320081245 indexdb HW/Server/WAS/indexdb	453999 service new high 08132008928 shopCatalog   shoping cart SW/webAppl/searchCatalog a2816AB

表 1 资源即服务标记示例

 

服务定义：服务定义是由供应商在服务类别中予以规范。服务定义主要有两个部分：服务类别和匹配规则。通常类别是站在用户的角度来定义的。匹配规则将服务和基础设施（资源）的抽象表现形式联系起来。这些可能会作为服务产品的服务定义部分给出，并在服务服务设计过程中演进。匹配规则是该方法的一个创新点。正如它的名字所说的那样，他是一种规则，用以匹配用户在服务创建时选择的类别和监控系统在资源标记创建时选择的类别。它有 一个很简单的形式：if servCategory then resCategory。对于一个服务类别可能存在多个匹配规则。我们建议每个标记系统有自己的标记分类体系。

例子：一个用户创建了一个购物车标记，同时搜索类别-电子商务服务（参见图1）。在这种作为”服务路径”的服务分类情形中它可以是SW/webAppl/searchCatalog/cannotSaveSearch。这个分类路径最重要的部分是SW/webAppl/searchCatalog，它指对于文本、应用搜索类别有一个标记。在这个服务定义中可能的规则有：

if SW/webAppl/searchCatalog then HW/Server/WAS or

if SW/webAppl/searchCatalog HW/Server/WAS/indexdb or

if SW/webAppl/searchCatalog HW/Storage/Database/CatalogDB or

if SW/webAppl/searchCatalog HW/Storage/Database/TransactionDB

依赖树：依赖树是包含组件及组件间关系的网络的一种表现形式。这些组件是相互关联的CIs。

例子：第III部分图 2展现了一部分实现服务分类购物的依赖树。在这个例子中，httpServerla依赖于dispacher2a。dispacher2a依赖于WASServer3a，ComputerSystem3a和OSNLN3a。WASServer3a依赖于数据库服务器DBServer5a 和 DBServer5b。DBServer5a依赖于WASServer4a，而WASServer4a本身依赖于indexdb。其他被数据库DBServer5a控制的数据库：catdb1, catdb2是购物的从属单元包含在WASServer3a中。

业务服务CI：业务服务CI是服务定义的实例化。它在我们讨论的方法中特别重要，这个方法是业务服务CI 包含特定用户服务实例的关键支持信息。关键CIs同样包含在依赖树中，此时是作为关联CIs的一个子集。

例子：业务服务CI作为一个针对用户A2816AB购物类别服务的实例。对于这个实例的关键CIs是dispacher2a，WASServer3a，WASServer3a和DBServer5a。

限制性自适应探测（CAP）：是一种在依赖树中以约定时间长度而且不加重网络负载的找寻最优先探寻CIs的技术。

 

B 理想关联模型

在这部分，我们提出了一种较优的方法来关联资源和服务标记，这一切都建立在之前介绍的思路。我们的目标是减少计算负担，同时增强相关联服务和资源标记的判定精确度。亦即，给出一个服务标记以及一些资源标记，该方法基于以下三个部分：

·基于类别的关联，采用匹配规则过滤资源标记；

·机缘关键CI的关联，过滤资源标记，它们基于对失效服务至关重要的CIs的引用。仅仅通过查看关键CIs，我们目的是减少对依赖树搜索（即拓扑比较）的花费；

·暂态关联，在依赖树中使用CAP抱着采用最好的方法定位CIs，目的是触发监控系统进行资源标记创建。

图4的活动图描述了关联进程的相应步骤，以终端用户服务标记创建开始。

图左边栏展现了终端用户活动。而右边栏我们有提供者区域。提供者活动在途右边显示，分为四列：相关器识别相关活动。标记系统包括关联中使用开放标记。

 

图 4 问题标记关联工作流

 

CMDB包括之前定义的依赖树（含有相关配置项的拓扑结构）和商业服务配置项（含有关键的配置项）。还有很重要的一点是服务目录给客户提供了接口。我们可以在服务目录中找到服务的定义。

活动以终端用户对新的事件标记的开启和分类作为开始。例如，客户A2816AB的用户B利用SW/webAppl/searchCatalog/cannotSubmitRequest开启了关于目录购物服务的标记。从此刻开始活动被置于相关域。在真实的相关关系出现之前额外的数据需要从上述已命名的域检索。现存的开放资源标记（RT）从ITS中进行检索。我们可以通过服务标记中的服务分类（分类途径）把所有相关类似的规则从服务定义中提取出来。同时，服务类别和客户身份标识（来自服务标记）可以在商业服务CIs中进行检索。使用上述数据，1a和1b两个活动得以并行处理。

1a 按照时序在开放资源标记（属于标记系统）中寻找类似的标记。首先完成不同服务类别的对比。这有助于将搜索范围限定在相关服务上，以此减少搜索标记的数量。这些信息以标记的resCategory 和 servCategory属性值形式存储，并且它们可以与服务定义中类似的规则进行匹配。在本文的例子中分类深度为4，但是分类深度越深规则匹配的精度就越高。分类路径是相似规则的第一部分。第二部分与分类路径类似，但是是针对资源标记的，在大多数情况下它指向默认资源。

1b 找到在与服务分类结合的商业服务CIs上定义的重要的CIs。该信息是从服务定义的包含在服务标记和服务分类客户ID属性值中重新获取的。如果这些活动同时成功，则转入活动2，否则转入活动3。

2 我们按照相关RTs的时间顺序，使用在1b中得到重要CIs在1a中搜索类似的RT。如果找到了匹配的选项，则关联过程完成。这是提出搜索请求后最理想的用户使用场景。

3 如果没有找到重要CIs所需的RTs，需要从商务服务CIs独立树（拓扑）进行输入。如果该服务相关的CIs没有得到标识，则关联过程认为没有RTs可以进行关联。否则进行下一步。按照定义相关CIs（在独立树中）也包含着重要CIs，所以我们不能遗漏搜索中任何候选项（在1b中找不到的CIs在3中一定可以找到）。

4在我们提出的方法中由于监测架构的原因，我们预计在活动3完成后，某些场景最后一个时隙可能没有标记可用。这时可以利用独立树资源上的CAP。对有问题的资源的探针生成资源标记。CAP的作用在于找出最有效的探针独立树内给定CIs集合的方法。这样在给定时间和给定探针数目限制的前提下可以完成这个过程。该解决方案的可行性和具体算法在第V部分有详细的说明。

5 标记系统在RTs上搜索相关的CIs。关联在该步骤之后以相关RTs的列表或者是没有相关RTs的结果这两种形式之一结束。

图5以伪代码形式更为详细的描述了关联算法。

INCIDENTICKCORRELATION过程实现了图4中以初始化算法中涉及到所有列表为开始的活动图。

 

1: procedure INCIDENTTICKETCORRELATION 2:   initializeAllList  all lists needed are initialized 3:   newServiceT icket = getNewServiceT icket() 4:   listOfOpenRT = getListOfRT() 5:   listOfSimilRules = getSimilRules() 6:   servCategory = getservCategory() 7:   for each SimilRule in listOfSimilRules do 8:     ResIdentT ree = getResourceIdentTree() 9:     listOfResIdentT ree。add(ResIdentTree) 10:  end for 11:  for each RT in listOfOpenRT do 12:    RTcategory = getResIdnetifier() 13:    for each resCategory in listOfResIdent do 14:      if RTcategory = resCategory then 15:        listOfSimilarRT。add(RT ) 16:      end if 17:    end for 18:  end for 19:  BusServCI = getBusServCI(customerID) 20:  listOfCriticalCIs =getCriticalCIs (BusServCI, servCategory) 21:  if notempty (listOfSimilarRT ) and notempty (listOfCriticalCIs) then 22:    listofRTforCritCIs = findRTforCritCIs 23:    if notempty (listofRTforCritCIs) then 24:      listOfCorrelRT = listofRTforCritCIs 25:    end if 26:  end if 27:  listOfRelatedCIs = findServiceRelCIs 28:  if notempty (listOfRelatedCIs) then 29:    listOfRTforRelCis = findRTForRelCIs 30:    listOfCorrelRT = listOfRTforRelCis 31:  else 32:   doCAP(listOfRelatedCIs) 33:  end if 34: return listOfCorrelRT 35: end procedure

图 5 事件标记关联算法

 

开始时，开放RT列表以及相似准则将从标记系统分别由服务定义重新获取（lines4，5）。服务分类可以从服务标记获得（line 6）。具体已确认的同一相似准则的资源分类被添加到资源列表中（lines 7-10）同时对相似资源标记进行填充（lines 11-18）。这些步骤对应于活动图中的1a,1b和2分别在line20和lines21-26中得到实现。最后相关CIs的资源标记列表得以填充并返回关联CIs列表。Line32实现了约束自适应探针。

 

概念评估

A 约束自适应探针正规化

本节用于约束自适应探针问题的正式说明。同时我们提供了解决该问题的可行的算法。

在CAP中我们寻找一个包含探针子集的序列，这个序列可以在考虑事件最小的情况下确保能够手动探针到剩下CIs数目。假设服务独立树CIs中有一个发生了故障，我们的目的是找到故障的CIs并通过探针触发RT的生成。如果独立树过大并且所有的探针按顺序执行，那么整个探针过程会耗费很多时间。由于需要在探针完成后搜索标记系统，我们需要对探针的时间进行约束。这意味这序列测试的数量需要减少。

另一个引入的约束是同时进行探针过程的数量。多个探针同时进行会对网络造成负面影响。

问题（约束自适应探针）有如下约束

a） 连续测试数量不能超过预先设定的数字L

b）同时进行的测试数量不能超过预先设定的数字P

寻找到探针子集的序列使得受限制CIs的数量达到最小。

由于这个问题包含了动态诊断子问题（参照[9]），所以该问题是NP难题。我们给出了基于贪婪算法的算法作为CAP的近似解决方案。

定义：假设服务独立树包含n个CIs或者节点 ，这些节点可能是两种状态之一，两种状态分别是OK和FAILED。在之前的例子中独立树中的CIs代表了一个物理的组件（服务器，网路，集线器等等）或者软件的组件（Web服务等）。依赖于独立树的商务服务的状态由二元向量 给出，其中 为CI 的OK或者FAILED状态。

一次探针或者测试T是用于查询服务CIs信息的方法。我们用 表示一个由探针T测试的CIs的集合。如果CIs中有一个处于FAILED状态，探针T就会失败，如果所有N（T）中的CIs都处于OK状态，那么探针T成功。为了简化我们假设每次测试花费时间1个单位。

CIs之间的独立性是以独立性矩阵 的形式表示的，其中 表示 依赖于 即 。集合 表示 。

独立性矩阵和探针以如下方式联系：如果探针T状态为OK则BD(N(T))的状态为OK。

我们的阐述遵循了辛钦信息论的方法。 代表集合CIs N的一部分。 代表从N 中由集合 生成的一部分。

该部分的信息定义如下：

                                             (1)

       其中 是A的特征函数，求和是针对 的全部元素。 和 的关联信息定义如下：

                                         (2)

其中 是A在条件 下的条件概率。我们也考虑条件熵

                                             (3)

其中 是N上的归一化的计数。

图6中的贪婪约束自适应探测算法是约束活动探测问题的多项式近似解决方案。

 

贪婪约束自适应探测算法 输入: 探针T的集合，独立性矩阵D，资源约束P，时间约束L，服务节点N的重要部分 输出: 探针序列 的子集序列   初始化: do 1. Select p most informative probes  s。t。 are 2. if probe  returns FAILED then 3. while return

图 6 贪心约束自适应探测算法

 

B 实验评价结果

我们采用了有关实验来证实了经我们优化后的模型的优点。优化后的模型明显减少了用户的选择项。图7的y轴表示依赖树的深度。我们假设资源依赖是深度为11的二叉树，这样给定一个资源数为2048的完整系统。假设分类路径服从6到9的均匀分布，CAP对分类有额外作用。我们重复进行了4096次仿真。我们只选了前64次的结果,这样可以更清楚的展示。仿真显示使用基于分类相关性独立（柱图的浅色虚线部分）的效果，额外的成效是由CAP提供的（柱图的深色部分）。

仿真表明通过基于分类关联方法将服务标记和资源标记相关联能够对性能有很大的提升。而且约束自适应探测解决方案改进了基于分类的结果同时减少了人为干预的需求。

图 7 仿真结果

 

结论以及下一步的工作

本文测试了一种标记关联的创新方法，该方法能够提高事件、问题管理处理的准确性和有效性。更值得一提的是，我们提供了服务定义和配置管理系统中已部署架构的描述。该方法提出了一个基于梯度式关联的优化模型。在该梯度式关联中，由于描述标记关联的简化资源选择的服务/资源类似规则，服务分类得到了增强。我们进一步地描述了该方法是怎样利用贪婪约束自适应探测算法来动态的标记相关性所需的额外资源细节。由于监视系统的限制，这些细节不能直接获得。通过仿真证明，这种方法能够在准确分类和之后对标记子集的关联分析能力上提供显著的改进。

接下来我们计划把该关联模型扩展到可以处理不同事件标记系统的标记的模型中。该扩展模型适用于多层次供应商或者由多个同级的合作伙伴提供的多级别服务的异构服务环境中。还有，我们计划评价CAP算法的次优解决方案对于标记关联结果优化的影响。

 

致   谢

本文为2008年IBM T J Watson Research Center 暑期合作的研究成果。感谢IBM T J Watson Research Center的David博士给我们提出的宝贵意见。我们同时还要感谢Prof. Dr.  Heinz-Gerd Hegering 领导的MNM-Team给我们提出的宝贵的建议。