CN1650274A

CN1650274A - 操作管理方法和操作管理服务器

Info

Publication number: CN1650274A
Application number: CNA028295080A
Authority: CN
Inventors: 高桥大作; 吉位裕贵子; 加来义朗; 小野仁; 铃木洋; 河嶋千晶
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2002-12-26
Filing date: 2002-12-26
Publication date: 2005-08-03
Also published as: EP1577783A4; EP1577783A1; US7506195B2; AU2002359925B2; JP4318643B2; JPWO2004061681A1; AU2002359925A1; WO2004061681A1; US20050172162A1

Abstract

可以由软件单元来确定故障位置。收集在被监控的单元中出现的事件信息(步骤ST1)。接着，对收集到的事件信息进行分组以生成事件组(步骤ST2)。而且，在事件组与多个模式定义组之间比较事件信息发生模式，其中，在所述多个模式定义组中定义了在发生故障期间输出的事件信息的发生模式(步骤ST3)。然后，提取故障解决方案信息，其被预先与具有相似的事件信息发生模式的模式定义组关联起来(步骤ST4)。

Description

操作管理方法和操作管理服务器

技术领域

本发明涉及用于对目标设备的操作进行管理的操作管理方法、操作管理服务器以及操作管理程序，还涉及用于存储该操作管理程序的计算机可读的存储介质。更具体来说，本发明涉及有效地对受到管理的目标设备进行故障排除的操作管理方法、操作管理服务器以及操作管理程序，还涉及用于存储该操作管理程序的计算机可读的存储介质。

背景技术

近年来因特网访问环境的流行已导致对提高系统可靠性的努力。一种方法是为系统引入功能冗余。采用冗余设计，系统的某个部分中的故障不会使整个操作崩溃。该系统依然可以利用其它有效的功能来进行操作。

一般来讲，以消息的形式把服务器中出现的故障或其它问题事件报告给某些其它设备(例如，操作管理服务器)。在冗余系统中，一个功能中的故障将传播到其它相关功能，由此使得会发送更多错误消息。即，当服务器遇到异常时，该服务器并非一定是唯一生成错误消息的服务器。实际上，其它相关服务器也会发送错误消息。

错误消息的多个发送者的存在使得难以定位真正的问题源。通常把该任务委托给精通网络的工程师，他们可以基于他/她的经验来定位出问题。然而，某些缺乏经验的工程师要花费很长时间来恢复系统。对于企业网络，其恢复的延迟将对该公司的商业活动造成极大的影响。因而需要一种不依赖于单个维护工程师的技能就可以从故障中恢复的网络系统。

已提出的一种方案是配备一数据库，其存储有每个网络故障的记录以及由此生成的故障通知消息的时间序列。通过与数据库记录进行比较来检查从网络实际发送的消息，可以定位出故障。所提出的设备自动检索故障的位置，由此使得能够快速恢复网络系统。例如，参见特开第2001-257677号公报(图1)。

然而，在特开第2001-257677号公报(图1)中公开的设备针对的是网络上的通信故障。它不涉及任何有关如何处理在服务器上运行的应用或其它程序可能遇到的故障。所提出的设备未提供根据从服务器上的应用、中间件或OS(操作系统)产生的错误消息来调查故障源的功能。

当服务器故障产生多条消息时，现有技术不能使我们能够查明该服务器故障的真实位置。例如，假定服务器上的应用由于某种原因而终止。除了源应用本身，包括中间件和OS模块的某些其它程序也可能发出错误消息。特别是在多个服务器协同操作的环境中，另一服务器上的某些应用也会产生错误消息。

从以上讨论可知，多功能计算机系统上的一个故障可以影响在多个不同服务器上运行的各种应用，从而导致多个错误消息。尽管初始故障源自特定服务器上的特定软件程序，但是不容易仅通过单独考查接收到的消息来找到真实原因并定位出错误。

在多任务和/或多线程系统环境中情况更复杂。在这些系统中，在没有明显原因的情况下，内存管理的问题可能导致应用的性能劣化，或者可能使中间件模块崩溃，尽管该应用本身没有任何问题。很难找到这种问题的原因，这是因为问题的实际发源地不在执行得很差的软件程序中，而在某个其它地方。

发明内容

鉴于上述情况，本发明的目的是提供可以指出成为故障源的软件程序的操作管理方法、操作管理服务器、操作管理程序，以及存储有该程序的计算机可读的存储介质。

为实现上述目的，本发明提供了一种图1所示的操作管理方法。将该方法设计成按以下方式执行操作管理任务。首先，从多个监控目标对象收集事件信息(步骤ST1)，其中，所述多个监控目标对象是在服务器上执行的多个功能。然后通过对收集到的多条事件信息进行分组来生成事件组(步骤ST2)。按事件信息的发生模式对该事件组与多个模式定义组进行比较(步骤ST3)，其中，每个模式定义组定义了在发生特定故障时从多个监控目标对象输出的事件信息的发生模式。随后，提取故障对策信息，该故障对策信息被预先与按事件信息的发生模式类似于所述事件组的模式定义组关联起来，并且该故障对策信息指示成为故障原因的监控目标对象(步骤ST4)。

根据上述操作管理方法，把由多个监控目标对象产生的事件信息收集起来并组合成事件组。然后对该事件组与多个模式定义组进行比较。当找到按时间信息的发生模式与该事件组相似的模式定义组时，提取被预先与找到的模式定义组关联起来的故障对策信息。该故障对策信息指示成为故障原因的监控目标对象。

此外，为实现上述目的，提供了一种用于管理服务器的操作管理方法。该方法包括以下步骤：收集输入到服务器的命令；通过对收集到的多个所述命令进行分组，来生成操作历史记录信息；按所述命令的输入模式，对多个操作模式信息与所述操作历史记录信息进行比较，所述操作模式信息定义成为故障发生原因的命令输入模式；以及提取故障对策信息，该故障对策信息已被预先与按所述命令的输入模式类似于所述操作历史记录信息的所述操作模式信息关联起来，并且该故障对策信息表示成为故障原因的所述监控目标对象。

根据上述操作管理方法，把输入到服务器的命令收集起来并组合成操作历史记录信息。然后对操作模式信息与该操作历史记录信息进行比较。当找到按命令的输入模式与该操作历史记录信息相似的特定操作模式信息时，提取已被预先与该操作模式信息关联起来的故障对策信息，该故障对策信息表示成为故障原因的监控目标对象。

根据结合附图的以下详细说明，本发明的上述和其他目的、特征以及优点将变得显见，这些附图通过示例例示了本发明的多个优选实施例。

附图说明

图1是本发明的概念图。

图2示出使用故障信息回归型解决方法的示例。

图3示出消息标准化过程。

图4示出配置管理数据的示例结构。

图5示出事件信息分组过程的概念。

图6示意性地示出比较过程。

图7示出事件组匹配和对策信息输出的示例。

图8示出比较结果排序过程。

图9是示出由比较部执行的过程的流程图。

图10示出设有故障检测功能的示例系统配置。

图11示出在本发明一实施例中使用的操作管理服务器的示例硬件配置。

图12是示出操作管理服务器的内部结构的框图。

图13示出硬件配置数据的示例数据结构。

图14示出软件配置数据的示例数据结构。

图15示出网络配置数据的示例数据结构。

图16示出系统配置数据的示例数据结构。

图17是消息分组过程的流程图。

图18示出事件分组的示例过程。

图19示出事件组日志的示例数据结构。

图20示出客户数据库的示例数据结构。

图21示出事件模式数据库的示例数据结构。

图22示出当日事件日志的示例数据结构。

图23示出当日事件组日志的示例数据结构。

图24是模式匹配过程的流程图。

图25是示出预处理的详情的流程图。

图26是示出重复事件过滤过程的流程图。

图27是事件模式提取过程的流程图。

图28示出临时事件模式数据库的示例数据结构。

图29是组合匹配过程的流程图。

图30是信息输出过程的流程图。

图31是以往事件检查过程的流程图。

图32是后处理顺序的流程图。

图33示出信息的流动。

图34示出事件组检索屏面的示例。

图35示出事件选择屏面的示例。

图36示出分析结果屏面的示例。

图37示出历史记录表的示例数据结构。

图38示出操作模式数据库的示例数据结构。

具体实施方式

下面参照附图对本发明的优选实施例进行描述。

以下说明从对本发明的概述开始，然后进行到本发明的更具体的实施例。

图1是本发明的概念图。在图1中，操作管理服务器1执行根据本发明的操作管理方法。该操作管理服务器1连接到多个服务器2到4。在服务器2上运行的软件程序包括应用程序2a、中间件程序2b以及OS程序2c，这些软件程序都属于操作管理服务器1监控的处理对象。在其它服务器3和4上运行着类似的软件程序。

操作管理服务器1具有预先配备好的模式定义组数据库1a和故障对策信息数据库1b。模式定义组数据库1a存储有多个模式定义组，每个模式定义组定义在发生特定故障时可能从多个监控目标对象产生的事件信息的模式。故障对策信息数据库1b存储有故障对策信息，该故障对策信息包含有关可能是故障原因的监控目标对象的信息。预先把这些故障对策信息与对应的模式定义组关联起来。具体来说，故障对策信息包含以下数据项：故障位置、故障原因，以及针对故障的对策。在操作中，操作管理服务器1执行以下任务：

首先，操作管理服务器1从多个监控目标对象收集事件信息(步骤ST1)，这里，术语“监控目标对象“是指在服务器上执行的各种功能。操作管理服务器1接着通过对所收集到的多条事件信息进行分组来生成事件组(步骤ST2)。然后，操作管理服务器1按照事件信息的发生模式，对生成的事件组与模式定义组数据库1a中的每个模式定义组进行比较(步骤ST3)。作为该比较过程的结果，操作管理服务器1按照事件信息的发生模式找到与给定事件组相似的特定模式定义组。操作管理服务器1接着查询故障对策信息数据库1b，以提取出与所找到的匹配模式定义组相关联的故障对策信息，该故障对策信息表示成为故障原因的监控目标对象(步骤ST4)。这里，两组之间在事件信息的发生模式方面的相似性是指它们共有至少一个公共事件记录。

根据上述操作管理方法，把从目标对象收集到的事件信息排序成多个组。按照事件信息的发生模式对一个所得事件组与多个模式定义组进行比较。从而找到具有类似发生模式的模式定义组，并提取出与该模式定义组相关联的故障对策信息。

所提出的方法允许管理员基于检索到的故障对策信息，对操作管理服务器进行维护，以识别出故障的位置和原因，以及针对该故障的可能对策。对于没有关联模式定义组的事件组，在解决了该故障时创建针对该事件组的新模式定义组，并把该新模式定义组存储在模式定义组数据库1a中。此外，把一新故障对策信息输入到故障对策信息数据库1b中。由此其它维护工程师在必要时可以重用某些维护工程师以往针对故障所采用的对策或其它动作。

不管单个操作员的能力如何，上述操作管理方法都将减少解决故障所需的时间。它使用模式定义组和故障对策信息中的有关以往故障和对策的累积知识，由此使得可以快速和恰当地应对类似故障。当解决了一个新发现的故障时，将该故障的信息登记为模式定义组和故障对策信息，这排除了他/她亲自把该故障的解决告知别人的必要。该特征防止了由于采取了不相关的措施而使故障长时间得不到解决。

下面将描述在本实施例中所提出的故障检测功能(故障信息回归型解决方法)的概念。

图2示出使用故障信息回归型解决方法的示例。正如所见，多个服务器11和12经由网络13连接到操作管理服务器20。一个服务器11具有包括以下功能的内嵌监管功能：硬件监控、软件监控、性能监控、安全性监控以及配置监控。另一服务器12也具有这种监管功能。

硬件监控功能跟踪在服务器11中使用的硬件模块的动作(例如，监视硬盘驱动器的写入差错率)。软件监控功能是多个模块的集合，每个模块都监控一特定软件，如OS程序、中间件程序或应用程序。性能监控功能监管服务器11的操作状态(例如，空闲存储空间)。安全性监控功能监视对服务器11的非法访问企图。配置监控功能监控服务器11的配置变化。

当诸如一错误的特定事件发生时，每个监管功能生成错误事件。生成详细描述该错误事件的事件信息，并以消息的形式经由网络13将其传送到操作管理服务器20。这种消息31和32例如携带服务器11和12生成的日志信息和配置变化通知。

操作管理服务器20包括事件提取表21、模式定义组22、对策信息表23、消息标准化部24、分组部25、比较部26以及对策输出部27。

事件提取表21是包含用于对从已接收消息提取必要事件信息的规则进行定义的信息表。

模式定义组22是对发生故障时监测到的事件的组合进行限定的信息。

对策信息表23是包含与对应于发生故障时可能遇到的各种事件模式的故障对策有关的信息的信息表。

消息标准化部24对从服务器11和12接收到的消息进行标准化，使得它们符合预定数据结构。更具体来说，当接收到消息时，消息标准化部24参照事件提取表21，以获得与每条接收消息相关的事件信息提取规则。消息标准化部24接着根据所获得的规则，从消息中提取事件信息。

然后，分组部25将所提取出的事件信息排序成多个组，每个组包括相互关联的多条事件信息。预先定义了特定监控目标对象(例如，装置、OS、中间件、应用)之间的关联性。这些相关联的监控目标对象在预定的短时段内产生的事件信息被视为是相互关联的。分组部25对给定的事件信息执行这种分组任务，由此生成事件组33。事件组33是相互关联的多条事件信息的集合。

比较部26对所生成的事件组33与模式定义组22进行比较，以在模式定义组22中找到完全匹配或最佳匹配。

当找到类似模式定义组时，对策输出部27参照对策信息表23获得与该模式定义组相关的对策信息。对策输出部27输出所获得的对策信息，以在与操作管理服务器20相连接的终端控制台或类似设备上显示该对策信息。

在上述系统中，按以下方式对从服务器11和12发送到操作管理服务器20的消息31和32进行处理。

首先，消息标准化部24把这些消息31和32转变成具有统一格式的事件信息。

图3示出该消息标准化过程。在图3的示例中，消息31和32携带有以下数据项：“序号”、“时间”、“主机名”以及“事件详情”。消息的序号域包含使得可以把该消息与其它消息唯一地区分开来的标识码。时间域表示事件的发生时间。主机名域包含产生该消息的服务器的主机名。主机名被用来标示网络13上的每个特定设备。事件详情域示出输出该服务器中的源监管功能的事件的详情。

当接收到这些消息31和32时，消息标准化部24参照事件提取表21。

事件提取表21具有以下数据域：“硬件/软件(HW/SW)名”、“关键字”以及“提取规则”。消息信息的提取规则由在同一行中的多个数据项的关联性形成。HW/SW名域给出引起事件的对象的名称。关键字域包含用于确定成为事件发生原因的对象的字符串。提取规则域描述了如何从给定消息提取必要的错误代码。

消息标准化部24可以通过参照上述事件提取表21，根据给定的消息31和32来生成事件信息31a和32a。更具体来说，对消息31和32的接收使消息标准化部24查看事件提取表21的关键字域。它接着对每个消息的主体进行扫描，以找出关键字。当找到关键字时，消息标准化部24参照与该关键字对应的提取规则域。根据该提取规则，消息标准化部24从该消息的事件详情域中提取出错误代码。

例如，考虑消息31。当接收到该消息31时，消息标准化部24首先从事件提取表21取得关键字“Kernel”。由于该关键字存在于消息31中，所以消息标准化部24接着参照对应的提取规则域，该提取规则域的内容为：“在‘]’之后找到一空格，然后提取文本，一直到’：’。”根据该指示，消息标准化部24提取文本串“WARNING 999”。

这时，消息标准化部24生成包含错误代码的事件信息31a和32a。每个事件信息31a和32a具有以下数据域：“序号”、“时间”、“主机名”、“HW/SW名”以及“错误代码”。序号域、时间域以及主机名域包含在消息31和32的对应域中找到的内容。另一方面，HW/SW名域和错误代码域是从与找到的关键字关联起来的事件提取表21的对应域中取得的。

按此方式，提取了标准化的事件信息31a和32a。

在标准化之后，分组部25把相互关联的事件信息组合成一组。具体来说，分组部25具有配置管理数据和多个监控目标对象之间的关联性的预定定义的集合。

图4示出该配置管理数据的示例结构，该示例结构表示层级形式的多个监控目标对象。位于最顶层的是系统51和52，按顺序接着是路由器53和54、服务器55到59和一存储装置60、中间件程序61到63以及应用程序64到66。

所有这些监控目标对象都由各自的标识符来表示，它们之间的关系如下。系统51和52例如是不同客户的网络系统。与这些系统51和52相关联的是路由器53和54，路由器53和54接收和转发分组，以使得能够接入系统51和52。部署在系统51和52中的服务器55到59与路由器53和54相关联。与路由器54相关联的还有系统52中的存储装置60。安装在服务器55中的中间件程序61到63与该服务器55相关联。与中间件程序61相关联的应用程序64到66是由该程序61管理的软件应用。

如从该示例看到的，分组部25被赋予了定义不同监控目标对象之间的关联性的数据集。该数据集允许分组部25识别相互关联的事件信息。更具体来说，利用在树结构中对这些监控目标对象定义的父-子关系来组织它们。基于该树结构，分组部25把特定的一组生成事件信息识别为相互关联的。

图4所示的配置管理数据还可以用于在维护作业中抑制事件。即，当监控目标对象经受维护作业时，有必要控制与所维护的对象相关的事件的发生。还希望在层级中处于受关注监控目标对象下方的监控目标对象应受到控制，以防止在这期间产生新事件。

具体来说，当上层监控目标对象(例如，中间件)处于维护模式时，即使其从属的下层监控目标对象(例如，应用)本身没有任何问题，它也可能产生错误事件。由于这种事件在维护活动中完全不必要，所以必须要求下层监控目标对象在维护时段不产生事件。

例如，假定图4所示的路由器53经受维护。位于路由器53下方的对象包括服务器55到57、中间件程序61到63以及应用程序64到66，这些对象在路由器53的维护期间可能产生事件。因此要对这些下层结构组件进行事件抑制。为此，把分组部25设计成在特定监控目标对象经受维护动作时，通过查询其本机配置管理数据来指定这种组件。分组部25还确定抑制时段并把事件抑制请求发送给相关监控目标对象。

也可能发生经受维护的监控目标对象在维护任务期间产生某些事件的情况。这些事件经受分组过程，并被存储为对经受维护的对象的问题进行描述的模式定义组。

由上可见，分组部25通过使用配置管理数据来把事件信息排序成多个组，以识别它们的关系。

图5示出事件信息分组过程的概念。消息标准化部24向分组部25提供如图5所示的一系列标准化事件信息71到73。分组部25在所接收到的事件信息中找出相互关联的事件信息，并接着把它们形成为一事件组33。给该事件组33指配一ID(标识符)，以唯一地标识每个事件组。除该ID之外，事件组33还包含详细数据项，该详细数据项与其原事件信息相同。

把生成的事件组33传给比较部26。比较部26对该事件组33与模式定义组22进行比较。

图6示意性地示出一比较过程。模式定义组22包括硬件事件、OS事件以及中间件程序和应用程序在发生故障时可能产生的事件的各种组合。通过对给定事件组33与所述多个模式定义组22进行比较(匹配)，比较部26识别出引起事件组33的故障。

当找到了与给定事件组33对应的模式定义组时，接着应当提取与该模式定义组对应的对策信息。

图7示出事件组比较和对策信息输出的示例。从图7可见，事件组33a的HW/SW名域和错误代码域与一个模式定义组22a的对应部分吻合。该模式定义组22a的ID为“PT0008”。对策输出部27接着检索对策信息表23，以找出与该ID“PT0008”对应的对策信息。

对策信息表23具有以下数据域：“ID”、“原因”、“对策”以及“紧急级”。在同一行中相关联的多个数据域形成一条数据记录。该对策信息的ID域存储为进行标识而赋给该信息的唯一标识符。对策信息ID与它们的对应模式定义组ID在它们的低四位数字中共用相同的值。例如，模式定义组“PT0008”与对策记录“000008”相关联。原因域表示故障的原因，其包括与可能涉及该故障的某些监控目标对象(例如，盘)有关的信息。对策域是表示故障对策方法的信息。紧急级域表示故障的重要性。在该域中具有更大值的故障要求更迅速的动作。

在图7的示例中，对策输出部27提取与模式定义组22a对应的对策信息。根据提取的对策信息23a，当前故障是由“由于硬盘驱动器的老化导致性能劣化”引起的。建议对策为：“更换RAID盘”。该对策信息的紧急级为“2”。

比较部26不仅找到与给定事件组完全吻合的模式定义组，而且可以提取类似的模式定义组。如果是这种情况，则比较部26把一些附加信息放到所提取出的模式定义表中，以记录已找到多少匹配和失配模式定义组。具体来说，该附加信息包括匹配数和失配数。术语“匹配数”是指找到的匹配事件信息的数目。术语“失配数”是指找到的失配事件信息的数目。当在被比较的模式定义组中缺失某些事件信息时，失配数将为负值。在模式定义组中存在某些额外的事件信息的情况下，失配数将为正值。

在显示与所提取出的模式定义组对应的对策信息之前，对策输出部27根据它们的匹配数和失配数，按合适的顺序对这些信息进行排序。

图8示出比较结果排序过程，其中，对一个事件组81与六个不同的模式定义组进行比较。它们的ID为：PT1、PT2、PT3、PT4、PT5以及PT6。

[ST1] 比较部26首先把给定事件组81与每个模式定义组进行比较。在图8的示例中，事件组81包括事件信息“a”、“b”、“c”以及“d”。模式定义组“PT1”包括事件信息“a”、“b”以及“c”。模式定义组“PT2”包括事件信息“a”和“c”。模式定义组“PT3”包括事件信息“a”、“x”、“y”、“x”以及“q”。模式定义组“PT4”包括事件信息“a”、“b”、“c”、“d”以及“y”。模式定义组“PT5”包括事件信息“a”、“b”、“c”以及“d”。模式定义组“PT6”包括事件信息“d”。

与每个单独模式定义组的比较产生成对的匹配数和失配数。具体来说，对于ID＝“PT1”的模式定义组，比较产生匹配数3和失配数-1。对于ID＝“PT2”的模式定义组，比较产生匹配数2和失配数-2。对于ID＝“PT3”的模式定义组，比较产生匹配数1和失配数+4。对于ID＝“PT4”的模式定义组，比较产生匹配数4和失配数+1。对于ID＝“PT5”的模式定义组，比较产生匹配数4和失配数0。对于ID＝“PT6”的模式定义组，比较产生匹配数1和失配数-3。

[ST2] 根据这些比较结果，对策输出部27首先按匹配数的降序对这些模式定义组进行排序。在本实施例中，经排序的组呈以下顺序：“PT4”、“PT5”、“PT1”、“PT2”、“PT3”、“PT6”。

[ST3] 然后对策输出部27根据模式定义组的失配数对它们进行局部排序。此时，失配数绝对值越小的组排在越高的位置处。其结果如下：“PT5”、“PT4”、“PT1”、“PT2”、“PT6”、“PT3”。

[ST4] 最后，对策输出部27检索与每个模式定义组对应的对策信息。然后查看所检索到的对策信息的紧急级域，并对那些具有超出预定阈值的高紧急级的信息作标记。对策输出部27在把这些对策信息输出到监视器屏幕上时，对那些被标记的对策信息进行强调。例如，假定模式定义组“PT2”和“PT5”与具有高紧急级的对策相关联，那么它们的对应对策信息会被高亮显示。

现在，已基于在监控目标对象处发生的事件获得了一组对策信息，对策输出部27以表征某些指定信息的方式显示经排序的对策信息。可以通过使用与其它颜色区分开来的特殊颜色来实现强调。

图9是示出由比较部执行的过程的流程图。该过程包括以下步骤：

(步骤S101)比较部26获得一事件组33。使用自然数N来表示该事件组33中包括的事件信息的数量。

(步骤S102)比较部26执行重复事件过滤，然后根据含有多个模式定义组22的数据库来创建临时表。临时表充当只由可以应用到受关注系统的模式定义组22形成的数据库。更具体来说，临时表容纳几个不同数据库。一个数据库存储可应用于所有系统的公共模式定义组。另一数据库包含可以针对每个客户的特定系统配置生成的客户特定模式定义组。又一数据库存储与这些模式定义组对应的故障信息。

(步骤S103)比较部26把1赋给变量I，还把N赋给变量J(即，I＝1，J＝N)。然后并行地执行以下步骤S104到S106。

(步骤S104)比较部26对故障信息数据库进行检索，以找到与第I个事件信息相关联的故障信息。

(步骤S105)比较部26对客户特定模式定义组数据库进行搜索，以找到与第I个事件信息相关联的模式定义组。

(步骤S106)比较部26对公共模式定义组数据库进行搜索，以找到与第I个事件信息相关联的模式定义组。

(步骤S107)比较部26确定J＝I是否成立。如果J＝I，那么过程前进到步骤S109。否则，过程进行到步骤S108。

(步骤S108)比较部26使I递增(即，I＝I+1)。然后过程返回至步骤S104到步骤S106。

(步骤S109)比较部26把1赋给变量I(I＝1)，并把所找到的模式定义组的数量赋给变量J。

(步骤S110)比较部26选择在步骤S105和S106处已找到的第I个模式定义组。从该模式定义组中，比较部26对与给定事件组具有公共项的事件信息进行提取和计数。

(步骤S111)比较部26确定I＝J是否成立。如果J＝I，那么过程前进到步骤S113。否则，过程进行到步骤S112。

(步骤S112)比较部26使I递增(I＝I+1)。然后过程返回到步骤S110。

(步骤S113)比较部26对事件进行排序。

(步骤S114)比较部26检查是否存在以往的相同事件。

(步骤S115)对策输出部27提取其事件信息与所述事件组中的事件信息至少部分地相符的模式定义组。它接着显示所提取的模式定义组的对策信息，这包括与该故障的可能原因和针对这些原因的合适对策有关的信息。

通过以上处理步骤，操作管理服务器100收集与在系统中发生的事件有关的信息，并把它们用作事件组，以识别故障的原因并以自动方式提供对策。

累积的模式定义组使操作管理服务器能够快速地发现与以往发生过的故障类似的故障。模式数据库还提供有关与每个特定事件模式相关联的原因和对策的信息。该特征减少了解决故障所需的时间。

操作管理服务器集中管理许多客户的模式定义组和其它数据，由此帮助管理员在必要时对它们进行更新。利用模式定义组，客户可以通过使用其它客户的类似经验来定位出他们自己的故障。模式定义组可以反映操作组织的策略，或包括从软件开发商提供的产品支持信息。管理员将这些模式定义组登记到操作管理服务器中，以提供更好的服务器监管服务。

下面的部分将描述利用带有上述问题检测功能的操作管理服务器，对客户系统进行远程维护服务的具体示例。

图10示出其中设有故障检测功能的示例系统配置。在图10的示例中，操作管理服务器100经由网络14连接到中继设备210。连接到中继设备210的其它设备有多个服务器220、230以及240。这些服务器220、230以及240和中继设备210属于客户系统。操作管理服务器100具有模式匹配引擎110。该模式匹配引擎110实际承担以下任务：从服务器220、230以及240收集信息；将它们与模式定义组进行比较；以及提供相关对策信息。

图11示出在本发明一实施例中使用的操作管理服务器的示例硬件配置。示出的操作管理服务器100具有用于控制整个服务器系统的CPU(中央处理单元)101，CPU 101经由公共总线与其它单元相连接。与该CPU101相连接的有：随机存取存储器(RAM)102、硬盘驱动器(HDD)103、图形处理器104、输入装置接口105以及通信接口106。

RAM 102充当以下对象的临时存储器：CPU 101执行的OS(操作系统)程序和应用程序的全部或一部分；以及其它在运行时(runtime)操纵的其它各种数据对象。HDD 103存储操作系统和各种应用的程序和数据文件。

图形处理器104耦接到监视器111。图形处理器104根据来自CPU101的绘图命令生成视频图像，并把它们显示在监视器111的屏幕上。输入装置接口105用于接收来自外部输入装置(如键盘112和鼠标113)的信号。经由总线107把输入信号提供给CPU 101。

通信接口106连接到网络14，以与在网络14上的其它计算机交换数据。

上述硬件系统为本发明所提出的处理功能提供了平台。虽然图11只示出例示用的操作管理服务器100，但是相同的硬件配置也可以应用于中继设备210和服务器220、230以及240。

图12是示出操作管理服务器的内部结构的框图。从图12可见，操作管理服务器100具有以下组件：模式匹配引擎110、事件组121、客户数据库122、杂项配置信息数据库123、事件模式数据库124、临时事件模式数据库125、信息提取部130、环境设定部140、当日事件日志151、当月事件日志152、当日事件组日志153、当月事件组日志154以及结果文件155。

模式匹配引擎110与其它功能协同控制整个模式匹配过程。

事件组121由发自服务器220、230以及240的消息形成。

客户数据库122存储有关客户的信息。

杂项配置信息数据库123存储与每个客户的(硬件和软件中的)系统配置有关的信息。

事件模式数据库124是与在所支持的系统中可能发生的各种故障相关的事件模式的数据库。事件模式包括模式定义组和对策信息。

临时事件模式数据库125存储根据每个客户的系统配置从事件模式数据库124提取的事件模式。

信息提取部130基于事件模式数据库124，通过提取与所服务的特定客户的系统相关的事件模式，来建立该临时事件模式数据库125。

当日事件日志151是用于保持与在一天内发生的故障相关的事件模式标识符及比较结果等信息的存储空间。

当月事件日志152是用于保持与在一个月内发生的故障相关的事件模式标识符及比较结果等信息的存储空间。

当日事件组日志153是用于存储在一天内生成的事件组的存储空间。

当月事件组日志154是用于存储在一个月内生成的事件组的存储空间。

结果文件155包含针对特定事件组检索到的对策信息的列表。

杂项配置信息数据库123包含：硬件配置信息、软件配置信息、网络配置信息以及系统配置信息。每条配置信息具有使得能够链接其它数据的主键数据域。

图13示出硬件配置信息的示例数据结构。硬件配置信息123a具有以下数据域：“设备ID”、“系统名”、“主机名”、“产品名”、“CPU数”、“存储器容量”、“硬盘容量”以及“LAN数”。

设备ID域示出作为服务器操作的计算机的标识符。该设备ID是以这样的方式指配的代码：即，在系统内其不会受到主机名长度的影响。系统名域表示服务器为其工作的系统(或服务的类型)的名字。主机名域示出指配给服务器的名字(用于在网络中使用，或用于管理目的)。产品名域包含服务器的计算机平台的产品名。CPU数域表示安装在服务器上的CPU的数目。存储器容量域示出服务器上的主存储器的容量。硬盘容量域示出连接到服务器的硬盘单元的存储容量。LAN数域表示安装在服务器上的网络接口卡的数目。

图14示出软件配置信息的示例数据结构。该软件配置信息123b具有以下数据域：“设备ID”、“软件类别”、“软件名”、“版本号”以及“修订版号”。

设备ID域也存在于上述硬件配置信息123a中，其充当在各种配置数据集中的其它数据项之间建立关联性的主键域。软件类别域示出受关注软件程序的类别(例如，OS、中间件、应用等)。软件名域包含该程序的名字。版本号域包含程序的版本。修订版号域示出对程序施加的缺陷修正(软件补丁)的版本。

图15示出网络配置信息的示例数据结构。该网络配置信息123c具有以下数据域：“客户码”、“设备ID”、“主机名”、“IP”、“接口名”以及“IP类别”。客户码域给出表示哪个客户在操作该系统的标识符。设备ID域也存在于上述硬件配置信息123a和软件配置信息123b中，其充当在这些数据集中的其它数据项之间建立关联性的主键域。主机名域包含与硬件配置信息123a中相同的项。IP域示出指配给该系统的IP地址。接口名域示出指配给设备中的每个网络接口卡的标识码。IP地址类型域示出IP地址的类型，该类型要么为“V”(vertual)，要么为“R”(Real)。这里，“V”(vertual)代表虚拟IP地址。“R”(Real)代表真实IP地址。

图16示出系统配置信息的示例数据结构。该系统配置信息123d具有以下数据域：“客户码”、“设备ID”、“关联主机名”、“关联类别”以及“关联软件”。客户码域包含与网络配置信息123c在其客户码域中具有的值相同的值。设备ID域包含与硬件配置信息123a、软件配置信息123b以及网络配置信息123c在它们各自的设备ID域中具有的值相同的值。关联主机名域包含关联计算机的设备ID。当该域具有值“PP9999”时，它意味着与其它设备不存在联系。

根据上述配置，操作管理服务器100执行下述各种任务。

首先，说明消息分组过程。

图17是消息分组过程的流程图。该过程包括以下步骤：

(步骤S1)信息提取部130接收消息。具体来说，假定一服务器遇到错误事件。然后该服务器发送消息，以把错误事件详情通知给操作管理服务器100。在操作管理服务器100中，把接收到的消息提供给操作管理服务器100的模式匹配引擎110。

(步骤S2)信息提取部130除了修改所接收到的消息的格式(即，标准化)以外，还通过查询杂项配置信息数据库123来识别管理的对象(硬件、软件等)。

(步骤S3)信息提取部130参照杂项配置信息数据库123来考查一个受管理对象与其它多个受管理对象之间的关联性。

(步骤S4)信息提取部130测试是否接收到任何相关事件。若为是，则过程前进到步骤S5。若为否，则过程进行到步骤S6。

(步骤S5)信息提取部130把相关事件放到相关组中。

(步骤S6)信息提取部130确定在步骤S1处消息到达之后是否已经过预定时间。若为是，则信息提取部130完成事件组，并把控制交给模式匹配引擎110。若为否，则过程进行到步骤S4。

图18示出事件分组的示例过程。例如，假定输入了消息“事件11”。这引起包含该事件信息的新事件组411的创建。随后，消息“事件21”到来，并且相应地生成包括该事件信息的另一事件组421。按类似方式，随后的消息“事件31”引起生成包含该事件信息的又一事件组431。

现在假定接收到与“事件11”相关的再一消息“事件12”。把该新事件信息加入到新事件组411，这使得事件组411发展成包含两个事件信息的事件组412。然后消息“事件13”到达。把该“事件13”的事件信息加入到事件组412，这使得事件组412发展成包含三个事件信息的事件组413。

操作管理服务器100基于按上述方式排序成多个组的事件信息，来建立用于内部使用的某些其它数据库。

图19示出事件组的示例数据结构。示出的事件组121具有以下数据域：“事件组ID”、“组成员序号”、“事件ID”、“客户ID”、“设备ID”、“接口名”、“发生时间”、“源类别”、“源简称”、“过滤”以及“消息”。

事件组域包含赋给每个事件组的标识符。组成员序号域示出提供给同一事件组的每个成员的序号。注意，一条事件信息构成事件组的一条。事件ID域示出赋给每个事件的标识符。客户ID域示出对已产生该事件的系统进行操作的客户的标识符。设备ID域示出已产生该事件的服务器的标识符。接口名域示出发送了携带有本事件信息的消息的网络接口的标识符。发生时间域示出该消息何时到达操作管理服务器100。源类别域示出哪个目标对象产生了该事件。源简称域示出该源目标对象的简称。过滤域表示是否应用过滤。消息域示出该事件信息的消息的内容。

尽管图19例示了事件组121的数据结构，但也可将相同或类似的数据结构应用于当日事件组日志153和当月事件组日志154。

图20示出客户数据库的示例数据结构。所示客户数据结构122具有以下数据域：“客户ID”、“客户名”、“联系人”以及“联系信息”。客户ID域示出客户的标识符。客户名域示出客户的名字。联系人域示出通过其可以联系到客户的人的名字。联系信息域示出客户的联系信息，如电话号码。

图21示出事件模式数据库的示例数据结构。所示事件模式数据库124具有以下数据域：“事件模式ID”、“事件序号”、“对象类别”、“对象简称”以及“错误消息”。事件模式ID域包含由该事件模式数据库管理的唯一标识码。事件序号域示出赋给属于同一事件模式的每个成员事件信息的标号。对象类别域示出目标对象所属的类别。错误消息域提供所产生的事件的内容。

虽然图21示出了事件模式数据库124的示例数据结构，但是也可将相同或类似的数据结构应用于临时事件模式数据库125。

图22示出当日事件日志的示例数据结构。所示当日事件日志151具有以下数据域：“事件组ID”、“匹配过程时标”、“事件模式ID”、“事件数目”以及“命中数”。事件组ID域包含事件组的标识码。匹配过程时标域表示模式匹配引擎110在何时执行模式匹配过程。事件模式ID域示出在模式匹配过程中提取的事件模式的标识符。事件数目域示出处于由事件模式ID域所指定的事件模式中的事件信息的数目。命中数域存储在比较事件组中可以找到的全部具有同一事件模式ID的事件信息的数目。

可以根据在该当日事件日志151中所示的事件数目和命中数来计算事件模式的权重。例如，把较大的权重(意味着较大的重要性)赋予具有较大命中数的事件模式。可以预先计算出这种权重，并将其登记到当日事件日志151中。

图23示出当日事件组日志的示例数据结构。所示当日事件组日志153具有以下数据域：“事件组ID”、“事件序号”、“事件ID”、“客户ID”、“设备ID”、“发生时间”、“事件类型”、“错误编号/消息”、“事件模式ID”、“重复事件ID数”以及“匹配结果”。

事件组ID域包含事件组的标识符。事件序号域示出赋给所产生的每个事件的序号。事件ID域包含每条事件信息的标识符。客户ID域示出对产生事件的系统进行操作的客户的标识符。设备ID域示出产生事件的服务器的标识符。时间域表示事件何时发生，而事件类型域示出事件是什么种类的(例如，错误、告警)。错误编号/消息域给出表示事件内容的标识符。事件模式ID域包含被选择为与该事件组相关的事件模式的标识符。“重复事件ID数”域给出检测到的事件模式的数目。匹配结果域示出对与检测到的事件模式对应的对策信息的说明。

下面更详细地阐述模式匹配过程。

图24是模式匹配过程的流程图。该过程包括以下步骤：

(步骤S11)模式匹配引擎110执行预处理，该预处理例如包括在RAM 102中创建工作表。

(步骤S12)模式匹配引擎110从事件组121中选择一个事件组，并执行重复事件过滤。这里术语“重复事件过滤”是指对由同一服务器产生的多条相同事件信息进行提取并挑选出重复的事件信息。

(步骤S13)模式匹配引擎110检查所选事件组中包括的事件信息的数目。如果存在一个或没有事件信息，那么过程跳到步骤S19，这是因为这种事件组不在本匹配过程的范围内，该匹配过程试图基于多个事件信息的发生模式来识别问题。如果该事件组具有两条或更多条信息，那么过程前进到步骤S14。

(步骤S14)模式匹配引擎110对临时事件模式数据库125进行扫描，以提取用于随后的组合匹配的事件模式。

(步骤S15)模式匹配引擎110确定是否已提取出至少一个事件模式。如果未提取出模式，那么过程跳到步骤S19。如果找到至少一个事件模式，那么过程前进到步骤S16。

(步骤S16)模式匹配引擎110执行组合匹配。更具体来说，其开始在两组事件记录之间进行穷尽式比较。一方是给定事件组中的一组经排序的事件信息，而另一方是属于从临时事件模式数据库125提取出的事件模式的一组事件信息。

(步骤S17)模式匹配引擎110输出上述匹配过程的结果。例如，其输出匹配结果，以显示在操作管理服务器100的监视器屏幕上。

(步骤S18)模式匹配引擎110检查以外事件。更具体来说，模式匹配引擎110查询当月事件日志152，以查看是否存在相同的事件日志条目。如果找到了这种事件日志条目，那么模式匹配引擎110把该事件追加到结果文件。

(步骤S19)模式匹配引擎110执行后处理。即，模式匹配引擎110把匹配结果存储在当日事件日志151和当月事件日志152中。

以下对图25的每个步骤进行详细描述。

图25是示出预处理的详情的流程图。该过程包括以下步骤：

(步骤S21)模式匹配引擎110创建新工作表。例如，创建针对当日事件组日志153和当日事件日志151的工作表。

(步骤S22)模式匹配引擎110对工作区进行初始化。

(步骤S23)模式匹配引擎110验证给定的参数。更具体来说，其确定是否为“事件组ID”和“目的文件夹”提供了有效输入。如果两项都缺少有效输入，那么模式匹配引擎110生成一错误，然后使控制返回到图24的主例程。

下面描述重复事件过滤过程。

参照图26的流程图，重复事件过滤过程包括以下步骤：

(步骤S31)模式匹配引擎110从给定事件组121读出一条记录(事件信息)。例如，按客户ID、设备ID以及错误编号/消息的项顺序来执行该读取操作。

(步骤S32)模式匹配引擎110确定是否已成功执行读取操作。如果已读取事件组记录，那么过程前进到步骤S33。如果没有记录读取，那么过程返回到图24的主例程。

(步骤S33)模式匹配引擎110确定是否滤除所述记录。具体来说，当本记录与先前记录具有相同的设备类型和错误编号/消息的域值时，必须滤除该记录。如果是这种情况，那么过程进行到步骤S31。如果没有必要过滤，那么过程前进到步骤S34。

(步骤S34)模式匹配引擎110把留下的事件组存储到当日事件组日志(工作表)153中。然后过程返回到步骤S31。

下面更详细地阐述事件模式提取过程。

参照图27的流程图，事件模式提取过程包括以下步骤：

(步骤S41)模式匹配引擎110请求信息提取部130提取事件模式。然后信息提取部130从当日事件组日志153中读取事件组。在该操作中读出的数据项顺序如下：客户ID、设备ID以及错误编号/消息。如果读取操作成功，则信息提取部130接着执行随后的步骤。如果读取失败(即，没有事件组供读取)，那么过程返回到图24的主例程。

(步骤S42)信息提取部130从杂项配置信息数据库123读取配置信息。具体来说，模式匹配引擎110对杂项配置信息数据库123进行检索，以检索出与在步骤S41处获得的记录中的客户ID和设备ID相关的简称。

(步骤S43)信息提取部130提取并添加事件模式。具体来说，信息提取部130对事件模式数据库124进行检索，以检索出与在步骤S42处检索出的每个简称相关的事件模式。信息提取部130接着把检索出的记录添加到临时事件模式数据库125。然后过程返回到图24的主例程。

图28示出临时事件模式数据库的示例数据结构。临时事件模式数据库125具有在其它数据库中的以下数据域：“事件模式ID”、“事件序号”、“模式内的消息的数目”、“对象类型”以及“对象简称”。

事件模式ID域示出事件模式的标识码。事件序号域给出赋给该事件模式的序号。错误编号/消息域给出表示问题内容的标识符。对象类型域示出目标对象所属的类别。对象简称域示出目标对象的缩写名字。

下面更详细地阐述组合匹配过程。

参照图29的流程图，组合匹配过程包括以下步骤：

(步骤S51)模式匹配引擎110对当日事件组日志153中的每个事件组的消息进行计数。

(步骤S52)模式匹配引擎110从当日事件组日志153中读取未完成的事件组。如果所有的事件组都已完成，那么返回一表示条目结束的消息。

(步骤S53)模式匹配引擎110确定是否已读取事件组。若为是，则过程前进到步骤S54。如果已到达条目尾部，那么过程进行到步骤S60。

(步骤S54)模式匹配引擎110从临时事件模式数据库125检索出事件模式的事件信息。如果已完成所有事件模式，那么接着返回表示条目结束的消息。

(步骤S55)模式匹配引擎110确定是否已读取事件模式的事件信息。若为是，则过程前进到步骤S56。如果已到达条目尾部，那么过程进行到步骤S59。

(步骤S56)模式匹配引擎110基于单个事件信息对在步骤S52处读取的事件组与在步骤S54处读取的事件组进行比较，以弄清该事件组是否具有与所述事件模式中的一事件信息相同的任何事件信息。如果在该事件组中找到这种匹配事件信息，那么模式匹配引擎110接着确定在用于当日事件日志151的工作存储器中是否找到了在步骤S54处读取的事件模式。如果在所述当日事件日志中未找到该事件模式，那么过程前进到步骤S57。如果在当日事件日志中找到了该事件模式，那么过程前进到步骤S58。

(步骤S57)模式匹配引擎110创建与在步骤S54处检索出的事件模式对应的记录，并将其存储在当日事件日志151的工作存储区中。然后过程返回到步骤S54。

当日事件日志151的该新记录具有从在步骤S54处读取的事件模式复制的“事件模式ID”和“事件序号”域。它还具有“命中数”域，该域被初始化为1。它还具有又一域“模式中的消息的数目”，该域被赋以构成所检索出的事件模式的事件信息的数目。

(步骤S58)此时存在与在步骤S54处检索出的事件模式对应的现有当日事件日志记录，模式匹配引擎110使其命中数域递增1，由此更新日事件日志151的该记录。然后过程返回到步骤S54。

(步骤S59)模式匹配引擎110在使用模式匹配结果执行更新之后，使过程转到步骤S52。更具体来说，模式匹配引擎110通过从在步骤S52处读取的事件组中复制以下域值：事件组ID、事件序号、事件ID、客户ID、设备ID、发生时间、源类别以及错误编号/消息，来把若干项输入到当日事件组日志153的工作表中。但是，对于匹配结果域，模式匹配引擎110创建并输入一标志，该标志表示比较过程是否已找到具有相同事件信息的事件模式。

(步骤S60)模式匹配引擎110为当日事件日志151的工作表中的每个记录指配一权重。具体来说，当事件组中的消息数大于命中数时，给权重赋以事件组中的消息数减去命中数所得的数；当事件组中的消息数小于命中数时，给权重赋以命中数减去事件组中的消息数所得的数；当事件组中的消息数等于命中数时，权重就等于命中数。

以下描述输出信息的过程。

参照图30的流程图，输出信息的过程包括以下步骤：

(步骤S71)模式匹配引擎110对当日事件日志151的工作表中的事件日志进行排序。该排序操作涉及两个排序主键：一个是权重，而另一个是相同事件信息的数目(即，在事件组和在每个事件日志中都找到的事件信息的数目)。在本实施例中，按权重的排序具有更高优先级。即，模式匹配引擎110首先根据权重对事件日志进行排序，而如果存在具有相同权重的两个或更多个记录，那么接着按相同事件信息的数目对它们局部地进行排序。

(步骤S72)模式匹配引擎110从经排序的数组的起始，一次一条地读取当日事件日志151。如果没有事件日志供读取，那么生成一消息，以表示已读取并处理了所有记录。

(步骤S73)模式匹配引擎110确定是否已读取并处理了所有记录。然后过程返回到图24的主例程。如果读取到一事件日志记录，那么过程前进到步骤S74。

(步骤S74)模式匹配引擎110读取与所述事件日志对应的对策信息。

(步骤S75)模式匹配引擎110编辑该事件日志。具体来说，模式匹配引擎110首先按如下方式计算匹配率：(命中数)/(事件日志中的事件信息数)×100。随后，模式匹配引擎110通过把事件模式ID用作检索关键字来从当日事件日志151检索出一记录。

(步骤S76)模式匹配引擎110向结果文件155输出该匹配率和结果。

下面更详细地阐述以往事件检查过程。

参照图31的流程图，以往事件检查过程包括以下步骤：

(步骤S81)模式匹配引擎110读取当日事件日志151的事件ID域值。如果没有记录供读取，接着产生一消息，以指示已读取并处理了所有记录。

(步骤S82)模式匹配引擎110确定是否已读取并处理了所有记录。若为是，则过程接着返回到图24的主例程。如果读取到一记录，那么过程前进到步骤S83。

(步骤S83)模式匹配引擎110执行与以往事件信息的匹配。具体来说，模式匹配引擎110查询当月事件日志152，以找出与已有事件模式相同的记录。

(步骤S84)利用步骤S83的匹配结果，模式匹配引擎110确定是否存在相同记录。如果存在，那么过程前进到步骤S85。如果不存在，那么过程返回到图24的主例程。

(步骤S85)模式匹配引擎110查看所找到的以往事件日志记录，以提取其事件组ID。该ID示出哪个事件组引发了该事件日志记录。

(步骤S86)模式匹配引擎110确定是否已处理了在步骤S85处获得的所有记录。若为是，那么过程返回到图24的主例程。如果还剩有未处理的记录，那么过程前进到步骤S87。

(步骤S87)模式匹配引擎110对与在步骤S81处读取的事件ID对应的事件模式和与在步骤S85处获得的事件组ID对应的事件组进行比较，以确定在该事件模式中是否找到该事件组中的每条事件信息。

(步骤S88)模式匹配引擎110确定在步骤S87处是否找到了所述事件组中的所有事件信息。若为是，那么过程前进到步骤S89。否则，过程返回到步骤S85。

(步骤S89)模式匹配引擎110输出表示何时产生在步骤S85处获得的事件组ID的时标。接着过程返回到步骤S85。

以下更详细地阐述后处理。

参照图32的流程图，后处理顺序包括以下步骤：

(步骤S91)模式匹配引擎110从当日事件日志151读取记录。

(步骤S92)模式匹配引擎110确定是否已读取并处理了所有记录。若为是，那么过程进行到步骤S94。若为否，那么过程前进到步骤S93。

(步骤S93)模式匹配引擎110把从当日事件日志151的工作表中读取的记录存储到HDD等中，并将其添加到当月事件日志152。而且，模式匹配引擎110把当日事件组日志153(其为当日事件日志151的源)的工作表存储到HDD等中，并将其添加到当月事件组日志154。然后过程返回到步骤S91。

(步骤S94)模式匹配引擎110确定是否已正确存储事件日志记录。若为是，那么过程前进到步骤S95。否则，过程前进到步骤S96。

(步骤S95)模式匹配引擎110提交记录存储会话并退出本过程。

(步骤S96)模式匹配引擎110执行回滚(rollback)。术语“回滚”是指使数据库回到先前建立的检查点处以从故障中恢复的操作。回滚之后，模式匹配引擎110退出本过程。

图33示出信息的流动。在图33的示例中，给定事件组121包括四个ID为“a”、“b”、“c”以及“d”的事件信息。

临时事件模式数据库125存储有多个事件模式。通过这些事件模式的事件模式ID“A”、“B”、“C”以及“D”等来参照它们。事件模式“A”包括事件信息“a”、“b”、“c”以及其它事件信息。事件模式“B”包括事件信息“a”、“c”以及其它事件信息。事件模式“C”包括事件信息“a”、“e”以及其它事件信息。事件模式“D”包括事件信息“b”、“c”以及其它事件信息。

针对上述事件组121与存储在临时事件模式数据库125中的事件模式进行模式匹配过程，由此产生图33中所示的组合匹配结果91。为简化起见，图33的示例仅示出针对两条事件信息的组合的匹配结果。

参照该组合匹配结果91，事件模式“A”被提取为针对事件信息“a”和“b”的组合的匹配事件模式。事件模式“A”和“B”被提取为针对事件信息“a”和“c”的组合的匹配事件模式。事件模式“C”被提取为针对事件信息“a”和“d”的组合的匹配事件模式。事件模式“D”被提取为针对事件信息“b”和“c”的组合的匹配事件模式。然而，对于事件信息“b”和“d”的组合以及事件信息“c”和“d”的组合，都没有提取到事件模式。

基于上述组合匹配结果91，生成当日事件日志151。与事件信息“a”相关联的有事件模式ID“A”、“A”、“B”以及“C”。类似地，与事件信息“b”相关联的有事件模式ID“A”和“D”。与事件信息“c”相关联的有事件模式ID“A”、“B”以及“D”。与事件信息“d”相关联的只有事件模式ID“C”。

当日事件日志151用于生成结果文件155。在图33的示例中的结果文件155给出事件模式列表，这些事件模式与它们各自的命中数按成为故障原因的可能性降序排列。在图33中，事件模式“A”的命中数为“4”。事件模式“B”的命中数为“2”，而剩下的事件模式“C”和“D”的命中数也为“2”。虽然图33中所示的示例结果文件155给出了命中数，然而也可以将其配置成示出匹配率。

由上可见，操作管理服务器100通过把相互关联的事件信息组合成事件组121并将它们与事件模式进行比较，来提取事件的一个或更多个高度可能的原因。操作管理服务器100的模式匹配引擎110为管理员提供对有关故障原因的提示及其对策的结果文件。

在以上阐述中，操作管理服务器100直接从系统中收集事件消息，并把事件信息自动排序成分析用的组。然而，操作管理服务器100也可以对一组指定的事件信息进行分析。在此情况下，可以例如通过事件组检索屏面选择希望的记录，由此来指定事件组。

图34示出事件组检索屏面的示例。该事件组检索屏面510允许用户通过从一数据库中检索出以往日志信息，来创建用于匹配的希望事件组，该数据库含有在预定时段内收集的以往事件组日志信息。

所示的事件组检索屏面510具有消息检索条件输入部分511和事件检索条件输入部分512。

消息检索条件输入部分511接受客户名和时段的输入，作为检索条件。指定客户名意味着指定产生含有事件信息的消息的特定系统。操作管理服务器100检索出与被输入到消息检索条件输入部分511中的检索条件匹配的事件组。

事件检索条件输入部分512包括用于指定原因和对策的输入框。每个输入框具有一复选框。当选中对应的复选框时，就将输入文本用作检索关键字。操作管理服务器100基于被输入到事件检索条件输入部分512中的检索条件，对事件组日志记录进行检索。

事件组检索屏面510使得能够检索出事件组并将其呈现在显示屏面上。为了进行模式匹配，允许用户从属于所检索出的事件组中的事件信息中选择特定事件信息。对所选事件信息进行分析，以找出故障的原因及其对策。

图35示出事件选择屏面的示例。事件选择屏面520示出属于通过检索等提取的事件组日志的事件信息的列表。用户选择该事件信息列表的一部分521。

可以把所选事件信息当作单个事件组来分析问题的原因。

通过一系列的过程对按此方式指定的事件组进行分析，把该分析的结果输出为结果文件155并显示在分析结果屏面上。

图36示出分析结果屏面的示例。该分析结果屏面530具有选定消息部分531、检索条件部分532以及事件消息部分533。选定消息部分531示出选定事件组的事件信息的细节。检索条件部分532给出由相关事件模式所指示的原因和对策的列表。事件消息部分533示出在事件模式中定义的事件信息的内容。

其他应用

在上述多个实施例中，基于服务器可能产生的错误事件来考查故障。作为另一种方法，操作员命令也可以成为用于分析故障的信息源。换句话说，另选途径是根据可能引起故障的输入来定位问题，而前述实施例试图根据由故障源产生的结果来定位故障。实际上，某些用户体验过依赖于他们的计算机环境的两个程序之间的冲突；即，某些激活应用进程会妨碍另一进程，而该另一进程通常可以独立地执行。在这种情况下，向这些进程发出的命令的历史记录使操作管理服务器能够自动隔离问题。

例如，当处于数据备份过程时，数据库禁止来自外部的访问。在此情况下，常规系统产生数据库访问错误。然而，用户无法知晓他们不能访问数据库的原因。

为了通知用户他们在尝试进行他们的系统不允许的操作，可以把系统设计成收集命令集的模式定义组，以用于以后的模式匹配。每个组包含不能同时执行的多个命令，并且当用户输入这种命令集时，系统将对收集到的命令集模式进行检索并向用户提供有关该问题的信息，包括其原因和对策。例如，系统可能建议他/她停止引起故障的应用。

当多个应用同时运行时，一个应用可能在试图进行另一应用不允许的事情时遇到错误。一般地，在这种情况下，不允许用户修改违反限制的应用程序。然而，如果系统可以检测到请求同时执行多个应用并将导致错误的操作员输入，并且如果系统可以提供另选方式以供他/她得到他/她想要的而不产生错误，那么用户就能够避免该故障。

上述处理机制可以在与图11中已描述的平台类似的平台上实现。但是，必须把服务器或其它终端站配置成向操作管理服务器100发送消息，以示出用户输入了什么指令。操作管理服务器100把这些消息存储到历史记录表中。此外，操作管理服务器100具有操作模式数据库，该操作模式数据库用于存储可能导致问题的各种操作模式。

图37示出历史记录表的示例数据结构。该历史记录表610具有以下数据域：“发生时间”、“命令名”以及“服务器名”。发生时间域示出操作管理服务器100何时接收到传送操作员输入记录的消息。命令名域示出实际发出的命令。服务器名域示出发送消息的服务器的名字。输入到历史记录表610中的是，在预定时间段(例如，从下午1:30起的十分钟)内的操作员输入的记录。

图38示出操作模式数据库的示例数据结构。该操作模式数据库620具有以下数据域：“操作模式码”、“操作模式”、“症状”、“原因”以及“对策”。

操作模式码域给出赋给每个操作模式的标识码。操作模式域示出可能导致故障的命令的集合。症状域示出故障将如何表现出来，而原因域示出该故障的原因。对策域告知采取什么动作来规避故障。

例如，参见图37的历史记录表610。记录表示：用户使用“vi”命令调用编辑器程序，编辑“hosts”文件，然后使用“mail”命令启动邮递程序。假定该操作员命令序列引起了错误。然后，用户从操作管理服务器100接收到有关该错误的分析报告。

上述操作员命令序列与操作模式数据库620中存储的代码为“s00000002”的操作模式相匹配。相应地，操作管理服务器100检索出该操作模式记录，并向用户的终端站发送消息，从而显示“症状”、“原因”以及“对策”域中的信息。用户接着检查实际发生了些什么情况，并且如果实际发生的情况与所述消息给出的情况完全相同，那么他/她认识到当前情况就是操作模式代码“s00000002”的情况。所提示的原因和对策将帮助用户解决他/她的问题。

将上述处理功实现在计算机系统上。对描述操作管理服务器的功能的指令进行编码并以计算机程序的形式来提供。该计算机系统执行这些程序，以提供希望的处理功能。可以把这些程序存储在计算机可读存储介质中。这种存储介质包括磁存储装置、光盘、磁光存储介质以及固态存储装置。磁存储装置包括硬盘驱动器(HDD)、软盘(FD)以及磁带。光盘包括数字多媒体盘(DVD)、DVD随机存取存储器(DVD-RAM)、只读光盘存储器(CD-ROM)、可写CD(CD-R)以及可重写CD(CD-RW)。磁光存储介质包括磁光盘(MO)。

诸如DVD和CD-ROM的便携式存储介质适合于程序产品的发布。也可以使用基于网络的软件程序发布，其中，在服务器计算机中提供主程序文件，并可以经由网络将其下载到其它计算机。

用户计算机在其本机存储单元中存储必要的程序，这些程序已被预先从便携式存储介质进行了安装或从服务器计算机进行了下载。该计算机执行从本机存储单元读取的程序，从而执行已编程的功能。作为程序执行的另选方式，计算机可以在直接从便携式存储介质中读出程序代码的情况下来执行程序。另一另选方法是，用户计算机在需要时动态地从服务器计算机下载程序，并在传输过程中执行它们。

上述阐述总结如下。根据本发明，把操作管理服务器设计成，从被监控的其它服务器中的目标对象收集事件记录，并把这些事件记录排序成多个组。将所得的事件组与模式定义组进行比较，以找出匹配模式定义组，并提取与该组对应的对策记录。本发明所提出的特征使得可以容易地识别出引起问题的目标对象。

上述阐述被视为仅例示了本发明的原理。此外，由于本领域的技术人员易知各种修改和变化，所以不应将本发明限于所示出和描述的具体结构和应用程序，因此，所有合适的变型例和等同物都可被视为落入所附权利要求及其等同物所限定的本发明的范围内。

Claims

1、一种用于管理服务器的操作管理方法，包括以下步骤：

从多个监控目标对象收集事件信息，该多个监控目标对象是在所述服务器上执行的多个功能；

通过对收集到的多条所述事件信息进行分组来生成事件组；

按所述事件信息的发生模式对多个模式定义组与所述事件组进行比较，所述模式定义组定义在故障发生时从多个所述监控目标对象输出的事件信息的发生模式；以及

提取故障对策信息，该故障对策信息已被预先与按所述事件信息的发生模式类似于所述事件组的所述模式定义组关联起来，该故障对策信息表示成为故障原因的所述监控目标对象。

2、如权利要求1所述的操作管理方法，其特征在于，所述事件信息是从多个服务器收集的。

3、如权利要求1所述的操作管理方法，其特征在于，在收集所述事件信息时，把每个所述监控目标对象的数据格式转换为统一的数据格式。

4、如权利要求1所述的操作管理方法，其特征在于，在生成所述事件组时，通过参照定义多个所述监控目标对象之间的关联性的数据库，对从存在关联性的所述监控目标对象输出的所述事件信息进行分组。

5、如权利要求1所述的操作管理方法，其特征在于，在生成所述事件组时，对在预定时段内收集的所述事件信息进行分组。

6、如权利要求1所述的操作管理方法，其特征在于，在对所述事件信息的发生模式进行比较时，找到共同的所述事件信息。

7、如权利要求1所述的操作管理方法，其特征在于，在提取多个所述故障对策信息时，根据所述模式定义组相对于所述事件组在所述事件信息的发生模式方面的共同度，对多个故障对策信息进行排序。

8、如权利要求7所述的操作管理方法，其特征在于，如果所述模式定义组与所述事件组具有共同的所述事件信息越多，则将所述模式定义组判断为具有越高的共同度。

9、如权利要求7所述的操作管理方法，其特征在于，在所述事件组或所述模式定义组包含的所述事件信息中，如果只属于其中一方的所述事件信息越少，则将所述模式定义组判断为具有越高的共同度。

10、如权利要求1所述的操作管理方法，其特征在于，所述故障对策信息包括故障发生原因和解决故障的对策信息。

11、一种用于管理服务器的操作管理方法，其特征在于包括以下步骤：

收集输入到所述服务器的命令；

通过对收集到的多个所述命令进行分组，来生成操作历史记录信息；

按所述命令的输入模式，对多个操作模式信息与所述操作历史记录信息进行比较，所述操作模式信息定义成为故障发生原因的命令输入模式；以及

提取故障对策信息，该故障对策信息已被预先与按所述命令的输入模式类似于所述操作历史记录信息的所述操作模式信息关联起来，该故障对策信息表示成为故障原因的所述监控目标对象。

12、一种用于管理服务器的操作管理设备，其特征在于包括：

收集装置，用于收集多个监控目标对象处发生的事件信息，该多个监控目标对象是在所述服务器上执行的多个功能；

生成装置，用于通过对收集到的多条所述事件信息进行分组来生成事件组；

比较装置，用于按所述事件信息的发生模式对多个模式定义组与所述事件组进行比较，所述模式定义组定义在故障发生时从多个所述监控目标对象输出的事件信息的发生模式；以及

提取装置，用于提取故障对策信息，该故障对策信息已被预先与按所述事件信息的发生模式类似于所述事件组的所述模式定义组关联起来，该故障对策信息表示成为故障原因的所述监控目标对象。

13、一种用于管理服务器的操作管理装置，其特征在于包括：

收集装置，用于收集输入到所述服务器的命令；

生成装置，用于通过对收集到的多个所述命令进行分组，来生成操作历史记录信息；

比较装置，按所述命令的输入模式，对多个操作模式信息与所述操作历史记录信息进行比较，所述操作模式信息定义成为故障发生原因的命令输入模式；以及

提取装置，提取故障对策信息，该故障对策信息已被预先与按所述命令的输入模式类似于所述操作历史记录信息的所述操作模式信息关联起来，该故障对策信息表示成为故障原因的所述监控目标对象。

14、一种用于管理服务器的操作管理程序，其特征在于，该操作管理程序使计算机执行以下步骤：

通过对收集到的多条所述事件信息进行分组来生成事件组；

15、一种用于管理服务器的操作管理程序，其特征在于，该操作管理程序使计算机执行以下步骤：

收集输入到所述服务器的命令；

16、一种计算机可读的存储介质，记录有用于管理服务器的操作管理程序，其特征在于，该操作管理程序使计算机执行以下步骤：

通过对收集到的多条所述事件信息进行分组来生成事件组；

17、一种计算机可读的存储介质，记录有用于管理服务器的操作管理程序，该操作管理程序使计算机执行以下步骤：

收集输入到所述服务器的命令；