CN103778044B - 用于系统故障诊断和修复的方法和装置 - Google Patents

Abstract

本发明的实施例涉及用于系统故障诊断和修复的方法和装置。根据本发明的实施例，能够通过部署在系统一侧的监测装置(或称“代理”)自动地监视和采集系统中的故障表象信息。诊断装置在接收到此类信息之后，例如可以通过查询后端知识库而自动地确定故障表象，以及可选地生成用于修复该故障的可执行软件包。如果诊断装置发现目前获得的信息尚不足以确定足够可信的故障根源和/或不足以生成修复该故障的软件包，则诊断装置可以交互地控制监测装置收集所需的附加信息。以此方式，能够有效地提高故障诊断和修复的效率和准确性。

Description

用于系统故障诊断和修复的方法和装置

技术领域

本发明的实施例总体上涉及计算机领域，更具体地，涉及用于系统故障诊断和修复的方法和装置。

背景技术

在软件和/或硬件系统被开发和部署之后，对使用中的系统进行维护是一个重要的问题。目前，已知的软件系统维护策略总体上可以分为两类，人工方案和自动化方案。

人工方案依赖于培训和指派专门的技术人员或专家，由这些技术人员以人工的方式负责特定软件产品的故障解决和维护。然而，培训一名有经验和较高职业技术水平的专业人员往往需要花费大量的时间和成本。而且，统计表明：在发现和解决一个系统故障的总时间中，大约60％的时间被花费在故障的确定和识别上。更有甚者，统计还表明：在用户和技术人员通过长时间交流确定的故障根源中，有95％以上的故障是先前别人或者用户本人已经在遇到和解决过的。很明显，以人工方式进行系统维护和故障处理将导致人力、物力和时间的浪费。

自动化方案通常依赖于在服务器上建立知识库，该知识库用于保存先前已经发生过的故障及其解决方案。然而，目前大多数此类系统仅仅基于最初收集的故障表象(symptom)对知识库进行查询，并且将该查询确定的故障根源和相应解决方案返回给用户。然而，在系统故障刚刚发生时收集的信息往往不足以确定真正的故障根源。例如，很多不同的故障或异常在刚开始发生的初始阶段可能具有相同的表象。此时，基于这些初级表象进行诊断有可能无法确定正确的故障根源。

实际上，软件和/或硬件系统中具有相同表象的故障很可能是由不同的根源导致的。例如，在大型存储系统中，存在很多因素可能导致“用户无法连接到特定存储阵列”这一故障表象。另一方面，系统中的同一根源在不同的使用情况和状态下可能导致不同的表象。此时，仅仅依靠初期表象来诊断故障根源是不足的。

因此，本领域中需要一种更为有效的故障诊断和修复方案。

发明内容

鉴于上述问题，本发明的实施例提供用于系统故障诊断和修复的方法和装置。

在本发明的第一方面，提供一种用于监测系统中的故障的监测装置。该监测装置包括：采集单元，被配置为采集与系统中的故障的表象有关的信息；传送单元，被配置为将采集到的信息传送给诊断装置；以及接收单元，被配置为从诊断装置接收用于采集与故障有关的附加信息的命令，并且作为响应使采集单元采集附加信息。

在本发明的第二方面，提供一种用于诊断系统中的故障的诊断装置。该诊断装置包括：接收单元，被配置为从部署在系统一侧的监测装置接收与系统中的故障的表象有关的信息；分析单元，被配置为分析接收到的信息以确定故障的根源；以及控制单元，被配置为响应于无法确定根源或者确定的根源的置信度低于预定阈值，与监测装置通信以控制监测装置采集与故障有关的附加信息。

在本发明的第三方面，提供一种用于监测系统中的故障的方法。该方法包括：采集与系统中的故障的表象有关的信息；将采集到的信息传送给诊断装置；以及从诊断装置接收用于采集与故障有关的附加信息的命令，并且作为响应采集附加信息。

在本发明的第四方面，提供一种用于诊断系统中的故障的方法。该方法包括：从部署在系统一例的监测装置接收与系统中的故障的表象有关的信息；分析接收到的信息以确定故障的根源；以及响应于无法确定根源或者确定的根源的置信度低于预定阈值，与监测装置通信以控制监测装置采集与故障有关的附加信息

通过下文描述将会理解，根据本发明的实施例，能够通过部署在系统一侧的监测装置(或称“代理”)自动地监视和采集系统中的故障表象信息。诊断装置在接收到此类信息之后，例如可以通过查询后端知识库而自动地确定故障表象，以及可选地生成用于修复该故障的可执行软件包。特别地，如果诊断装置发现目前获得的信息尚不足以确定足够可信的故障根源和/或不足以生成修复该故障的软件包，则诊断装置可以交互地控制监测装置收集所需的附加信息。以此方式，能够有效地提高故障诊断和修复的效率和准确性。

附图说明

通过参考附图阅读下文的详细描述，本发明实施例的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本发明的若干实施例，其中：

图1示出了根据本发明一个示例性实施例的用于监测系统中的故障的监测装置100的框图；

图2示出了根据本发明一个示例性实施例的用于诊断系统中的故障的诊断装置200的框图；

图3示出了根据本发明一个示例性实施例的用于监测系统中的故障的方法300的流程图；

图4示出了根据本发明一个示例性实施例的用于诊断系统中的故障的方法400的流程图；

图5示出了适合用来实践本发明实施例的计算机500的框图。

在各个附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考附图中示出的若干示例性实施例来描述本发明的原理和精神。应当理解，给出这些实施例仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。

根据本发明的实施例，可以通过分布式的方式来监测和诊断系统中的故障。一般而言，在系统一侧可部署有监测装置，用于监测与系统中的故障有关的信息；另一方面，独立于监测装置(例如，部署在后端服务器处)的故障诊断装置可以与监测装置交互，以便诊断以及可选地修复系统中的故障。

注意，在此使用的术语“系统”可以是硬件系统，也可以软件系统，本发明的范围在此方面不受限制。在此使用的术语“故障”是指影响或者潜在影响系统正常运行的任何问题、失效、异常等等。另外，在此使用的术语“装置”(apparatus)既可以指基于硬件构成的设备或模块，也可以是基于软件构成的模块。

首先参考图1，其示出了根据本发明一个示例性实施例的用于监测系统中的故障的诊断装置100的框图。根据本发明的实施例，装置100可以驻留在所要监测的系统一侧。特别地，在此描述的“监测装置”也可以称为“代理”(agent)。

如图1所示，根据本发明的实施例，监测装置100包括采集单元101，其可被配置为采集与系统中的故障的表象有关的信息。在此使用的术语“表象”是指对故障的症状的描述，即，故障引起了哪些系统行为或状态。例如，表象信息可以包括故障的出现时间、当时的系统状态、引发的系统行为、系统上下文、系统抛出的异常(exception)等等。另外，故障表象还可以包括系统配置文件中的信息、操作系统(OS)配置信息、硬件配置信息、网络配置信息，等等。上面描述的仅仅是一些示例，根据本发明实施例的采集单元101可操作以采集与故障表象有关的任何信息。

特别地，故障表象信息还可以包括与系统有关的日志(log)中的信息。可以理解，日志通常由一系列日志条目组成，每个日志条目可以包括用于记录不同类型信息的一个或多个字段。例如，下表示出了一个可能的软件系统的日志条目的结构。

等级

时间

事件

描述

分类

来源

类型

注意，上面所示的结构仅仅是示例性的，用于记录软件系统的行为和问题的任何日志结构均落在本发明的范围之内。而且，除了日志信息之外或者作为补充，可以存储其他形式的故障表象。本发明的范围在此方面不受限制。

根据本发明的实施例，监测装置100中的采集单元101例如可以在后台持续地采集各种故障信息。备选地，采集单元101也可以基于预定的周期而间歇性地工作。另外，采集单元101也可由系统的用户交互式地启用和禁用。本发明的范围在此方面不受限制。

如图1所示，监测装置100还包括传送单元102，其可被配置为将采集到的信息传送给诊断装置。如下文详述，诊断装置可以驻留于系统的远程或本地。传送单元102可以利用各种适当的信息通信机制与诊断装置通信。

例如，在诊断装置位于系统远程的实施例中，传送单元102可以借助于网络通信机制将采集单元101所采集的故障表象信息传送给诊断装置。网络例如可以包括有线网络、无线网络或其组合，包括但不限于以下至少一个：蜂窝电话网络，以太网，基于IEEE 802.11、802.16、802.20等的无线局域网(WLAN)，和/或全球微波接入互操作性(WiMAX)网络。此外，网络可以是公共网络(诸如，因特网)、专用网络(诸如，企业内部网)或其组合。利用上述网络，传送单元102与诊断装置可以基于Syslog，SNMP and HTTPS等各种适当的协议通信。备选地或附加地，也可以使用总线、线缆、光纤等机制实现信息通信。

另外，在诊断装置与监测装置100驻留于相同物理机器的实施例中，传送单元102可以借助于机器内部通信机制将采集单元101所采集的故障表象信息传送给诊断装置。这样的通信机制例如总线通信或进程间通信，等等。本发明的范围在此方面不受限制。

当诊断装置接收到故障表象信息之后，可以分析该信息以尝试确定故障的根源。特别地，如果无法确定根源或者确定的根源置信度较低，则诊断装置不是简单地返回错误提示或者被动地继续等待监测装置的进一步动作，而是可以主动地与监测装置通信，以控制或者命令监测装置采集与故障有关的附加信息。

相应地，根据本发明实施例的监测装置100包括接收单元103，其可被配置为从诊断装置接收用于采集与故障有关的附加信息的命令，并且作为响应使采集单元101采集该附加信息。

例如，在某些实施例中，诊断装置可能无法基于目前的故障表现确定问题的根源，因为不同根源所导致的故障在早期可能具有相同的表象。由此，诊断装置可以向接收单元103传送命令以指示监测装置100采集与故障的进一步表象有关的信息。在这些实施例中，接收单元103接收到该命令，并且通知采集单元101相应地操作。采集单元101包括第一采集单元(未示出)，被配置为响应于接收单元103接收到的上述命令，采集与故障的进一步表象有关的信息。被采集的该信息将由传送单元102传送给诊断装置。

备选地或附加地，对于某些比较复杂的故障，诊断装置可能无法基于监测装置采集的信息完全自动地确定出故障根源，而是可能需要交互式地获取用户关于该故障的输入。此时，诊断装置可以向接收单元103传送命令以指示监测装置100采集与故障有关的用户输入。在这些实施例中，接收单元103接收到该命令，并且通知采集单元101相应地操作。采集单元101包括第二采集单元(未示出)，被配置为响应于接收单元103接收到的上述命令，采集与故障有关的用户输入，例如用户对于故障的描述、对系统中相关状态的描述、基于以往经验对故障根源做出的人工预测等等。根据本发明的实施例，第二采集单元可以利用各种交互手段实现与用户的交互，例如图形用户界面(GUI)以及相关联的各种控件(例如文本框、单选框、复选框、下拉列表，等等)或者音频、视频等多模态交互机制。被采集的用户输入信息将由传送单元102传送给诊断装置以便辅助确定故障根源。

备选地或附加地，仅凭故障表象和/或用户输入可能仍然无法准确地确定出故障的根源。一种解决方法是对系统的行为加以引导，并且根据系统的反应来判断故障根源。此时，诊断装置可以向接收单元103传送命令以指示监测装置100执行与系统相关联的一个或多个动作，并且采集与该动作引起的结果有关的信息。在这些实施例中，接收单元103接收到该命令，并且通知采集单元101相应地操作。采集单元101可以包括第三采集单元(未示出)，被配置为响应于接收单元103接收到的上述命令，执行与系统相关联的一个或多个动作并且采集与该动作引起的结果有关的信息。根据本发明的实施例，所执行的动作可以是诊断装置确定的，通过执行这些动作并且采集系统的反馈，能够有助于确定故障根源。例如，如果故障是系统无法连接到网络，则诊断装置可以控制监测装置向网络端口发送请求消息，并且根据是否获得相应来判断网络端口目前是否正常工作。被采集的系统反馈信息将由传送单元102传送给诊断装置以便辅助确定故障根源。

可以理解，根据本发明的实施例，采集单元101可以包括上面描述的第一、第二和第三采集单元中的一个或多个。而且，上文描述的仅仅是示例性的。根据本发明的实施例，诊断装置可以根据需要以交互式方式控制监测装置100采集与系统故障有关的任何附加/辅助信息以用于确定故障根源。本发明的范围在此方面不受限制。而且，在监测装置与诊断装置之间可以进行不止一轮的上述交互，以逐步获取确定故障根源的足够信息。

根据某些实施例，诊断装置在确定根源之后可以生成相应的可执行软件包(例如，升级包、补丁包，等等)，这将在下文详述。在这些实施例中，监测装置100可以包括可选的修复包执行单元(未示出)，其可被配置为执行从诊断装置接收到的用于修复故障的可执行软件包。

特别地，诊断装置可能在确定故障根源之后发现目前所获取的信息上不足以生成可执行软件包。换言之，由监测装置100传送给诊断中的信息已经足以确定故障的根源，但是还不足以修复该故障。此时，诊断装置可以命令监测装置100继续采集修复该故障所需的附加信息。此类命令可由接收单元103接收，并且采集单元101可以相应地动作。具体而言，采集单元101可以包括第四采集单元(未示出)，其可被配置为响应于接收单元103从诊断装置接收到的上述命令，采集生成所述可执行软件包所需的附加信息。这些附加信息例如可以包括系统所在物理机器的配置、软件环境、OS环境、网络环境、存储器和/或处理器使用率，等等。采集到的附加信息将由传送单元102传送给诊断装置，以便生成用于故障修复的可执行软件包。

另外，根据本发明的某些实施例，监测装置100还可以包括修复反馈单元(未示出)，其可配置为根据是否通过执行可执行软件包而成功地修复了故障，而向诊断装置传送修复成功信息或修复失败信息。特别地，如果执行可执行软件包之后采集单元101仍然能够采集到与故障表象有关的信息，则可以认为修复动作失败。此时，修复反馈单元向诊断装置传送指示修复失败的信息。可选地，该信息中可以包含修复失败的具体参数或数据。相应地，诊断装置可以根据修复失败信息判断失败原因，并且相应地指示监测装置收集附加信息以便重新生成用于修复的可执行软件包，这还将在下文详述。

上文已经参考图1描述了根据本发明实施例的监测装置100的若干示例。限制将参考附图2描述根据本发明示例性实施例的用于诊断系统故障的诊断装置200。

如图2所示，根据本发明的实施例，诊断装置200包括接收单元201，其可被配置为从所述系统中的监测装置接收与系统中的故障表象有关的信息。表象信息的若干示例已经在文参考图1讨论，在此不再赘述。

根据本发明的某些实施例，接收单元201可以将接收到的表象信息进行标准化，以使其具有标准化的格式以利于后续操作。例如，一种标准化格式的示例可以是[系统类型，系统ID，时间，日志等级(可选，发生故障的模块名、异常名称(可选)，数据...]。应当理解，这仅仅示例性的，并非意在限制本发明的范围。

继续参考图2，诊断装置200还包括分析单元202，其可被配置为分析接收到的信息以确定所述故障的根源。根据某些实施例，分析单元202可以对接收的信息执行基于规则的分析。例如，在诊断装置200一侧可以维护有一系列预定的规则，指明故障表象与根源之间的对应关系。这些规则可以利用各种适当的方式保存，例如文本文件、格式化文本、数据库，等等。

备选地或附加地，可以维护有诊断装置200可访问的故障知识库。该知识库可以存储有与至少一个先前故障有关的信息。例如，知识库可以存储先前已经发生的问题的表象、根源和解决方案。根据本发明的某些实施例，知识库中的信息可以是人工生成、输入和控制的。备选地或附加地，可以利用数据挖掘和训练的方法来管理知识库。例如，基于先前已经发生过的故障的相关信息，可以采用各种目前已知或者将来的技术对知识库进行训练，从而得到“表象-根源”和“根源-解决方案”的映射关系。在此方面，通常的训练过程可以包括以下主要步骤：数据挑选；预处理；变换、数据挖掘以及解释/评估。数据挖掘技术的示例可以包括关联规则、聚类分析、半超学习(semi-super learning)、数据分类技术等等。本发明的范围在此方面不受限制。

相应地，在这些实施例中，分析单元202可以包括知识库查询单元(未示出)，其可被配置为利用接收到的信息查询知识库以确定故障的根源。例如，知识库查询单元可以采用演绎推理(deductive reasoning，DE)技术来执行分析过程，以根据输入的表象找到知识库中对应问题根源。另一种可行的方式是使用复杂事件处理(Complex Event Processing，CPE)技术，其可用于根据低级别的事件(例如，故障表象)确定对应的高级别事件(例如，故障根源)。此外，神经网络、贝叶斯网络等各种其他方式均可以被用于基于故障表象确定故障根源。

另外，根据本发明的某些实施例，知识库可以是可更新的。在这些实施例中，诊断装置200可以包括知识库更新单元(未示出)，其可被配置为响应于确定的根源不存在于知识库中，而将与故障的根源和表象有关的信息添加到知识库中。如果分析装置202无法在知识库中找到与表象匹配的故障根源，则可以求助于人类专家。由专家确定的根源继而可以被馈送到知识库，从而对知识库进行训练和学习，以实现知识的更新。

继续参考图2，诊断装置200还包括控制单元203，其可被配置为响应于无法确定根源或者确定的根源的置信度低于预定阈值，而与监测装置通信以控制监测装置采集与故障有关的附加信息。具体而言，如果分析单元202无法根据目前从监测装置接收到的信息确定问题的根源，或者虽然确定了问题的根源但是通过DE或CPE技术返回的根源的置信度低于一个预定阈值(即，虽然可以认为存在与表象匹配的根源，但是这种匹配的程度较弱)，诊断装置200可以利用控制单元203命令监测装置收集更多信息，而不是直接向人工专家求助。实际上，有时即使是人工专家也无法从当前收集的信息准确地判定故障根源，而是需要收集更多的故障信息以确定故障根源。

如上文已经参考图1所描述的，采集的附加信息可以包括以下一个或多个：与故障的进一步表象有关的信息，与故障有关的用户输入，与监测装置导致执行的一个或多个动作的结果有关的信息，等等。相应地，根据本发明的实施例，控制单元203可以包括以下至少一个：第一控制单元，可被配置为控制监测装置采集与故障的进一步表象有关的信息；第二控制单元，被配置为控制监测装置采集与故障有关的用户输入；以及第三控制单元，被配置为控制监测装置在系统中执行一个或多个动作并且采集与动作引起的结果有关的信息。

在某些实施例中，诊断装置200还可以包括修复包生成单元(未示出)，其可被配置为基于确定的根源生成用于修复该故障的可执行软件包，并且将所述可执行软件包传送给监测装置以便在系统中执行。特别地，可以理解的是，在某些情况下从监测装置获得的信息已经足以确定故障根源，但是尚不足以生成修复故障所需的软件包。为此，在某些实施例中，控制单元203可以包括第四控制单元，其可被配置为响应于接收到的信息不足以生成可执行软件包，而与监测装置通信以控制监测装置采集生成可执行软件包所需的附加信息。

如上所述，如果监测装置执行由修复包生成单元生成的可执行包没有成功修复故障，则监测装置可以向诊断装置200发送修复失败信息。为此，根据本发明的某些实施例，控制单元203可以包括第五控制单元，被配置为响应于从监测装置接收到修复失败信息，而与所述监测装置通信以控制监测装置与故障相关的附加信息。如上文所述，在监测装置发送的修复失败信息中，可以包含有关于修复的具体参数、细节和数据。由此，第五控制单元可以确定完全修复故障还需要哪些附加信息，并且命令监测装置采集这些信息。

可以理解，修复失败可能是因为确定的故障根源不正确，也可能是因为修复动作不恰当或不完备，或者二者兼具。相应地，第五控制单元可以命令监测装置收集确定正确故障根源所需的附加信息和/或生成正确修复包所需的附加信息。

通过上文描述可以看到，通过部署和使用上文分别参考图1和图2描述的监测装置100和诊断装置200，可以自动采集与系统中的故障有关的信息，并且可以有效地确定故障根源以及可选地自动修复故障。特别地，诊断装置可以根据诊断和/或修复的需要而动态地与监测装置进行一次或多次交互，以收集足够的信息完成故障诊断和修复。

注意，根据本发明的实施例，监测装置100和诊断装置200可以利用各种方式实现。例如，在某些实施例中，监测装置100和诊断装置200可以利用软件和/或固件来实现。备选地或附加地，监测装置100和诊断装置200可以部分地或者完全地基于硬件来实现。例如，监测装置100和诊断装置200可以实现为集成电路(IC)芯片或专用集成电路(ASIC)。监测装置100和诊断装置200也可以实现为片上系统(SOC)。现在已知或者将来开发的其他方式也是可行的，本发明的范围在此方面不受限制。

现在参考图3，其示出了根据本发明示例性实施例的用于监测系统中的故障的方法300的流程图。方法300可以由上文描述的监测装置100执行。

如图3所示，方法300开始之后，在步骤S301，采集与系统中的故障的表象有关的信息。接下来在步骤S302，可以将采集到的信息传送给诊断装置。

方法300继而进行到步骤S303，在此从诊断装置接收用于采集与故障有关的附加信息的命令，并且作为响应采集附加信息以便传送给诊断装置。根据本发明的某些实施例，采集附加信息可以包括以下或多个：响应于从诊断装置接收到的命令，采集与故障的进一步表象有关的信息；响应于从诊断装置接收到的命令，采集与故障有关的用户输入；以及响应于从诊断装置接收到的命令，在系统中执行一个或多个动作并且采集与动作引起的结果有关的信息。

根据本发明的某些实施例，方法300可以进行到可选的步骤S304，在此响应于从诊断装置接收到的命令，采集生成用于修复故障的可执行软件包所需的附加信息以便传送给诊断装置。接下来，在步骤S305处，可以执行从诊断装置接收到的用于修复故障的可执行软件包。

此后，在步骤S306判断是否已经通过执行可执行软件包而成功修复了故障。如果没有(分支“否”)，方法300进行到步骤S307，在此向诊断装置传送修复失败信息。此后，根据修复失败的具体原因，诊断装置可能命令监测装置继续收集用于确定故障根源的附加信息和/或用于生成正确修复包的附加信息。相应地，方法300可以返回到步骤S303和/或S304继续执行。

另一方面，如果在步骤S306处确定通过执行修复软件包已经成功修复了故障(分支“是”)，则方法300进行到步骤S308，在此向诊断装置传送修复成功信息，并且方法300随之结束。请注意，在此所说的“结束”是指逻辑上的。在实践中，监测装置可以返回步骤S301继续监测系统中的任何故障。

下面参考图4，其示出了根据本发明一个示例性实施例的用于诊断系统中的故障的方法400的流程图。方法400可以由上文描述的诊断装置200执行。

如图4所示，方法400开始之后，在步骤S401，从部署在系统一侧的监测装置接收与系统中的故障表象有关的信息。接下来，方法400进行到步骤S402，在此分析接收到的信息以确定故障的根源。根据某些实施例，这可以包括利用接收到的信息查询知识库以确定故障的根源，知识库存储有与至少一个先前故障有关的信息。可选地，在这些实施例中，还可以响应于确定的根源不存在于知识库中而将与故障有关的信息添加到知识库中。

方法400继而进行到步骤S403，在此判断是否确定出了置信度高于预定阈值的根源。响应于无法确定根源或者确定的根源的置信度低于预定阈值(分支“否”)，方法400进行到步骤S404，在此与监测装置通信以控制监测装置采集与故障有关的附加信息并且接收该信息。根据某些实施例，在步骤S404例如可以执行以下至少一个操作：控制监测装置采集与故障的进一步表象有关的信息；控制监测装置采集与故障有关的用户输入；以及控制监测装置在系统中执行一个或多个动作并且采集与动作引起的结果有关的信息。此后，方法400返回步骤S402以继续分析故障根源。

另一方面，如果在步骤S403判定已经确定了置信度足够高的故障根源(分支“是”)，则执行可选的步骤S405以判定目前所具有的信息是否足以生成用于修复该故障的可执行软件包。如果否，方法400进行到步骤S406，在此与监测装置通信以控制监测装置采集生成可执行软件包所需的附加信息。另一方面，如果在步骤S405判定目前获取的信息已经足以生成用于修复的可执行软件包，方法400进行到步骤S407，在此生成用于修复故障的可执行软件包，并且将可执行软件包传送给监测装置以供执行。

可选地，方法400继而进行到步骤S408，在此确定是否从监测装置接收到了修复失败信息。如果是，则诊断装置可以通过该修复失败信息中包含的具体参数和数据来确定失败的原因，例如确定的根源有误和/或生成的修复包存在问题。相应地，方法400可以返回步骤S404和/或406，在此与监测装置通信以控制监测装置采集修复故障所需的相应附加信息。

另一方面，如果没有从监测装置接收到修复失败信息，则方法400在步骤S408之后结束。请注意，在此所说的“结束”是指逻辑上的。在实践中，诊断装置可以返回步骤S401继续诊断系统中的任何故障。

可以理解，上文结合图1和图2描述的所有特征分别适用于方法300和400，在此不再赘述。

下面参考图5，其示出了适于用来实践本发明实施例的计算机500的示意性框图。如图所示，计算机500可以包括：CPU(中央处理单元)501、RAM(随机存取存储器)502、ROM(只读存储器)503、系统总线504、硬盘控制器505、键盘控制器506、串行接口控制器507、并行接口控制器508、显示控制器509、硬盘510、键盘511、串行外部设备512、并行外部设备513和显示器514。在这些设备中，与系统总线504耦合的有CPU 501、RAM 502、ROM 503、硬盘控制器505、键盘控制器506、串行控制器507、并行控制器508和显示控制器509。硬盘510与硬盘控制器505耦合，键盘511与键盘控制器506耦合，串行外部设备512与串行接口控制器507耦合，并行外部设备513与并行接口控制器508耦合，以及显示器514与显示控制器509耦合。应当理解，图5所述的结构框图仅仅为了示例的目的而示出的，而不是对本发明范围的限制。在某些情况下，可以根据具体情况而增加或者减少某些设备。

如上所述，监测装置100和诊断装置200可以通过硬件实现，例如芯片、ASIC、SOC等。这些硬件可以集成在计算机500中。此外，本发明的实施例也可以通过计算机程序产品的形式实现。例如，参考图3和图4描述的方法300和400可以通过计算机程序产品来实现。该计算机程序产品可以存储在例如图5所示的RAM 504、ROM 504、硬盘510和/或任何适当的存储介质中，或者通过网络从适当的位置下载到计算机500上。计算机程序产品可以包括计算机代码部分，其包括可由适当的处理设备(例如，图5中示出的CPU 501)执行的程序指令。所述程序指令至少可以包括用于实现方法300和400的步骤的指令。

应当注意，本发明的实施例可以通过硬件、软件或者软件和硬件的结合来实现。硬件部分可以利用专用逻辑来实现；软件部分可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域的普通技术人员可以理解上述的设备和方法可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本发明的设备及其模块可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用由各种类型的处理器执行的软件实现，也可以由上述硬件电路和软件的结合例如固件来实现。

说明书中提及的通信网络可以包括各类网络，包括但不限于局域网(“LAN”)，广域网(“WAN”)，根据IP协议的网络(例如，因特网)以及端对端网络(例如，ad hoc对等网络)。

应当注意，尽管在上文详细描述中提及了设备的若干单元，但是这种划分仅仅并非强制性的。实际上，根据本发明的实施例，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来实现。

此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施例描述了本发明，但是应该理解，本发明并不限于所公开的具体实施例。本发明旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。所附权利要求的范围符合最宽泛的解释，从而包含所有这样的修改及等同结构和功能。

Claims (24)

1.一种用于监测系统中的故障的监测装置，所述监测装置包括：

采集单元，被配置为采集与所述系统中的故障的表象有关的信息；

传送单元，被配置为将采集到的所述信息传送给诊断装置；以及

接收单元，被配置为从所述诊断装置接收用于采集与所述故障有关的附加信息的命令并且使所述采集单元采集所述附加信息，并且所述诊断装置被配置为响应于以下至少一项来交互地控制所述监测装置以收集期望的所述附加信息：

无法确定根源，

与所述根源相关联的置信度低于阈值，以及

无法生成软件包。

2.根据权利要求1所述的监测装置，其中所述采集单元包括以下至少一个：

第一采集单元，被配置为响应于由所述接收单元从所述诊断装置接收到的命令，采集与所述故障的进一步表象有关的信息；

第二采集单元，被配置为响应于由所述接收单元从所述诊断装置接收到的命令，采集与所述故障有关的用户输入；以及

第三采集单元，被配置为响应于由所述接收单元从所述诊断装置接收到的命令，执行与所述系统相关联的至少一个动作并且采集与所述至少一个动作引起的结果有关的信息。

3.根据权利要求1所述的监测装置，其中所述采集单元包括：

第四采集单元，被配置为响应于由所述接收单元从所述诊断装置接收到的命令，采集生成用于修复所述故障的可执行软件包所需的附加信息以便由所述传送单元传送给所述诊断装置。

4.根据权利要求1所述的监测装置，进一步包括：

修复包执行单元，被配置为执行从所述诊断装置接收到的用于修复所述故障的可执行软件包。

5.根据权利要求4所述的监测装置，进一步包括：

修复反馈单元，被配置为根据是否通过执行所述可执行软件包而修复了所述故障，向所述诊断装置传送修复成功信息或修复失败信息。

6.一种用于诊断系统中的故障的诊断装置，所述诊断装置包括：

接收单元，被配置为从部署在所述系统一侧的监测装置接收与所述系统中的故障的表象有关的信息；

分析单元，被配置为分析接收到的所述信息以确定所述故障的根源；以及

控制单元，被配置为响应于无法确定所述根源或者确定的所述根源的置信度低于预定阈值，与所述监测装置通信以控制所述监测装置采集与所述故障有关的附加信息。

7.根据权利要求6所述的诊断装置，其中所述控制单元包括以下至少一个：

第一控制单元，被配置为控制所述监测装置采集与所述故障的进一步表象有关的信息；

第二控制单元，被配置为控制所述监测装置采集与所述故障有关的用户输入；以及

第三控制单元，被配置为控制所述监测装置执行与所述系统相关联的至少一个动作并且采集与所述至少一个动作引起的结果有关的信息。

8.根据权利要求6所述的诊断装置，其中所述分析单元包括：

知识库查询单元，被配置为利用接收到的所述信息查询知识库以确定所述故障的根源，所述知识库存储有与至少一个先前故障有关的信息。

9.根据权利要求8所述的诊断装置，进一步包括：

知识库更新单元，被配置为响应于确定的所述根源不存在于所述知识库中，将与所述故障有关的信息添加到所述知识库中。

10.根据权利要求6所述的诊断装置，其中所述控制单元包括：

第四控制单元，被配置为响应于接收到的所述信息不足以生成用于修复所述故障的可执行软件包，与所述监测装置通信以控制所述监测装置采集生成所述可执行软件包所需的附加信息。

11.根据权利要求6所述的诊断装置，进一步包括：

修复包生成单元，被配置为基于确定的所述根源生成用于修复所述故障的可执行软件包，并且将所述可执行软件包传送给所述监测装置以供执行。

12.根据权利要求11所述的诊断装置，其中所述控制单元包括：

第五控制单元，被配置为响应于从所述监测装置接收到修复失败信息，与所述监测装置通信以控制所述监测装置采集与所述故障有关的附加信息。

13.一种用于监测系统中的故障的方法，所述方法包括：

采集与所述系统中的故障的表象有关的信息；

将采集到的所述信息传送给诊断装置；以及

从所述诊断装置接收用于采集与所述故障有关的附加信息的命令，并且采集所述附加信息，并且所述诊断装置被配置为响应于以下的至少一项来使得期望的所述附加信息被收集：

无法确定根源，

与所述根源相关联的置信度低于阈值，

无法生成软件包。

14.根据权利要求13所述的方法，其中采集所述附加信息包括以下至少一个：

响应于从所述诊断装置接收到的命令，采集与所述故障的进一步表象有关的信息；

响应于从所述诊断装置接收到的命令，采集与所述故障有关的用户输入；以及

响应于从所述诊断装置接收到的命令，执行与所述系统相关联的至少一个动作并且采集与所述至少一个动作引起的结果有关的信息。

15.根据权利要求13所述的方法，进一步包括：

响应于从所述诊断装置接收到的命令，采集生成用于修复所述故障的可执行软件包所需的附加信息以便传送给所述诊断装置。

16.根据权利要求13所述的方法，进一步包括：

执行从所述诊断装置接收到的用于修复所述故障的可执行软件包。

17.根据权利要求16所述的方法，进一步包括：

根据是否通过执行所述可执行软件包而修复了所述故障，向所述诊断装置传送修复成功信息或修复失败信息。

18.一种用于诊断系统中的故障的方法，所述方法包括：

从部署在所述系统一侧的监测装置接收与所述系统中的故障的表象有关的信息；

分析接收到的所述信息以确定所述故障的根源；以及

响应于无法确定所述根源或者确定的所述根源的置信度低于预定阈值，与所述监测装置通信以控制所述监测装置采集与所述故障有关的附加信息。

19.根据权利要求18所述的方法，其中与所述监测装置通信以控制所述监测装置采集与所述故障有关的附加信息包括以下至少一个：

控制所述监测装置采集与所述故障的进一步表象有关的信息；

控制所述监测装置采集与所述故障有关的用户输入；以及

控制所述监测装置执行与所述系统相关联的至少一个动作并且采集与所述至少一个动作引起的结果有关的信息。

20.根据权利要求18所述的方法，其中分析接收到的所述信息以确定所述故障的根源包括：

利用接收到的所述信息查询知识库以确定所述故障的根源，所述知识库存储有与至少一个先前故障有关的信息。

21.根据权利要求20所述的方法，进一步包括：

响应于确定的所述根源不存在于所述知识库中，将与所述故障有关的信息添加到所述知识库中。

22.根据权利要求18所述的方法，进一步包括：

响应于接收到的所述信息不足以生成用于修复所述故障的可执行软件包，与所述监测装置通信以控制所述监测装置采集生成所述可执行软件包所需的附加信息。

23.根据权利要求18所述的方法，进一步包括：

生成用于修复所述故障的可执行软件包，并且将所述可执行软件包传送给所述监测装置以供执行。

24.根据权利要求23所述的方法，进一步包括：

响应于从所述监测装置接收到修复失败信息，与所述监测装置通信以控制所述监测装置采集与所述故障有关的附加信息。