CN1722678A

CN1722678A - 管理系统和管理方法

Info

Publication number: CN1722678A
Application number: CN200510084074.9A
Authority: CN
Inventors: 铃木敬
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2004-07-12
Filing date: 2005-07-12
Publication date: 2006-01-18
Anticipated expiration: 2025-07-12
Also published as: US20060010337A1; EP1622306A3; JP2006031109A; EP1622306A2; CN100377532C

Abstract

管理系统具有：检测已发生的事件的事件监视部；提取与上述事件有关的依存关系的依存关系提取部；保存上述事件和上述依存关系的保存部；根据更新规则对由上述保存部所保存的上述事件和上述依存关系进行更新的更新部；参照上述保存部，根据上述事件和上述依存关系确定已发生的故障原因的原因确定部。

Description

管理系统和管理方法

技术领域

本发明涉及管理系统和装置的管理系统和管理方法，特别涉及适合确定在系统和装置中所发生的故障的原因的管理系统和管理方法。

背景技术

近几年，随着移动电话终端等装置和系统的高功能化，软件和硬件的构成单元不断增加，装置和系统日趋复杂化。一般，在高度化和复杂化的装置和系统中，根绝缺陷和脆弱性是困难的，故障发生不可避免。而且，随着构成单元的增加，单元间的相互依存的数量以平方形式增加，所以在故障发生时愈发难以确定其根本原因。

另一方面，例如，移动电话终端和网络等，作为进行紧急通报等通信的基础设施，要求具有较高的可靠性。因此，即使由于利用脆弱性的攻击和软件的缺陷，在携带电话终端和网络等中发生故障的情况，也要求迅速除去该原因，复原其功能。因而，要求高效确定故障原因的功能。

目前，作为容易确定故障原因的装置，具有网络管理装置(特开2001-125854号公报，以下称「文献1」)，该装置在某个构成单元的故障会影响到其他构成单元，故障传播的网络中，在某个构成单元中发生了故障时，通过对在依存于该构成单元的构成单元中发生的故障设定抑制标志，能够抑制由同一故障引起的冗长警告的发生，容易跟踪根本原因。

此外，提出了一种方案(特开平11-308221号公报，以下称「文献2」)，该方案根据故障事件间的传播模型和网络结构信息，推论输入的多个故障事件的原因。在该技术中提出了一种原因推断方法，该方法以认为各个故障原因是在传播模型上引起的故障事件的个数上限值予先已知为前提，对每个故障原因赋予指针，存储器使用量少。而且，还公开了一种反馈单元，该单元根据故障事件的历史计算故障事件间的相互相关值，检测存在记述遗漏的故障传播规则，更新传播模型。

而且，还提出了一种根据在计算机的操作系统(基本软件)上发生的事件的记录，构筑操作系统所管理的对象间的依存模型的方法(S.King，P.Chen，“Backtracking Intrusions”，ACM SOSP 2003，以下称「文献3」)。在该技术中，通过在故障事件发生后分析事件记录，生成并显示以故障事件为基点的依存模型，支援原因分析。

但是，文献1公开的网络管理装置从多个构成单元引起的故障事件中确定成为根本原因的故障事件，能成为原因的故障事件以事先被选择为前提。即，该网络管理装置能跟踪的原因限于事先能识别的故障事件。因此，在成为根本原因的事件事先不能识别时，就不能跟踪该事件。然而，成为故障根本原因的事件各式各样，难以在故障事件发生时判定是否成为原因。

此外，文献2公开的系统所必须的前提为故障事件的个数上限值是预先已知的。该前提仅在事先构筑了妥当的传播模型时成立。因此，即使是像简单网络那样系统结构管理者已知，在能预测故障原因和由其引起的故障事件的情况下可以适用，但在复杂网络和用户能够自由扩充软件及硬件的构成单元的装置中不能适用。此外，使用该技术虽然能检测存在记述遗漏的故障传播规则，更新传播模型，但到底还是补足记述遗漏的程度，无法由故障传播规则完全不存在的状态构筑高精度的传播模型。

而且，在文献3中公开的方法根据操作系统所记录的事件记录构筑对象间的依存模型，所以不需要与故障原因有关的事先知识。但是，由于必须存储动作中全部的事件记录，所需要的存储容量随着执行增加。

即，在所有的现有技术中，存在前提条件和存储容量等制约，在不满足前提条件和存储容量不充分的情况下，无法适当地确定故障原因。

发明内容

本发明的目的在于提供一种在各式各样装置和系统中能确定故障原因的管理系统以及管理方法。

涉及本发明一实施例的管理系统具有：检测发生的事件的事件监视部；提取与事件有关的依存关系的依存关系提取部；保存事件和依存关系的保存部；根据更新规则更新由保存部保存的事件和依存关系的更新部；参照保存部，根据事件和依存关系确定发生的故障的原因的原因确定部。

根据这样的管理系统，在检测装置和系统中发生的事件，提取与事件有关的依存关系，根据事件和依存关系可以确定故障原因。因此，管理系统无需必须事先已知事件和依存关系、与故障原因有关的信息的前提条件。而且，管理系统能根据更新规则更新保存部保存的事件和依存关系。所以，管理系统不仅无需预先保存信息，而且还能够适当更新已检测出的事件和已提取出的依存关系，仅保存必要的信息。因此，管理系统能削减所必要的存储容量和信息的处理量。根据以上内容，管理系统由于不受到来自前提条件和存储容量等方面的制约，所以在各式各样的装置和系统中能够确定故障原因。特别地，管理系统具有即使是在存储容量和运算能力有限的装置和系统中也能够确定故障原因的优点。

涉及本发明一实施例的管理方法检测已发生的事件，提取与事件有关的依存关系，根据更新规则更新在保存部中已保存的事件和依存关系，参照保存部，根据事件和依存关系确定已发生的故障的原因。

附图说明

图1是表示本发明第1实施例的管理系统的方框图。

图2是表示本发明第1实施例的数据库的图。

图3是表示本发明第1实施例的更新规则存储部的图。

图4是表示本发明第1实施例的故障原因探测程序的概念图。

图5是表示本发明第1实施例的事件和依存关系的管理方法的流程图。

图6是表示本发明第1实施例的原因确定部的处理程序的流程图。

图7是表示本发明第1实施例的故障原因的确定程序的流程图。

图8表示本发明第2实施例的管理系统的方框图。

图9是表示本发明第2实施例的数据库的图。

图10表示本发明第2实施例的故障原因探测程序的概念图。

图11表示本发明第2实施例的事件和依存关系的管理方法的流程图。

图12是表示本发明第2实施例的原因特定部的处理程序的流程图。

图13是表示本发明第2实施例的故障原因的特定程序的流程图。

图14是表示本发明第3实施例的管理系统的结构的方框图。

具体实施方式

(第1实施例)

如图1所示，管理系统100具备事件监视部1、依存关系提取部2、存储部3、数据库4、原因确定部5、故障检测部6、更新部7a、契机检测部7b和更新规则存储部8。

事件监视部1检测在作为管理系统100的管理对象的系统和装置中发生的事件。例如，事件监视部1将在操作系统(OS)上执行的处理所生成的系统引入和系统设定文件的写入等作为事件进行监视并进行检测。

而且，事件监视部1从更新规则存储部8取得规则ID。更新规则存储部8存储与管理系统100保存的信息更新有关的更新规则。对更新规则给予规则ID作为用于识别更新规则的识别符。事件监视部1根据检测出的事件选择适用于该事件的更新规则。例如，事件监视部1能够根据事件的重要度等选择更新规则。而且，事件监视部1取得对选择出的更新规则所给予的规则ID。事件监视部1将检测出的事件、该事件的发生时间、规则ID输入到存储部3。而且，事件监视部1将检测出的事件输入到依存关系提取部2。例如，事件监视部1可以作为操作系统(OS)内的模块被安装。

依存关系提取部2提取与事件有关的依存关系。依存关系提取部2取得由事件监视部1检测出的事件。依存关系提取部2根据作为管理对象的系统和装置中包含的构成单元、系统和装置进行的处理、检测出的事件提取依存关系。在依存关系中有事件间的依存关系、事件的构成单元间的依存关系、事件的处理间的依存关系、事件和构成单元的依存关系、事件和处理间的依存关系等。在构成单元中具有存储器和文件等。构成单元，例如，在操作系统(OS)上执行的处理等利用。

例如，依存关系提取部2在从事件监视部1取得系统设定文件写入事件时，将系统设定文件的文件名和向系统设定文件的路径作为依存于系统设定文件写入事件的「依存源」的构成单元进行提取，将发生系统设定文件写入事件的处理名称作为系统设定文件写入事件依存的依存对像的处理进行提取。依存关系提取部2将提取的依存关系输入到存储部3。

此外，依存关系提取部2可以根据提取出的依存关系选择适用于该依存关系的更新规则。此时，例如，依存关系提取部2能根据依存关系选的重要度等选择更新规则。依存关系提取部2取得给予给更新规则的规则ID，该更新规则是从更新规则存储部8选择出的。而且，依存关系提取部2将规则ID与提取出的依存关系一同输入到存储部3。

存储部3取得由事件监视部1检测出的事件、事件发生时间、规则ID，取得由依存关系提取部2提取的依存关系。存储部3将已取得的事件、事件发生时间、规则ID和依存关系对应地存储在数据库4。

数据库4是保存事件和依存关系的保存部。数据库4不仅保存事件和依存关系，而且还能够与事件或依存关系相对应地保存事件或依存关系的属性信息。在属性信息中有与事件发生时间和更新规则有关的信息等。作为与更新规则有关的信息，存在对更新规则进行识别的识别符(规则ID)等，上述更新规则是适用于事件和依存关系的更新的更新规则。在事件和依存关系的更新中适用更新规则时参照与更新规则有关的信息。

如图2所示，数据库4具有事件ID、事件、依存对象、依存源、事件发生时间和更新规则的区域。依存关系通过依存对象和依存源来表示。在更新规则的区域中存储规则ID。在没有适用的规则ID时，在更新规则的区域中设定NULL值。存储部3对事件给予作为事件的识别符的事件ID，与事件ID对应地将事件、依存关系、事件发生时间、规则ID存储到数据库4中。

更新部7a根据更新规则更新数据库4保存的事件和依存关系等。更新部7a从更新规则存储部8取得更新规则。更新规则可以决定对重要度低的信息和临时信息进行删除、使多个事件与其依存关系衰减等的规则。具体地说，如图3所示，更新规则存储部8具有存储更新规则的更新规则表81、存储更新契机规则的更新契机规则表82。更新规则表81将规则ID、适用条件、更新内容相对应地存储。这样，更新规则包含更新内容和适用该更新内容的适用条件，对各更新规则给予规则ID。

更新契机规则表82将更新契机和根据该更新契机适用的更新规则的规则ID相对应地保存。这样，更新契机规则可以使用记述了更新契机和根据该更新契机适用的更新规则的识别符的规则。更新契机规则表82在与一个更新契机相对应保存多个规则ID的情况下，按更新规则的适用顺序保存规则ID。更新契机例如可以根据作为管理对象的系统和装置的各种契机的负荷和存储器使用量等进行设定。因此，管理系统100容易适用于计算机能力和存储容量等资源有限的装置和系统。

契机检测部7b检测适用这些更新规则的更新契机，将该检测出的更新契机通知给更新部7a。更新部7a接收由契机检测部7b检测出的更新契机的通知。更新部7a根据更新规则更新数据库4，该更新规则是由契机检测部7b通知的更新契机所适用的更新规则。具体地说，更新部7a根据已通知的更新契机检索更新契机规则表82，取得由检测出的更新契机适用的更新规则的规则ID。更新部7a根据已取得的规则ID，从更新规则表81取得适用条件和更新内容，作为更新规则。而且，更新部7a根据已取得的适用条件和更新内容更新数据库4。

而且，更新部7a参照数据库4，根据更新规则对事件和依存关系进行更新，该事件和依存关系是由检测出的更新契机适用的更新规则的规则ID所对应的事件和依存关系。这样，更新部7a根据与作为事件或依存关系的属性信息的更新规则有关的信息，更新数据库4。具体地说，更新部7a参照数据库4，首先，判断是否有与事件和依存关系对应的规则ID，适用于该事件和依存关系的更新规则是否存在。更新部7a在规则ID对应的情况下，根据由该规则ID确定的更新规则更新数据库4。更新部7a在不存在适用的更新规则的情况下，能判断不更新数据库4。此外，在图2所示的数据库4中，对1个事件对应1个规则ID，但不限定对1个事件适用的更新规则的数量。因此，

数据库4也可以对1个事件相对应地保存多个规则ID。

例如，契机检测部7b检测新事件向数据库4的存储，通知给更新部7a。接收到通知的更新部7a参照更新契机规则表82，判断执行与更新契机「新事件追加」对应的规则ID「0x02」的更新规则。而且，更新部7a根据更新规则表81存储的适用条件和更新内容，对在数据库4中规则ID「0x02」作为属性信息所对应的事件和依存关系进行更新。此时，在数据库4中被给予了规则ID「0x02」的事件成为更新对象事件，新事件成为比较事件。

更新部7a在满足适用条件「更新对象事件的事件发生时间比比较事件的事件发生时间更早，而且更新对象事件的依存源和比较事件的依存对象相等」的情况下，进行更新内容「将与更新对象事件有关的信息置换成与比较事件有关的信息」。因此，例如，更新部7a在关于经由了共有存储器的处理间通信在数据库4中进行存储的情况下，能将向共有存储器的写入事件置换成来自共有存储器的读出事件。因此，能够削除冗长的依存关系。

故障检测部6检测在作为管理对象的装置和系统中发生的故障。例如，故障检测部6通过取得由核心进行的处理异常结束通知或由用户进行的通知等检测故障。故障检测部6向原因确定部5通知故障检测。故障检测部6通知发生了故障的构成单元和处理名称(以下称为「故障发生单元」、故障发生时间。例如，故障检测部6向原因确定部5发送故障检测信号。

原因确定部5，参照数据库4，根据事件和依存关系确定已发生的故障原因。原因确定部5当从故障检测部6接收故障检测的通知时，开始原因确定处理。原因确定部5通过参照数据库4分析事件和依存关系等来确定原因。在图4中表示原因确定部5的故障原因探测程序的概念图。在图4中多个圆表示事件。「N」～「N-12」为事件名称。而且，从依存源的事件向依存对象的事件表示箭头。从图4的上方向下方表示时间的经过。

原因确定部5追溯由故障检测部6通知的故障发生单元，例如，以故障发生处理为起点追溯依存关系。原因确定部5从通知的故障发生时间开始，沿与时间的经过相反的方向以故障发生处理为起点追溯依存关系。因此，原因确定部5探测故障发生处理直接或间接依存的事件，确定为故障原因的候补。在图4的情况下，原因确定部5确定事件「N」、「N-2」、「N-3」、「N-5」、「N-6」、「N-7」、「N-10」、「N-12」为故障原因的候补。原因确定部5向管理对象的装置和系统的控制部和显示部等输出已确定的故障原因的候补。

在故障原因中例如具有系统设定文件的修正错误、包含缺陷的的操作和装置驱动器的安装、因病毒等有恶意的程序引起的系统改变等。

这样的管理系统100可以设置为作为管理对象的装置和系统的一部。或者，管理系统100也可以设置为与作为管理对象的装置和系统相连接。这样的管理系统可以通过由计算机执行程序来实现，改程序是指作为检测已发生的事件的事件监视部、提取与事件有关的依存关系的依存关系提取部、保存事件和依存关系的保存部、根据更新规则对在保存部中保存的事件和依存关系等进行更新的更新部、和参照保存部根据事件和依存关系确定已发生的故障原因的原因确定部，来发挥功能的程序。

然后，使用图5～7对图1所示的管理系统100进行的管理方法的程序进行说明。图5表示事件和依存关系的管理方法。管理系统100检测在管理对象的装置和系统中已发生的事件(S101)。管理系统100选择与检测出的事件有关的更新规则(规则ID)(S102)。管理系统100提取与检测出的事件有关的依存关系(S103)。管理系统100将事件、依存关系、规则ID等存储在数据库4中(S104)。管理系统100检测更新契机(S105)。管理系统100从更新规则存储部8中取得由检测出的更新契机适用的更新规则(S106)。管理系统100根据已取得的更新规则更新数据库4(S107)。

图6表示原因确定部5的处理程序。原因确定部5从故障检测部6取得故障发生单元和故障发生时间。原因确定部5在键(key)中代入故障发生单元，在时间(time)中代入故障发生时间(S201)。原因确定部5以故障发生单元为键(key)，也使用故障发生时间(time)来确定故障原因的侯补(S202)。原因确定部5输出已确定的故障原因的侯补(S203)。

图7表示故障原因的确定程序，即图6所示的步骤(S202)更为详细的程序。原因确定部5根据已取得的故障发生时间(time)检索数据库4，确定故障发生时间之前的事件。而且，原因确定部5将之前的事件的事件发生时间代入到时间(time)(S301)。原因确定部5判定之前的事件的依存源是否与已取得故障发生单元(key)一致(S302)。一致时，原因确定部5判断为故障发生单元依存于之前的事件，确定之前的事件作为故障原因的侯补并进行存储(S303)。

而且，原因确定部5为了探测作为故障原因的侯补确定的事件(以下称为「确定完成事件」)依存的其他事件，将确定完成事件的依存对像代入到键(key)，再次调用按照图4所示的故障原因探测程序的处理(S304)。而且，原因确定部5根据确定完成事件的依存对像(key)和故障发生时间(time)检索数据库4(S305)。

原因确定部5接着步骤(S305)，或在步骤(S302)，在之前的事件依存源与故障发生单元(key)不一致的情况下，尝试对确定完成事件之前的事件进行确定。而且，原因确定部5将确定完成事件之前的事件的事件发生时间代入到时间(time)(S306)。原因确定部5在步骤(S306)判断是否能够确定之前的事件(S307)。即，原因确定部5判断之前的事件是否存在(NULL)。

原因确定部5在之前的事件存在的情况下，确定该事件作为故障原因的侯补。而且，只要之前的事件存在，返回步骤(S302)，反复执行步骤(S302)～(S307)。另一方面，原因确定部5在之前的事件不存在的情况下，结束处理。

根据这样的管理系统100和管理方法，检测在作为管理对象的装置和系统中已发生的事件，提取与事件有关的依存关系，根据事件和依存关能够确定故障原因。因此，管理系统100无需必须预先已知事件和依存关系、与故障有关的信息这个前提条件。而且，管理系统100能够根据更新规则更新数据库4保存的事件和依存关系。因而，管理系统100不仅不需要预先保存信息，而且能够对检测出的事件和提取出的依存关系进行适当更新，仅保存必要的信息。因此，管理系统100能够削减所需要的存储容量和信息的处理量。

根据以上内容，管理系统100由于不受到来自前提条件和存储容量方面的制约，所以可以在各式各样的装置和系统中确定故障原因。而且，由于能够削减信息的处理量，所以故障原因的确定变得容易，能够减少故障修复所需要的时间。

例如，管理系统100由于不需要保存并管理与全部事件有关的信息，所以可以防止在包含多个构成单元的复杂的装置和系统中保存的信息量的膨胀。此外，能够防止随着从故障原因的发生到实际故障的发生的时间间隔的增加，应保存的信息量和分析所需要的处理量增加，存储容量和运算能力有限的装置和系统的故障原因的确定变得困难。因而，管理系统100即使在存储容量和运算能力有限的移动电话终端那样的装置和系统中也能够确定故障原因。

而且，在管理系统100中，契机检测部7b检测适用更新规则的更新契机，将该检测出的更新契机通知给更新部7a。而且，更新部7a可以根据由契机检测部7b通知的更新契机适用的更新规则更新数据库4。因此，通过管理系统100能够明确地指定执行根据更新规则的更新的更新契机。

此外，作为事件或依存关系的属性信息，数据库4保存与更新规则有关的信息，更新部7a能够根据与更新规则有关的信息更新数据库4。因此，管理系统100可以对每个事件和依存关系控制更新，能够进行较弹性的控制。例如，管理系统100能够控制适用于每个事件和依存关系的更新规则，根据事件和依存关系的重要度等可以弹性地控制更新。

特别地，通过管理系统100能够作为属性信息来使用规则ID，更新部7a能够根据由规则ID确定的更新规则更新数据库4。因此，通过管理系统100能够明确地指定适用于各事件和依存关系的更新规则。

(第2实施例)

如图8所示，管理系统200具有事件监视部201、依存关系提取部2、存储部203、数据库204、原因确定部205、故障检测部6、更新部207a、契机检测部7b、更新规则存储部8和相似性决定规则存储部9。在图8中，对与图1所表示的管理系统100实际相同的结构附以相同的符号并省略说明。

事件监视部201对检测出的事件给予相似性。事件监视部201最好根据检测出的事件的种类或依存于检测出的事件的事件相似性中的至少1个来决定给予的相似性。具体地说，事件监视部201根据相似性决定规则决定给予的相似性。相似性决定规则由相似性决定规则存储部9存储。在相似性决定规则中，例如包含根据事件的种类和相似性的对应或根据依存于检测出的事件的事件相似性来决定相似性的决定规则。根据事件种类的相似性，例如可以根据对作为管理对象的装置和系统给予的影响的大小来设定。例如，对系统设定文件的变更事件等设定高的相似性。

数据库204与事件对应地保存相似性。如图9所示，数据库204具有事件ID、事件、依存对象、依存源、事件发生时间、相似性和更新规则的区域。存储部203对事件给予事件ID，与事件ID对应地存储事件、依存关系、事件发生时间、相似性、规则ID。更新部207a也更新相似性。

原因确定部205根据相似性确定故障原因。图10表示原因确定部205的故障原因探测程序的概念图。图10与图4相同地表现事件间的关系等。原因确定部205和图4的情况同样，以故障检测部6所通知的故障发生单元(故障发生处理等)为起点追溯依存关系，探测故障发生处理直接或间接依存的事件。

然后，原因确定部205将故障发生处理直接或间接依存的各事件的相似性与变量Mi(i表示事件名称)进行累积加法运算。而且，原因确定部205只确定变量Mi比预先规定的阀值大的事件作为故障原因的侯补。在图10中，原因确定部205确定具有超过阀值的变量「M_N-5」、「M_N-7」、「M_N-12」的事件「N-5」、「N-7」、「N-12」作为故障原因的侯补。

或者，原因确定部205也可以比较故障发生处理直接或间接依存的事件的相似性，选择相似性高，作为故障原因的可能性高的事件作为故障原因的侯补。例如，原因确定部205也可以根据相似性对事件附加序号，选择上位规定数的事件作为故障原因的侯补。事件监视部201、存储部203、原因确定部205、更新部207a除这些点以外，和图1表示的事件监视部1、存储部3、原因确定部5、更新部7a实际上是相同的。

然后，使用图11～13对图8所示的管理系统200进行的管理方法的程序进行说明。图11表示事件和依存关系的管理方法。管理系统200检测在管理对象的装置和系统中已发生的事件(S401)。管理系统200选择与检测出的事件有关的更新规则(规则ID)。而且，管理系统200根据相似性决定规则决定检测出的事件的相似性，对事件给予相似性(S402)。管理系统200提取与检测出的事件有关的依存关系(S403)。管理系统200将事件、依存关系、相似性、规则ID等存储在数据库204中(S404)。管理系统200检测更新契机(S405)。管理系统200从更新规则存储部8取得由检测出的更新契机适用的更新规则(S406)。管理系统200根据已取得的更新规则更新数据库204(S407)。

图12表示原因确定部205的处理程序。原因确定部205从故障检测部6取得故障发生单元(key)和故障发生时间(time)。原因确定部205在键(key)中代入故障发生单元，在时间(time)中代入故障发生时间。原因确定部205在使用变量Mi确定故障原因的情况下，对变量Mi进行初始化(S501)。原因确定部205以故障发生单元为键(key)，也使用故障发生时间，根据相似性来确定故障原因的侯补(S502)。原因确定部5同时输出已确定的故障原因的侯补和其的相似性(S503)。

图13表示故障原因的确定程序，即图12所示的步骤(S502)一例的更为详细的程序。原因确定部205把对相似性进行累积加法运算的变量，即存储相似性累积值的变量Mi代入到局部变量Mi′(S601)。原因确定部205根据已取得的故障发生时间(time)检索数据库204，确定故障发生时间之前的事件。而且，原因确定部205将之前的事件的事件发生时间代入到时间(time)(S602)。

原因确定部205判定之前的事件的依存源是否与已取得故障发生单元(key)一致(S603)。一致时，原因确定部205将之前的事件的相似性与变量Mi进行累积加法运算(S604)。原因确定部205判断累积加法运算后的变数Mi是否比阀值大(S605)。原因确定部205在判断为累积加法运算后的变数Mi比阀值大的情况下，确定之前的事件作为故障原因的侯补并进行存储(S606)。接着步骤(S606)进入到步骤(S607)。此外，在步骤(S605)，在判断为累积加法运算后的变数Mi比阀值小的情况下，原因确定部205绕过步骤(S606)，进入到步骤(S607)。

原因确定部205，将确定完事件的依存对方代入到键(key)，再次调用按照图10所示的故障原因探测程序的处理(S607)。原因确定部205根据确定完事件的依存对方(key)和事件发生时间(time)检索数据库204(S608)。

原因确定部205接着步骤(S608)，或在步骤(S603)，在之前的事件的依存源与故障发生单元(key)不一致时，尝试确定完成事件的之前的事件的确定。而且，原因确定部205将确定完成事件之前的事件的事件发生时间代入到时间中(time)(S609)。

原因确定部205在步骤(S609)判断是否可以确定之前的事件(S610)。即，原因确定部205判断之前的事件是否存在(NULL)。原因确定部5在之前的事件存在时，返回步骤(S603)，只要之前的事件存在就反复执行步骤(S603)～(S610)。另一方面，原因确定部205在之前的事件不存在(NULL)时，将局部变量Mi′代入到变量Mi(S611)，结束处理。

根据这样的管理系统200和管理方法，除了得到通过图1所示的管理系统100和图5～7所示的管理方法得到的效果之外，还能够得到以下的效果。管理系统200能够根据相似性选择可能性高的故障原因，能提高故障原因确定的精度。而且，根据管理系统200，即使是在故障发生单元依存于多个事件的情况下，也可以通过根据相似性的确定来抑制故障原因的侯补数量的增加，能够更容易地确定故障原因。而且，管理系统200能够给予与事件的种类对应的相似性、和根据依存关系将事件的相似性传播给依存的事件。因而，管理系统200可以较适当地给予相似性，更加提高故障原因确定的精度。

[第3实施例]

如图14所示，管理系统300具有事件监视部201、依存关系提取部2、存储部303、第1数据库304a、第2数据库304b、原因确定部305、故障检测部6、更新部307a、契机检测部7b、更新规则存储部8、和相似性决定规则存储部9。在图14中，与图1、8所示的管理系统100、200实际相同的结构附以相同的符号，省略说明。

管理系统300具有作为保存部的第1保存部的第1数据库304a和作为保存部的第2保存部的第2数据库304b。第1数据库304a可以使用易失性的存储媒体。易失性的存储媒体虽然记录速度为高速，但存储容量有限，容量单价高。例如，作为第1数据库304a，可以使用主存储器。第2数据库304b可以使用非易失性的存储媒体。非易失性的存储媒体虽然记录速度是低速，但存储容量大，容量单价低廉。即，第2数据库304b能够以低成本保存大量的数据。例如，作为第2数据库304b能够使用磁性存储装置和网络上的数据库服务器。第1数据库304a、第2数据库304b与图9表示的数据库204相同地保存数据。

存储部303在第1数据库304a存储从事件监视部201和依存关系提取部2取得的事件发生时的信息。因为能够向第1数据库304a高速存储信息，所以管理系统300能够降低随着信息存储的总开销。

更新部307a从第1数据库304a取得信息，并存储在第2数据库304b。即，更新部307a从第1数据库304a向第2数据库304b转录、转移信息。更新部307a例如在事先已规定的定时转移信息。例如，更新部307a能够在第1数据库304a所保存的信息量超过阀值时，和对作为管理对象的装置和系统进行升级时转移信息。

而且，更新部307a从第1数据库304a取得事件和依存关系进行更新，并将更新后的事件和依存关系存储在第2数据库304b中。即，更新部307a在信息转移的同时进行更新。

例如，如图3所示，由于更新契机规则表82保存着更新契机「向第2数据库的存储」，更新部307a在转移信息时能够执行更新。更新部307a以规则ID「0x02」、「0x04」的序号执行根据更新规则的更新。更新部307a根据规则ID「0x02」的更新内容更新从第1数据库304a取得的信息，存储在第2数据库304b之后，根据规则ID「0x04」的更新内容，删除第1数据库304a保存的信息。

原因确定部305参照第1数据库304a和第2数据库304b，使用第1数据库304a和第2数据库304b保存的信息确定故障原因。存储部303、原因确定部305和更新部307a除了这些功能之外，和图8所示的存储部203、原因确定部305和更新部207a实际上相同。

根据这样的管理系统300，除了得到使用图1、8所示的管理系统100、200所取得的效果之外，还能够得到以下的效果。通过管理系统300可以暂时将信息保存在第1数据库304a中，仅将必要的更新后的信息保存在第2数据库304b中。而且，由于是更新后的信息，可以削减第2数据库304b保存的信息量。

而且，管理系统300使用特性不同的2个存储媒体作为第1数据库304a和第2数据库304b。而且，管理系统300能够将信息暂时存储在可以高速记录的第1数据库304a中，并向第2数据库304b进行适当的转移。因而，管理系统300能降低在收集信息并将其存储在第1数据库304a时的总开销。

这样的管理系统300对存储容量有限的装置和系统特别有用。例如，在携带电话终端中，对存储容量的限制十分严格，为了保存用于确定故障原因的必要的信息而使用大量的存储器是不太现实的，但通过管理系统300就能够回避这样的情况。

Claims

1.一种管理系统，其特征在于，

具有：检测已发生的事件的事件监视部；

提取与上述事件有关的依存关系的依存关系提取部；

保存上述事件和上述依存关系的保存部；

根据更新规则对由上述保存部保存的上述事件和上述依存关系进行更新的更新部；和

参照上述保存部，根据上述事件和上述依存关系确定已发生的故障原因的原因确定部。

2.根据权利要求1所述的管理系统，其特征在于，

具有检测适用上述更新规则的更新契机，并向上述更新部通知该检测出的更新契机的契机检测部，

上述更新部根据由上述契机检测部通知的上述更新契机所适用的上述更新规则，来更新上述保存部。

3.根据权利要求1所述的管理系统，其特征在于，

上述保存部保存与上述更新规则有关的信息作为上述事件或上述依存关系的属性信息，

上述更新部根据与上述更新规则有关的信息更新上述保存部。

4.根据权利要求3所述的管理系统，其特征在于，

上述属性信息是识别上述更新规则的识别符，

上述更新部根据通过上述识别符所确定的更新规则更新上述保存部。

5.根据权利要求1所述的管理系统，其特征在于，

上述事件监视部对上述事件给予相似性，

上述保存部将上述相似性与上述事件对应地保存，

上述原因确定部根据上述相似性确定上述故障原因。

6.根据权利要求5所述的管理系统，其特征在于，

上述事件监视部根据上述事件的种类，或依存于上述事件的事件相似性中的至少一个来决定上述给予的相似性。

7.根据权利要求1所述的管理系统，其特征在于，

上述保存部具有第1保存部和第2保存部，

上述更新部从上述第1保存部取得上述事件和上述依存关系进行更新，并将更新后的事件和依存关系存储在上述第2保存部中。

8.一种管理方法，其特征在于，

检测已发生的事件；

提取与上述事件有关的依存关系；

根据更新规则对由保存部所保存的上述事件和上述依存关系进行更新；

参照上述保存部，根据上述事件和上述依存关系确定已发生的故障原因。