分布式系统、服务器计算机、分布式管理服务器和故障防止方法与流程

分布式系统、服务器计算机、分布式管理服务器和故障防止方法引用并入本申请基于2012年9月24日提交的日本专利申请号2012-209911并且要求其优先权，其公开通过引用整体包含于此。技术领域本申请涉及一种分布式系统、服务器计算机、分布式管理服务器和故障防止方法。

背景技术：
在业务系统中，经常由于应用服务器上所实施的业务应用程序中的缺陷而出现故障，导致整个业务系统瘫痪。业务应用中的故障示例包括以下。第一示例是死锁。死锁是指其中执行应用逻辑的多个线程相互进行互斥控制（锁定获取等）并且因此每个线程的执行都保持被阻止的状态。在这种情况下存在着问题，诸如用作诸如浏览器的应用的调用方的客户端应用无法获取针对请求的相应，从而无法更新屏幕。第二示例是过度存储器消耗。过度存储器消耗是指其中可用于应用服务器的存储器区域例如由于在与业务相关的查询处理中对大量数据进行处理的应用逻辑的一次性执行而减少的情形。在这种情况下，在并行执行相同处理上所运行的另一应用逻辑的线程的处理中可能出现延迟，或者由于在处理期间存储器短缺导致错误可能出现。最差的情况下，应用服务器的处理中止。第三示例是过度中央处理器（CPU）消耗（过高CPU使用）。过度CPU消耗是指其中CPU由于出现无限循环或冗余应用逻辑而比必要情况下使用得更多的情形。在这种情况下，例如出现应用调用方无法获取针对请求的响应从而无法更新屏幕的问题。还会出现在并行执行相同处理上所运行的另一应用逻辑的线程的处理中出现延迟的问题。当这样的情况发生时，其通常可以通过重启故障应用服务器而被消除。然而，在任意情形中，根本的解决方案需要对所涉及的应用程序进行修改。出于该原因，系统操作任意可能必须采取临时措施，诸如定期重启应用服务器或者对关于应用服务器的参数进行调谐，从而防止如以上所描述的故障再次发生直至应用得以被修改。作为用于应对故障的技术，日本未审专利申请公开号2010-9127公开了一种识别作为故障原因的组件的管理装置。特别地，当其中包括应用服务器的计算机和包括管理系统的计算机经由网络连接在一起的系统中出现异常时，该管理装置能够确定该故障发生在应用服务器和管理系统中的哪一个之中。日本未审专利申请公开号2006-338069公开了一种响应于故障的迹象或发生而防止错误出现以及防止性能下降的组件软件操作架构。特别地，在包括多个组件（软件组件）的组件软件的执行期间，该组件软件操作架构利用另一组件对组件进行替换。日本未审专利申请公开号2005-209029公开了一种包括多个应用服务器计算机和管理服务器计算机的应用管理系统。每个应用服务器计算机参考存储在管理服务器计算机中的应用操作定义存储文件以对已经请求其执行的应用的执行进行控制和管理。当在应用服务器计算机所执行的应用中发生故障时，应用服务器计算机将该事实通知另一应用服务器计算机或外部计算机。目前，使用云计算技术的系统化正在普及。这样的系统化是指构建一个使用分布于许多网络上的大量应用服务器的系统。在这样的环境中，负载是分布式的。因此，在单个服务器中发生异常（例如，由于发生故障）不太可能导致整个系统瘫痪。然而，如果故障是由与应用程序自身相关联的问题所导致，则所有应用服务器都存在着在未来经历相同故障的潜在风险。出于该原因，系统操作人员必须不可避免地采取如以上所描述的临时措施，除非其采取了诸如将故障应用降低至之前版本的措施。另外，随着服务器数量的增加，这样的故障更可能在系统中出现。这导致了采取临时措施的操作成本的增加。日本未审专利申请公开号2010-9127和2006-338069中均未考虑到诸如应用服务器的多个服务器如云计算中那样进行部署的情形。对于根据日本未审专利申请公开号2005-209029的应用管理系统而言，当在由应用服务器计算机所执行的应用中出现异常时，其无法防止在另一应用服务器计算机中发生类似的异常。

技术实现要素：
本发明的目标的示例是提供一种防止在服务器中出现故障而并不增加系统操作人员的负担的分布式系统、服务器计算机、分布式管理服务器和故障防止方法。在本发明的第一示例性方面，一种分布式系统包括：能够执行相同应用的第一和第二服务器，其中当该第一服务器中的该应用中出现故障时，该第一服务器生成识别该应用中的故障的原因的故障信息，并且该第二服务器执行基于该故障信息所确定并且意在防止该应用中的故障的故障防止处理。在第二示例性方面，一种服务器计算机，该服务器计算机部署在分布式系统中并且连接至能够执行相同应用的另一个服务器计算机，其中当该应用中出现故障时，该服务器计算机生成识别该应用中的故障的原因的故障信息，并且当所述另一服务器生成识别该应用中的故障的原因的故障信息时，该服务器计算机执行基于该故障信息所确定并且意在防止该应用中的故障的故障防止处理。在第三示例性方面，一种分布式管理服务器，该分布式管理服务器部署在包括能够执行相应应用的第一和第二服务器的分布式系统中，其中当该分布式管理服务器从该第一服务器接收到识别该第一服务器中的该应用中的故障的原因的故障信息时，该分布式管理服务器向该第二服务器传送该故障信息，该故障信息用作由该第二服务器用来执行防止该应用中的故障的故障防止处理的信息。在第四示例性方面，在包括能够执行相同应用的第一和第二服务器的分布式系统中，一种用于防止应用中的故障的故障防止方法，包括：当第一服务器中的应用中出现故障时，由该第一服务器生成识别应用中的故障的原因的故障信息，并且由第二服务器执行基于该故障信息所确定并且意在防止应用中的故障的故障防止处理。鉴于上文，可能提供一种能够防止服务器中的故障而并不增加系统操作人员的负担的分布式系统、服务器计算机、分布式管理服务器和故障防止方法。附图说明根据以下所给出的详细描述以及仅通过图示而给出并且因此不应被认为对本发明进行限制的附图，本发明的以上和其它目标、特征和优势将得到更为全面地理解。图1是示出根据第一实施例的分布式系统的第一示例配置的框图；图2是示出根据第一实施例的分布式系统的第二示例配置的框图；图3是示出根据第二实施例的分布式管理系统的示例配置的框图；图4A是示出根据第二实施例的由应用服务器所执行的处理示例的第一流程图；图4B是示出根据第二实施例的由应用服务器所执行的处理示例的第二流程图；图5是根据第二实施例的潜在故障存储单元中所存储的数据的概念图；图6是示出根据第二实施例的由分布式管理服务器所执行的处理示例的流程图；图7是根据第二实施例的存储在故障信息存储单元16中的数据示例的概念图；图8是示出根据第二实施例的由应用服务器所执行的监视处理示例的流程图；图9A是根据第二实施例的用于防止死锁故障的请求处理控制示例的概念图；图9B是根据现有技术的可能出现死锁故障的请求处理控制的概念图；图10A是示出根据第二实施例的故障信息存储单元16在时间t1所存储的数据示例的表格；图10B是示出根据第二实施例的故障信息存储单元16在时间t2所存储的数据示例的表格；图10C是示出根据第二实施例的故障信息存储单元16在时间t3所存储的数据示例的表格；图11A是根据第二实施例的用于防止过度存储器消耗故障的请求处理控制示例的概念图；图11B是根据现有技术的可能出现过度存储器消耗故障的请求处理控制的概念图；图12A是示出根据第二实施例的故障信息存储单元16在时间t4的数据示例的表格；图12B是示出根据第二实施例的故障信息存储单元16在时间t5的数据示例的表格；图12C是示出根据第二实施例的故障信息存储单元16在时间t6的数据示例的表格；图13A是根据第二实施例的用于防止过度CPU消耗的请求处理控制示例的概念图；和图13B是根据现有技术的可能出现过度CPU消耗故障的请求处理控制的概念图。具体实施方式第一实施例现在，将参考附图对本发明的第一实施例进行描述。图1是示出根据第一实施例的分布式系统1的示例配置的框图。分布式系统1包括都能够执行相同应用的服务器计算机2（第一服务器）和服务器计算机3（第二服务器）。分布式系统1例如是使用云计算的分布式系统。分布式系统1中所包括的服务器计算机的数量并不局限于两个并且可以是三个或更多。服务器计算机2和3以应用4和5可执行的方式存储有相同的应用，即应用4和5。当服务器计算机2所执行的应用4中出现故障时，服务器计算机2生成识别应用4中的故障的原因的故障信息。如这里所使用的，故障信息例如涉及已经针对应用4导致了故障的组件，或者与该组件相关联的接口。特别地，故障信息可以是接口或组件的数据，接口或组件的名称，等等。服务器计算机3执行故障防止处理，该故障防止处理基于服务器计算机2所生成的故障信息而确定并且意在防止应用5中的故障。例如，假设服务器计算机2中由于来自其客户端的请求而出现了故障，并且随后服务器计算机2生成了与该故障相关的故障信息。在这种情况下，服务器计算机3基于该故障信息而监视来自其客户端的请求，也就是说，执行故障防止处理。作为监视的示例，服务器计算机3确定服务器计算机的客户端是否请求了与来自客户端的针对服务器计算机2导致了故障的请求所请求的应用的功能相同的功能。如果服务器计算机3的客户端请求了相同功能，则服务器计算机3例如通过停止执行该功能而防止出现与服务器计算机2中相同的故障。通过执行如以上所描述的处理，分布式系统1能够防止服务器中的故障而系统操作人员无需执行一些处理（并不增加系统操作人员的负担）。修改形式1以上所描述的服务器计算机2可以进一步执行由服务器计算机3所执行的处理。特别地，当在应用4中出现故障时，服务器计算机2生成识别应用4中的故障的原因的故障信息。当服务器计算机3生成识别应用5中的故障的原因的故障信息时，服务器计算机2执行基于该故障信息所确定并且意在防止应用4中的故障的故障防止处理。类似地，服务器计算机3可以执行服务器计算机2所执行的处理。也就是说，每个服务器计算机能够在其中出现故障时生成故障信息，该故障信息对于另一服务器计算机执行故障防止处理而言是必需的，而且能够在另一服务器计算机生成故障信息时执行基于该故障信息的故障防止处理。通过在分布式系统1中包括这样的服务器计算机，可能更为有效地防止分布式系统1中的故障。修改形式2除了服务器计算机2和3之外，分布式系统1可以包括对分布式系统1进行管理的分布式管理服务器6。图2是示出如以上所描述的分布式系统1的示例配置的框图。在分布式系统1中，分布式管理服务器6连接至服务器计算机2和3。服务器计算机2和3与参考图1所描述的相类似。分布式管理服务器6从服务器计算机2接收识别服务器计算机2中所安装应用中的故障的原因的故障信息。分布式服务器6向服务器计算机3传送该故障信息，其作为服务器计算机3用来执行用于防止应用5中的故障的故障防止处理的信息。通过执行以上处理，分布式管理服务器6能够防止服务器计算机3中的故障。服务器计算机3所执行的故障防止处理的细节可以由服务器计算机3和分布式管理服务器6中的任一个基于故障信息来确定。第二实施例现在，将参考附图对本发明的第二实施例进行描述。图3是示出根据第二实施例的分布式管理系统10的示例配置的框图。分布式管理系统10包括应用服务器11A、11B和11C，分布式管理服务器27以及客户端应用34A、34B和34C。此后，应用服务器11A、11B和11C将共同被称作应用服务器11；客户端应用34A、34B和34C共同被称作客户端应用34。应用服务器11用作分布式管理系统10中的业务应用执行架构。应用服务器11例如包括由包括诸如CPU和存储器之类的资源的服务器计算机所执行的软件，以及在该软件的处理中所使用的服务器计算机的硬件。应用服务器11包括请求接收单元12、请求分析单元13、操作请求接收单元14、故障信息接收单元15、故障信息存储单元16、存储设备17、故障事件发布单元18和应用执行控制单元19。应用服务器11A、11B和11C分布在分布式管理系统10的网络上并且均具有相同的配置。应用服务器11A、11B和11C由不同计算机所执行。请求接收单元12接收系统用户使用客户端应用34所传送的请求。请求分析单元13对请求接收单元12所接收的请求的详细信息进行分析。操作请求接收单元14接收由分布式管理服务器27向应用服务器11所进行的针对操作管理的请求。故障信息接收单元15从分布式管理服务器27接收与另一应用服务器中已经出现的故障相关的信息。故障信息存储单元16在其内部存储器中存储故障信息接收单元15所接收的故障信息。存储设备17是以非瞬时的方式存储故障信息的存储设备，并且故障信息存储单元16在必要情况下将故障信息存储在存储设备17中。故障事件发布单元18向经由分布式管理服务器27连接至应用服务器11的其它应用服务器传送与应用服务器11中所安装的应用中已经出现的故障相关的信息。应用执行控制单元19对应用服务器11中所安装的应用的执行进行控制。应用执行控制单元包括执行管理单元20、故障监视单元21、故障识别单元22、故障分析单元23、潜在故障存储单元24、故障信息搜索单元25以及组件（应用组件）26A、26B和26C。此后，组件26A、26B和26C共同被称作组件26。执行管理单元20对应用执行控制单元19中进行操作的组件26的执行状态进行管理。特别地，执行管理单元20对指示应用正在被调用的信息或者关于目前正在被执行的请求以及关于执行该请求的线程的信息进行管理。故障监视单元21监视应用服务器11中所安装的应用中的故障。例如，故障监视单元21获取与处理的线程（线程转储）相关的信息或者诸如存储器使用和CPU使用的各种类型的资源信息的列表。故障识别单元22识别故障监视单元21所检测到的故障的细节。特别地，故障识别单元22从故障监视单元21所获取的各种类型的资源信息提取组件的标识符（组件名称）和组件接口的名称。故障分析单元23基于故障识别单元22通过识别所提取的信息而对所出现的故障进行详细分析或者执行与故障预测相关的计算。潜在故障存储单元24存储与故障分析单元23所预测的故障相关的信息。该信息由故障分析单元23进行更新。故障信息搜索单元25关于应用而针对故障信息搜索故障信息存储单元16。组件26形成实际安装于应用服务器11中的应用（以要由应用服务器的计算机可执行的方式存储的应用）。组件26具有在其上实施的业务逻辑。组件26在应用执行控制单元19上运行。应用服务器11A至11C具有安装于其上的相同应用并且因此包括相同的组件26A至26C。注意，组件26A至26C并不需要形成相同的应用。分布式管理服务器27是对分布式管理系统10的网络配置上所分布的应用服务器进行集中管理的专用服务器。系统管理员能够通过使用分布式管理服务器27来管理分布式管理系统10。分布式管理服务器27包括应用存储单元28、应用信息管理单元29、故障事件接收单元30、操作动作发布单元32和故障信息发布单元33。应用存储单元28存储与应用服务器11中所安装的应用相同的应用。应用信息管理单元29管理与应用服务器11中所安装的应用相关的详细信息（版本信息等）。故障事件接收单元30接收每个应用服务器的故障事件发布单元18所发布并且包括故障信息在内的事件。故障事件接收单元30包括事件分析单元31。事件分析单元31基于所接收的事件对应用服务器11中已经出现的故障的细节进行分析。操作动作发布单元32向处于管理之下的应用服务器11传送任意操作动作请求。故障信息发布单元33将特定应用服务器11的故障识别单元22所提取的故障信息传送至其管理之下的应用服务器11。客户端应用34是用于客户端的系统用户（客户端）用来调用应用服务器中所安装的应用的业务逻辑的应用。在图3中被示为执行各种处理的功能模块的应用服务器11和分布式管理服务器27的部件能够由CPU、存储器以及硬件形式的其它电路所形成；这些部件在软件方面例如由加载到存储器中的程序来实现。因此，本领域技术人员将要意识到的是，这些功能模块可以单独使用硬件、单独使用软件或者以各种形式的其组合来实现而并不局限于此。此后，将参考附图对根据第二实施例的分布式管理系统10的示例操作进行详细描述。首先，将对应用服务器11的基本处理的流程进行描述。应用服务器11经由请求接收单元12从诸如Web浏览器的客户端应用34接收请求。请求分析单元13对请求接收单元12所接收的请求进行分析以提取与该请求所要调用的组件26相关并且与该组件的接口（方法）相关的信息。请求分析单元13将作为参数的提取结果传送至应用执行控制单元19。应用执行控制单元19在执行管理单元20中存储指示应用正在被调用的信息并且随后使用所请求组件26的接口执行业务逻辑。当业务逻辑的执行完成时，应用执行控制单元19检测执行管理单元20中所存储的信息。这一系列处理由以请求为基础而运行应用服务器11的处理的线程来执行。另外，分布式管理服务器27对于分布式应用服务器11相关的基本信息（主机名称等）或者与应用服务器11中所安装的应用的配置相关的信息（应用名称、版本名称等）进行适当管理。应用服务器11之前以系统操作人员的操作工作为基础进行分布。此外，分布式管理服务器27能够指示其管理之下的所有应用服务器11执行应用的安装或更新，应用服务器的设置改变等。在根据第二实施例的应用服务器11关于故障检测而设置以下事项。1.检测到“死锁”时的恢复动作（恢复处理）该事项中规定了在应用被调用的同时检测到死锁时在应用服务器11上采取的恢复动作。在第二实施例中，恢复动作的选项至少包括“应用服务器重启”和“将应用降级至之前版本”。2.用于确定“过度存储器消耗”的存储器使用阈值该事项中设置了用于确定应用服务器11的存储器正在被过度消耗的存储器使用。当应用服务器11的实际存储器使用变得大于或等于该事项中所设置的数值时，应用服务器11确定存储器正在被过度消耗。3.用于在检测到“过度存储器消耗”时确定原因的频率阈值该事项中规定了用于在存储器被过度消耗时确定原因的组件名称和接口名称的条目频率（故障频率）。当组件名称和接口名称以大于或等于所规定频率的频率进行输入时，应用服务器11将所输入的组件名称和接口名称确定为过度存储器消耗的原因。4.在检测到“过度存储器消耗”时的恢复动作该事项包括在检测到过度存储器消耗时在应用服务器上所采取的恢复动作的选项。恢复动作选项至少包括“强制执行垃圾收集（GC）”和“将应用降级至先前版本”。5.用于确定“过度CPU消耗”的CPU使用阈值该事项中设置了用于确定应用服务器11的CPU正在被过度消耗的CPU使用。当应用服务器11的实际CPU使用变为大于或等于所设置的数值时，应用服务器11确定CPU正在被过度消耗。6.用于在检测到“CPU过度消耗”时确定原因的频率阈值该事项中规定了用于在检测到CPU正在被过度消耗时确定原因的组件名称和接口名称的输入频率。当组件名称和接口名称以大于或等于所规定频率的频率进行输入时，应用服务器11将组件名称和接口名称确定为过度CPU消耗的原因。7.在检测到“过度CPU消耗”时的恢复动作该事项中选择了在检测到过度CPU消耗时在应用服务器上所采取的恢复动作。恢复动作选项至少包括“改变处理优先级”和“将应用降级至之前版本”。以上事项被系统操作人员或者根据应用服务器11的规范而事先设置为适当数值（标准）。应用服务器11使用以下方法检测应用中的故障。例如，应用服务器11自身使用操作系统（OS）或程序的执行环境所提供的应用编程接口（API）定期监视资源的消耗状态或者故障的发生状态。可替换地，在故障的发生作为内部事件进行发布的执行环境中，应用服务器11的应用执行控制单元19通过接收这样的事件来检测故障。图4A和4B是示出应用服务器11所执行的处理示例的流程图。使用以上描述作为前提，以下将参考图4A和4B对应用服务器11在其中出现故障时执行的处理进行描述。当使用如以上所示出的方法在应用服务器11中检测到故障时，应用服务器11的故障监视单元21获取与处理线程相关的信息或者与资源相关的信息，诸如存储器使用或CPU使用（故障信息）（步骤S11）。使用故障识别单元22，应用执行控制单元19从故障监视单元21所获取的各种类型的资源信息识别所出现故障的类型（故障的原因）（步骤S12）。应用执行控制单元19确定故障识别单元22所识别的故障的类型是否是死锁或者正在处理的请求的数量是否为1（步骤S13）。应用执行控制单元19参考执行管理单元20中所存储的与当前正在执行的（多个）请求相关的信息来确定正在处理的请求的数量是否为1。当故障识别单元22所识别的故障类型为死锁时或者当正在处理的请求的数量为1时（步骤S13中的是），应用执行控制单元19从与线程堆栈相关的信息中提取其业务逻辑已经被调用的所怀疑组件的标识符（组件名称）及其接口名称。基于所提取的信息，应用执行控制单元19经由故障事件发布单元18向分布式管理服务器发布包括以下信息在内的故障事件（步骤S14）。·组件名称（标识符）·接口名称（方法名称）·故障类型（死锁、过度CPU消耗、过度存储器消耗等）·相关组件名称（标识符）·相关接口名称（方法名称）·恢复动作相关组件名称和相关接口名称表示其被认为导致了与其业务逻辑已经被调用的所怀疑组件及其接口相关的问题的组件及其接口。当正在处理的请求的数量为1时，仅其业务逻辑已经被调用的组件及其接口被描述为组件名称和接口名称，没有什么被描述为相关组件名称或相关接口名称。当故障识别单元22所识别的故障类型不是死锁并且当正在处理的请求的数量大于1时（步骤S13中的否），故障识别单元22对所获取的线程堆栈信息进行顺序分析。在分析中，故障识别单元22从线程堆栈信息提取组件标识符（故障组件的名称）及其接口的名称（步骤S15）。故障分析单元23通过以上标识基于故障识别单元22所提取的信息对故障进行分析（步骤S16）。故障识别单元22所提取的信息（步骤15）以及故障分析单元23所进行的故障分析（步骤S16）通过生成与正在被处理请求的数量相对应的循环而执行。参考图4B，将对故障分析单元23所执行的故障分析（步骤S16）进行详细描述。在故障分析中，故障分析单元23检查由故障识别单元22所提取的一对组件名称和接口名称所组成的数据是否已经作为潜在故障存储单元24中的潜在数据而被输入（存在）（步骤S17）。如果这样的数据已经作为潜在故障存储单元24中的潜在数据被输入（步骤S17中的是），则故障分析单元23从潜在故障存储单元24获取该数据（步骤S18）。如果这样的数据还没有作为潜在故障存储单元24中的潜在数据被输入（步骤S17中的否），则故障分析单元23通过使用组件标识符和接口名称作为关键字生成作为新的故障原因的条目（潜在数据）（步骤S19）。此时，故障分析单元23依据所检测的故障类型在该条目中存储参数，诸如用于故障检测的事项中所规定的阈值或恢复动作。在步骤S18和S19中的任一个中，故障分析单元23将故障识别单元22所提取的组件名称和接口名称的故障频率加1（步骤S20）。注意，步骤S20的处理可以与步骤S18或步骤S19同时执行或者在它们之前执行。图5是潜在故障存储单元24中所存储的数据的概念图。在潜在故障存储单元24中，故障类型、频率、阈值和恢复动作与组件名称及其接口名称相关联地进行存储。如这里所使用的，频率是指在故障监视单元21在组件的接口被调用时检测到一些故障的情况下，故障监视单元21已经作为故障的潜在原因而输入的组件名称和接口名称的频率。如以上所描述的，图5中的阈值是指用于确定出现了对应于该阈值的故障的标准。例如，如果应用中故障的类型是过度存储器消耗、CPU负载等，则故障分析单元23难以确定并行运行的多个应用线程中的哪一个是直接原因。在这种情况下，需要使用统计数值和标准来确定故障的源位置。该阈值被用作用于确定源位置的信息。图5示出了已经在组件D和接口Dm中已经出现过一次“过度存储器消耗”并且对应于“过度存储器消耗”的阈值和恢复动作分别为三次和“强制GC”。图5还示出了“过度CPU消耗”已经在组件H和接口Hm中已经出现过两次并且对应于“过度存储器消耗”的阈值和恢复动作分别为三次和“改变处理优先级”。故障分析单元23参考潜在故障存储单元24中所存储的数据以在组件名称和接口名称的故障频率和相对应阈值之间进行比较。故障分析单元23随后确定是否有大于或等于阈值的故障频率（步骤S21）。如果用作确定该故障的标准的频率已经达到（或超过）了阈值（步骤S21中的是），则故障分析单元23将相对应组件的调用确定（识别）为故障的原因。使用该信息，故障分析单元23开始用于向分布式管理服务器27发布故障事件的处理。该事件的细节如以上所描述。所要发布的故障事件中所包括的组件名称和接口名称是被故障分析单元23确定为故障原因的组件（第一组件）和接口（第一接口）的名称。此时，除了被确定为故障原因的条目（其已经达到或超过了阈值）之外，故障分析单元23提取与此时还没有达到阈值但是具有最高频率的条目（具有第二最高故障频率的条目）相关的组件（第二组件）和接口（第二接口）（步骤S22）。该潜在故障的线程处理要受到控制。除了被确定为故障原因的条目之外还提取具有最高频率的条目作为潜在故障的原因是为了获取可能导致故障的应用组件之间的关系。在过度CPU消耗的情况下，其原因可能不是特定组件的接口调用而是多个组件的接口调用之间的重叠。甚至在需要在被调用时执行复杂处理并且明显消耗CPU的逻辑的情况下，过度CPU消耗也并不在其负载在该接口被单独调用时落入业务系统正常运行的可允许范围之内（虽然可能临时增加）的接口被单独调用的情况下出现。然而，当多个这样的接口的调用相互重叠时，将会出现过度CPU消耗。注意，即使在多个接口的调用相互重叠时，是否出现故障也取决于应用的配置、应用服务器的机器规范等。出于该原因，通过在业务系统运行时获取如以上所描述的关系，可能更为准确地检测到潜在故障并且防止故障出现。这不仅应用于过度CPU消耗而且也应用于过度存储器消耗。可能存在均具有达到或超出阈值的故障频率的多个组件。如果组件的接口在故障分析单元23确定另一个组件的故障频率已经达到或超出阈值时已经达到或超出了阈值，则如以上所描述的，故障分析单元23还可以在步骤S22提取其它组件（第二组件）及其接口（第二接口）作为潜在故障。如以上所看到的，故障分析单元23所提取的潜在故障的数量并不局限于一个而可以为两个或更多个。另外，当关于特定组件及其接口的过度CPU消耗的故障频率达到或超出阈值时，关于另一个组件及其接口的过度存储器消耗的故障频率可能达到或超出阈值。在这样的情况下，其中已经出现了过度存储器消耗的其它组件（第二组件）及其接口（第二接口）在步骤S22在中被提取作为潜在故障。与之相比，当关于组件及其接口的过度存储器消耗的故障频率达到或超出阈值时，关于另一组件及其接口的过度CPU消耗的故障频率可能达到或超出阈值。在这样的情况下，其中已经出现了过度CPU消耗的其它组件（第二组件）及其接口（第二接口）在步骤S22在中被提取作为潜在故障。注意，在步骤S22中被提取作为潜在故障的组件（第二组件）可能与被故障分析单元23确定为故障原因的组件（第一组件）不同或相同。注意，被故障分析单元23确定为故障原因的接口（第一接口）不同于由此被提取作为潜在故障的接口（第二接口）。故障信息事件发布单元28将步骤S22中所提取的潜在故障作为关于相关组件名称和相关接口名称的信息（相关信息）包括在故障事件中，并且随后发布该故障事件（步骤S23）。在故障事件发布之后，故障分析单元23从潜在故障存储单元24删除与条目相关的数据（潜在数据）。如果条目的频率低于阈值（步骤S21中的否），则故障分析单元23确定数据不足以确定该条目为故障原因并且避免开始发布故障事件的处理。故障分析单元23更新潜在故障存储单元24中的条目数据（潜在数据）（步骤S25）。经更新的信息经由故障信息存储单元16而存储在存储设备17中。由于以上处理，潜在故障存储单元24中所累加的条目信息被每个应用服务器11持续保存直至所怀疑的组件26被更新或删除。因此，当应用服务器11启动时，存储设备17中以非瞬时方式存储的与潜在故障相关的数据被读取并再次存储在潜在故障存储单元24中。图6是示出分布式管理服务器27所执行的处理示例的流程图。参考图6，将对分布式管理服务器27在应用服务器11基于以上处理向分布式管理服务器27发布故障事件时所执行的处理进行描述。首先，分布式管理服务器27经由故障事件接收单元30从应用服务器11接收故障事件并且随后使用故障分析单元31对其进行分析（步骤S31）。故障分析单元31确定要对该故障采取的恢复动作是否被包括（定义）在所接收的故障事件中（步骤S32）。如果要对该故障采取的恢复动作包括在故障事件中（步骤S32中的是），则操作动作发布单元32基于故障事件中所包括的恢复动作的细节向故障应用服务器11A发出恢复动作请求。依据所发出的恢复动作请求，应用服务器11A采取恢复动作（恢复处理）（步骤S33）。因此，应用服务器11A能够从故障中恢复。分布式管理服务器27确定要对故障采取的恢复动作是否为将应用降级至之前版本（步骤S34）。如果恢复动作是将应用降级至之前版本（步骤S34中的是），则分布式管理服务器27更新与应用信息管理单元29中所存储的所安装应用的版本相关的信息（步骤S35）。因此，分布式管理服务器27将关于其中的应用版本的信息与关于应用服务器11中的应用版本的信息相匹配。如果恢复动作不是降级（步骤S34中的否），则分布式管理服务器27基于事件分析单元31所提取应用的组件标识符和接口名称经由故障信息发布单元33向其控制之下的所有应用服务器11传送新的故障信息（步骤S36）。分布式管理服务器27所传送的信息如下：·组件名称（标识符）·接口名称（方法名称）·故障类型（死锁、过度CPU消耗、过度存储器消耗等）·相关组件名称（标识符）·相关接口名称（方法名称）注意，故障信息发布处理（步骤S36）通过生成与所要管理的应用服务器11的数量相对应的循环而执行。每个应用服务器11的故障信息接收单元15接收故障信息发布单元33所发布的故障信息。应用服务器11将所接收的故障信息存储在故障信息存储单元16中并随后存储在存储设备17中。应用服务器11还立即开始监视从系统用户所传送的请求。注意，步骤S33的处理可以与步骤S34同时执行或者在其后执行。另外，步骤S33的处理可以与步骤S35同时执行或在其后执行，或者与步骤S36同时执行或在其后执行。图7是故障信息存储单元16中所存储的数据示例的概念图。在图7中，故障类型以及相关组件名称和相关接口名称（相关信息）与组件名称和接口名称相关联地进行存储。图7示出了在组件A和接口Am中出现了“死锁”故障，并且与该故障相关的组件和接口为组件B和接口Bm。图7还示出了在组件B和接口Bm中出现了“死锁”故障，并且与该故障相关的组件和接口为组件A和接口Am。图7还示出了在组件D和接口Dm出现了“过度存储器消耗”故障以及在组件H和接口Hm中出现了“过度CPU消耗”故障。图8是示出应用服务器11基于所接收的故障信息而执行的监视处理示例的流程图。现在参考图8，将对应用服务器11所执行的监视进行描述。在开始监视之后，应用服务器11的应用执行控制单元19经由请求接收单元接收关于来自系统用户的请求的请求（针对请求的请求）（步骤S41）。使用故障信息搜索单元25，应用执行控制单元19确定与系统用户所请求的组件的接口相关的故障信息是否以组件名称和接口名称的形式存储在故障信息存储单元16中（步骤S42）。如果故障信息被存储（步骤S42中的是），则应用执行控制单元19参考与涉及该故障信息中所请求组件的接口的应用的接口相关的信息（步骤S43）。应用执行控制单元19随后确定故障信息是否包括与相关应用的接口相关的信息（步骤S44）。如这里所使用的，相关应用是指包括故障信息中所包括的“相关组件”的应用。如果故障信息包括与相关应用的接口相关的信息（也就是与故障信息中的“相关接口”相关的信息）（步骤S44中的是），则应用执行控制单元19确定对应于该接口信息的请求（相关请求）是否被对针对请求的请求进行处理的线程以外的线程正在执行（步骤S45）。应用执行控制单元19基于执行管理单元20所保存的信息进行该确定。如果应用执行控制单元19能够确认相关请求由另一线程正在执行（步骤S45中的是），则其暂停后续请求（针对请求的请求）的执行直至其它线程所进行的执行完成（步骤S47）。在过去预定时间之后，应用执行控制单元19再次确定相关请求是否正在由另一线程所执行（步骤S45）。如果相关请求并未由另一线程正在执行（步骤S45中的否），则应用执行控制单元19使得线程处理后续请求（步骤S49）。也就是说，应用执行控制单元19执行该请求。如果应用执行控制单元19在之前的步骤S47中暂停后续请求的执行，则其使得线程继续处理被暂停的请求。如果故障信息并不包括与步骤S44中的相关组件的接口相关的信息（步骤S44中的否），则应用执行控制单元19执行以下处理。应用执行控制单元19基于执行管理单元20所保存的信息来确定针对故障组件的接口的请求（相同请求）是否被对针对请求的请求进行处理的线程以外的线程所执行（步骤S46）。如果相同请求由另一线程正在执行（步骤S46中的是），则应用执行控制单元19暂停后续请求的执行直至其它线程的执行完成（步骤S48）。在过去预定时间之后，应用执行控制单元19再次确定相同请求是否由另一线程正在执行（步骤S46）。如果相同请求并未由另一线程正在执行（步骤S46中的否），则应用执行控制单元19使得线程处理该相同请求（步骤S49）。也就是说，应用执行控制单元19执行该请求。如果应用执行控制单元19在步骤S48暂停后续请求的执行，则其使得线程继续对所暂停的请求进行处理。注意，在步骤S47和S48中的暂停处理中，应用执行控制单元19可以在过去预定时间之后确定处理已经超时并且向调用方返回适当错误，结束图8的处理。应用执行控制单元19例如基于系统操作人员或应用服务器11所规定的参数来执行该处理。如果应用服务器11A中出现的故障是死锁，则应用服务器11B并不需要执行任何步骤S46至S48中的处理。死锁故障在与请求相关的组件的接口和另一组件的接口同时相互进行互斥控制时出现。因此，如果与请求相关的组件的接口已经被执行，则认为不会出现死锁故障。注意，如果相关请求并未由另一线程正在执行（步骤S45中的否），则应用执行控制单元19可以执行步骤S46的处理。基于步骤S46中的确定的分歧如以上所描述。以上监视由每个应用服务器11连续执行直至对象应用被更新。因此，如果应用服务器11在进行这样的更新之前被重启，则故障信息存储单元16的存储器上的故障信息将会丢失。出于该原因，当应用服务器11被重启时，从存储设备17读取以非瞬时方式存储的故障信息。所读取的故障信息再次被应用执行控制单元19存储在故障信息存储单元16中。此后，假设具体情形，将进一步对图4、6和8的处理进行描述。<在出现死锁时>假设以下情形，在业务系统在特定应用服务器11A中运行时，由于应用缺陷而在并行处理多个请求的线程之间出现了死锁。已经在应用服务器11中导致死锁的应用的组件由A和B所表示，并且其调用接口由Am和Bm所表示。重启应用服务器被预先定义为在出现死锁时采取的恢复动作。当应用服务器11A中出现死锁时，应用服务器11A中的故障监视单元21关于对已经导致死锁的请求进行处理的线程而获取堆栈信息（包括线程调用的流程的信息）。基于所获取的信息，应用服务器11A向分布式管理服务器27发布故障事件。该故障事件包括含有被故障识别单元22识别为死锁来源（故障原因）的应用的组件名称（A）和接口名称（Am），对应于组件名称（A）和接口名称（Am）的相关组件名称（B）和相关接口名称（Bm）以及故障类型“死锁”的信息，以及含有被识别为死锁来源（故障原因）的应用的组件名称（B）和接口名称（Bm），对应于组件名称（B）和接口名称（Bm）的相关组件名称（A）和相关接口名称（Am）以及故障类型“死锁”的信息。这里所识别的恢复动作是“重启服务器”。分布式管理服务器27接收该故障事件，并且通过事件分析单元31所进行的分析而提取指示已经在组件A和B的接口Am和Bm之间出现了死锁并且其中重启服务器被预定义为恢复动作的故障信息。分布式管理服务器27重启故障应用服务器11A并且随后将该故障信息传送至其管理之下的所有应用服务器11。该故障信息包括组件名称组件A和B以及接口名称接口Am和Bm。应用服务器11B接收该故障信息并且将它存储在其故障信息存储单元16中，而且立即开始监视请求。应用服务器11B随后使用请求接收单元12对从客户端34所输出并且意在调用应用的组件A的接口Am的请求进行处理。请求接收单元12将该请求传输至应用执行控制单元19。此时，应用执行控制单元19的故障信息搜索单元25确认组件A的接口信息Am出现在故障信息存储单元16中。在该确认之后，应用执行控制单元19针对于相关组件B的相关接口Bm的调用是否已经由于被另一线程正在执行而被管理而询问执行管理单元20。如果接口Bm的调用正在被另一线程所执行，则应用执行控制单元19暂停用于调用组件A的接口Am的处理直至其它线程所进行的处理完成。在组件B的接口Bm的调用完成之后，应用执行控制单元19释放被暂停的组件A的接口Am的调用以继续进行处理。图9A是用于防止以上所描述的死锁故障的请求处理控制示例的概念图。在应用服务器11B中，针对组件A的接口Am所进行的请求在针对组件B的接口Bm的请求的处理线程的执行期间到达应用执行控制单元19。当针对组件A的接口Am的请求的处理线程被执行时，针对组件C的接口Cm1进行请求。另一方面，当针对组件B的接口Bm的请求的处理线程被执行时，针对组件C的接口Cm2进行请求。此时，两个接口（方法）会进行互斥控制。根据处理执行的时间，会在接口Cm1和Cm2之间出现死锁。在以上处理中，针对组件A的接口Am的请求的执行被暂停直至针对组件B的接口Bm的请求完成。这防止了两个接口进行互斥控制，允许接口Cm1在接口Cm2被执行之后执行。换句话说，接口Cm1和Cm2在不同时间执行。结果，死锁能够被避免。图9B是（根据现有技术的）可能出现死锁故障的请求处理控制的概念图。图9B示出了以下情形，其中针对组件A的接口Am的请求的执行并未被暂停，因此接口Cm1和Cm2同时进行互斥控制，导致了其间的死锁。不仅应用服务器11B，应用服务器11C也接收该故障信息并执行类似处理。虽然以上已经对不同组件A和B的接口之间出现死锁的情形进行了描述，但是死锁可能在相同组件的不同接口之间出现。例如，可能存在以下情形，其中在执行针对组件A的接口Am1的请求的处理线程时，针对共用组件C的接口Cm1进行请求；在执行针对组件A的接口Am2的请求的处理线程时，针对共用组件C的接口Cm2进行请求。此时，两个接口Am1和Am2进行互斥控制。根据处理的时间，处理会以重叠方式（同时）进行互斥控制的方式而进行，这根据与图9B类似的原则而导致死锁。如以上所看到的，虽然线程对相同组件A的不同接口Am1和Am2进行处理，但是可能在共用组件C上进行不同的互斥控制。当在应用服务器11A中出现死锁时，应用服务器11基于故障监视单元21所获取的信息而向分布式管理服务器27发布故障事件。该故障事件包括含有被故障识别单元22识别为死锁源（故障原因）的应用的组件名称（A）和接口名称（Am1），与该组件名称（A）和接口名称（Am1）相对应的相关组件名称（A）和相关接口名称（Am2），以及故障类型“死锁”的信息，以及含有被识别为死锁源的应用的组件名称（A）和接口名称（Am2），与该组件名称（A）和接口名称（Am2）相对应的相关组件名称（A）和相关接口名称（Am1），以及故障类型“死锁”的信息。依据所发布的故障事件，分布式管理服务器27向应用服务器11B传送故障信息。应用服务器11B执行与参考图9A所描述的相类似的用于防止死锁故障的处请求处理控制。例如，当由客户端应用34进行用于调用接口Am1的请求时并且当已经由另一线程正在执行接口Am2的调用时，应用执行控制单元19暂停用于调用接口Am1的处理直至其它线程所进行的处理完成。在调用接口Am2的处理完成之后，应用执行控制单元19释放被暂停的接口Am1的调用以继续处理。<在存储器过度消耗时>此后，将使用另一个具体示例对图4、6和8的处理进一步进行描述。假设其中存储器在系统操作期间由于特定应用服务器11A中的应用的缺陷而被过度消耗的情形。在以下所描述中，在应用服务器11中，过度消耗存储器的应用组件由A表示，其接口由Am表示，而其它组件由B至E表示，其接口由Bm至Em表示。假设在故障信息存储单元16中所存储的数据中，用于将组件确定为故障原因的频率阈值为“3”并且所设置的恢复动作为“强制GC”。当存储器在时间t1在应用服务器11A中被过度消耗时，故障监视单元21关于对请求进行处理的线程而获取堆栈信息。使用故障识别单元22，应用执行控制单元19从所获取的信息识别故障应用的组件名称和接口名称。假设获取了以下信息。[组件名称：接口名称]A:Am，C:Cm，E:Em（此后，将类似地表示组件以及与之相对应的接口）。此时，故障分析单元23将条目信息新存储在故障信息存储单元16中。每个条目的频率被认为是1。图10A是示出故障信息存储单元16在时间t1所存储数据的示例的表格。故障信息存储单元16中所存储的数据指示故障“过度CPU消耗”已经在A:Am，C:Cm和E:Em中的每一个中出现了一次。所存储的数据还示出每个频率的阈值为“3”并且每个回复动作为“强制GC”。条目:Am，C:Cm和E:Em的任意频率还没有达到相对应的阈值。出于该原因，该故障事件发布单元18并不发布故障事件。随后，存储器在时间t2再次在应用服务器11A中被过度消耗。假设故障识别单元22获取了以下信息。[组件名称：接口名称]A:Am，B:Bm，C:Cm此时，故障分析单元23执行与以上所描述相类似的处理并且将条目添加至故障信息存储单元16中所存储的数据以更新数据。图10B是示出故障信息存储单元16在时间t2所存储数据的示例的表格。故障信息存储单元16中所存储的数据指示故障“过度存储器消耗”已经在A:Am中出现两次，在B:Bm中出现一次，在C:Cm出现两次，以及在E:Em中出现一次。A:Am和C:Cm的故障频率均为2但是还没有达到相对应阈值。因此，故障事件发布单元18并不发布故障事件。随后，存储器在时间t3再次在应用服务器11A中被过度消耗。假设故障识别单元22获取了以下信息。[组件名称：接口名称]A:Am，D:Dm，E:Em此时，故障分析单元23执行与以上所描述相类似的处理并且将条目添加至故障信息存储单元16中所存储的数据以更新数据。图10C是示出是示出故障信息存储单元16在时间t3所存储数据的示例的表格。故障信息存储单元16中所存储的数据指示故障“过度存储器消耗”已经在A:Am中出现三次，在B:Bm中出现一次，在C:Cm出现两次，在D:Dm中出现一次，以及在E:Em中出现两次。此时，A:Am的故障频率达到3，也就是说，达到了阈值。出于该原因，故障分析单元23确定A:Am是与过度存储器消耗相关联的故障的原因。故障分析单元23将A:Am之后具有最高频率的C:Cm和E:Em视为关于作为故障原因的A:Am的相关组件和相关接口（相关信息）。故障事件发布单元18向分布式管理服务器27发布故障事件，其指示作为故障原因的组件名称和接口名称（A:Am）以及相关组件名称和相关接口名称（C:Cm和E:Em）。后续处理，也就是由分布式管理服务器27所进行的恢复动作的执行和向应用服务器11发布故障信息，以及每个应用服务器11在接收到该故障信息之后执行的处理和请求处理线程执行控制如以上所描述。图11A是用于防止以上所描述的过度存储器消耗的请求处理控制示例的概念图。在图11A中，针对组件A的接口Am所进行的多个请求到达应用服务器11B中的应用执行控制单元19。如果组件A的接口Am是过度消耗存储器的接口，则由多个请求进行的对接口Am的调用会导致存储器短缺。出于该原因，应用服务器11B暂停后续对组件A的接口Am所进行的请求的执行直至对组件A的接口Am较早进行的（之前）请求完成。这防止了在应用服务器11B中正在进行基于多个请求的调用，允许避免存储器短缺。换句话说，应用服务器11B执行控制以使得组件A的接口Am不会同时被多个线程所执行。注意，故障信息可以指示组件C的接口Cm是组件A的接口Am之后具有（第二）最高频率的潜在故障，并且在应用服务器11B中，接口Cm被正在执行接口Am的线程以外的线程正在执行。在这种情况下，应用服务器11B暂停组件A的接口Am的执行直至接口Cm的执行完成。此外，应用服务器11B可以暂停组件C的接口Cm的执行直至接口Am的执行完成。由于应用服务器11B以这种方式执行控制，所以可能防止多个组件的接口调用并导致故障。甚至在已经达到或超出阈值的组件接口被记录为潜在故障时或者甚至在其关于CPU过度消耗的故障频率已经达到或超出阈值的组件接口被记录为潜在故障时，应用服务器11B也能够执行类似控制。注意，相同组件A的不同接口Am2可以被描述为组件A的接口Am之后具有最高频率的潜在故障。在这种情况下，如果接口Am2被正在执行接口Am的线程以外的线程正在执行，则应用服务器11B暂停接口Am的执行直至接口Am2的执行完成。图11B是根据现有技术的其中可能出现过度存储器消耗的请求处理控制的概念图。在图11B中，针对组件A的接口Am进行了多个请求并且随后均调用接口Am，这导致存储器短缺的故障。<在CPU过度消耗时>此后，将使用又另一个具体示例对图4、6和8的处理进一步进行描述。假设其中CPU在系统操作期间由于特定应用服务器11A中的应用的缺陷而被过度消耗的情形。在以下所描述中，在应用服务器11中，过度消耗CPU的应用组件由A表示，其接口由Am表示，而其它组件由B至E表示，其接口由Bm至Em表示。假设在故障信息存储单元16中所存储的数据中，用于将组件确定为故障原因的频率阈值为“3”并且所设置的恢复动作为“强制GC”。当CPU在时间t4在应用服务器11A中被过度消耗时，故障监视单元21关于对请求进行处理的线程而获取堆栈信息。从所获取的信息，应用执行控制单元19使用故障识别单元22识别故障应用的组件名称和接口名称。假设获取了以下信息。[组件名称：接口名称]A:Am，C:Cm，E:Em（此后，将类似地表示组件以及与之相对应的接口）。此时，故障分析单元23将每个条目信息存储在故障信息存储单元16中。每个条目的频率被认为是1。图12A是示出在时间t4故障信息存储单元16中数据的示例的表格。故障信息存储单元16中所存储的数据指示故障“过度CPU消耗”已经在A:Am，C:Cm和E:Em中的每一个中出现了一次。所存储的数据还示出每个频率的阈值为“3”并且每个回复动作为“强制GC”。条目:Am，C:Cm和E:Em的任意频率还没有达到相对应的阈值。出于该原因，该故障事件发布单元18并不发布故障事件。随后，CPU在时间t5再次在应用服务器11A中被过度消耗。假设故障识别单元22获取了以下信息。[组件名称：接口名称]A:Am，B:Bm，C:Cm此时，故障分析单元23执行与以上所描述相类似的处理并且将条目添加至故障信息存储单元16中所存储的数据以更新数据。图12B是示在时间t5出故障信息存储单元16中数据的示例的表格。故障信息存储单元16中所存储的数据指示故障“过度CPU消耗”已经在A:Am中出现两次，在B:Bm中出现一次，在C:Cm出现两次，以及在E:Em中出现一次。A:Am和C:Cm的故障频率均为2但是还没有达到相对应阈值。因此，故障事件发布单元18并不发布故障事件。随后，CPU在时间t6再次在应用服务器11A中被过度消耗。假设故障识别单元22获取了以下信息。[组件名称：接口名称]A:Am，D:Dm，E:Em此时，故障分析单元23执行与以上所描述相类似的处理并且将条目添加至故障信息存储单元16中所存储的数据以更新数据。图12C是示出在时间t6故障信息存储单元16中数据的示例的表格。故障信息存储单元16中所存储的数据指示故障“过度CPU消耗”已经在A:Am中出现三次，在B:Bm中出现一次，在C:Cm出现两次，在D:Dm中出现一次，以及在E:Em中出现两次。此时，A:Am的故障频率达到3，也就是说，达到了阈值。出于该原因，故障分析单元23确定A:Am是与过度CPU消耗相关联的故障的原因。故障分析单元23将具有第二最高频率的C:Cm和E:Em视为关于作为故障原因的A:Am的相关组件和相关接口。故障事件发布单元18向分布式管理服务器27发布故障事件，其指示作为故障原因的组件名称和接口名称（A:Am）以及相关组件名称和相关接口名称（C:Cm和E:Em）。后续处理，也就是由分布式管理服务器27所进行的恢复动作的执行和向应用服务器11发布故障信息，以及每个应用服务器11在接收到该故障信息之后执行的处理和请求处理线程执行控制如以上所描述。图13A是用于防止以上所描述的过度CPU消耗的请求处理控制示例的概念图。在图13A中，针对组件A的接口Am所进行的多个请求到达应用服务器11A中的应用执行控制单元19。如果组件A的接口Am是过度消耗CPU的接口，则基于多个请求的接口Am调用会导致另一请求的处理延迟，等等。应用服务器11B暂停后续对组件A的接口Am所进行的请求的执行直至对组件A的接口Am较早进行的请求完成。这防止了在应用服务器11B中进行基于多个请求的调用，允许避免另一请求的处理延迟等。换句话说，应用服务器11B执行控制以使得组件A的接口Am不会同时被多个线程所执行。注意，故障信息可以指示组件C的接口Cm是组件A的接口Am之后具有（第二）最高频率的潜在故障，并且在应用服务器11B中，接口Cm正在被执行接口Am的线程以外的线程正在执行。在这种情况下，应用服务器11B暂停组件A的接口Am的执行直至接口Cm的执行完成。由于应用服务器11B以这种方式执行控制，所以可能防止多个组件的接口调用并导致故障。甚至在已经达到或超出阈值的组件接口被记录为潜在故障时或者甚至在其关于存储器过度消耗的故障频率已经达到或超出阈值的组件接口被记录为潜在故障时，应用服务器11B也能够执行类似控制。注意，相同组件A的不同接口Am2可以被描述为组件A的接口Am之后具有最高频率的潜在故障。在这种情况下，如果接口Am2被正在执行接口Am的线程以外的线程正在执行，则应用服务器11B暂停接口Am的执行直至接口Am2的执行完成。此外，应用服务器11B可以暂停组件A的接口Am2的执行直至接口Am的执行完成。图13B是根据现有技术的其中可能出现过度存储器消耗的请求处理控制的概念图。在图13B中，针对组件A的接口Am进行了多个请求并且随后均调用接口Am，这导致了另一请求处理的延迟等。对以上所描述的根据第二实施例的分布式管理系统10中的处理进行了概述。其中已经出现故障的应用服务器对有关诸如存储器、线程或CPU的资源的信息进行分析并且以组件或接口为基础识别或预测应用故障的原因。因此，在应对可能影响整个系统的应用故障时，系统操作人员并不需要识别故障的原因（或者进行统计预测），这样系统操作人员的负担被减少。故障应用服务器随后将分析结果传送至具有相同配置的其它应用服务器以便与其它应用服务器共享故障信息。其它应用服务器接收故障应用服务器所传送的故障信息并且对故障信息进行累加以便防止与故障应用服务器中已经出现的故障相类似的故障。依据所累加的故障信息，应用服务器对针对应用的请求进行分析，而且控制请求执行的顺序或时间。根据第二实施例的分布式管理系统10的效果如下。首先包括分布的多个应用服务器的系统能够防止由应用中的缺陷所导致并且会影响到整个系统的故障。其原因在于，由于与应用中的缺陷相关的故障信息被传送至其它应用服务器，所以已经接收到所传送故障信息的应用服务器能够对应用的执行进行控制以使得不会在应用服务器中出现相同故障。诸如死锁或存储器故障之类的应用故障经常基于特定处理模式而出现。出于该原因，如果应用服务器对模式进行分析并且预先控制应用调用以使得该处理模式不会出现，则可能稳定运行整个分布式管理系统。换句话说，应用服务器能够执行特定于与另一应用服务器中已经出现并且在未来可能出现的故障相类似的故障位置的监视和过程。在执行该监视和过程时，应用服务器对针对应用的请求的执行顺序或时间进行控制。第二效果是能够减少系统操作人员的负担。其原因在于，分布式管理系统10能够在不涉及系统操作人员所进行的操作的情况下自动针对故障采取（例如，临时）措施。典型地，针对由应用中的缺陷所导致的故障的基本解决方案需要应用程序的修改。也就是说，在所有应用服务器上运行的组件被更新之前，故障会再次出现。应用程序的修改、修改程序的测试以及应用服务器上组件的更新都需要一定的时间周期。出于该原因，当在系统在组件更新之前必须不可避免地继续运行的情况下出现类似故障时，必须采取一些临时措施，包括由系统操作人员重启应用服务器。在这种情况下，随着应用服务器数量的增加，更可能在应用中出现故障。因此，系统操作人员更可能承担过多的工作负担。然而，根据第二实施例的分布式管理系统10替代系统操作人员对应用的执行进行控制以使得应用服务器自身防止故障的重新出现。结果，无论应用服务器的数量如何，系统操作人员都无需采取这样的措施。近年来，使用云计算技术的系统模型已经越来越多地得以被构建。大多数这样的系统包括分布在许多网络上的大量服务器机器。用作服务器机器的应用服务器经常具有相同的配置。由于大多数这样的系统具有负载分布配置，所以单个服务器中（由故障等所导致的）异常较不可能影响到整个系统（也就是说，较不可能使得整个系统瘫痪）。然而，如果在每个应用服务器上运行的业务应用自身存在缺陷，则由单个应用服务器中的这一错误所导致的故障可能会导致在不久的将来在其它应用服务器中连续出现类似故障。结果，该故障会降低整个系统的性能或者影响到其非工作时间。另外，该故障会导致关于系统的服务级别契约（SLA）的质量问题，等等。在这种情况下，除非已经采取了措施，否则系统操作人员必须不可避免地采取临时措施，诸如将故障应用降级至之前的版本。另外，随着服务数量的增加，这样的故障更可能出现，这导致采取临时措施的操作成本的增加。然而，如以上所描述的，应用中的缺陷经常基于特定处理模式而出现。出于该原因，如果应用服务器对该模式进行分析并且事先控制应用的调用以使得故障模式不会出现，则系统可能更为稳定地运行。另一方面，应用从错误中恢复几乎都需要足够的评估周期以及足够的操作成本以便不会导致类似问题。鉴于上文，在使用包含故障的应用的同时，如果可能，似乎有必要构建一种执行控制以使得系统能够尽可能稳定运行而不会对系统操作人员增加负担的机制。在这种情况下，似乎重要的是，系统即使在处理性能在一定程度上有所衰退的情况下也能够尽可能稳定地运行。这是因为可能实现防止与操作成本增加以及在故障被根本解决之前可能发生的系统无操作相关联的经济损失的重要目标。如以上所描述的，日本未审专利申请公开号2010-9127和2006-338069并没有考虑到诸如应用服务器的多个服务器部署为云计算的情形。特别地，根据日本未审专利申请公开号2010-9127的系统基于唯一确定标准累加故障信息并且将基于确定标准所检测的故障信息传送至专用管理员终端。然而，日本未审专利申请公开号2010-9127并没有考虑到其中分布有应用服务器等的环境。另一方面，根据第二实施例的分布式管理系统具有向分布式环境传送故障信息并且基于该故障信息防止故障的机制。对于根据日本未审专利申请公开号2006-338069的系统而言，在系统基于唯一确定标准预测或检测到故障信息时，其对组件进行替换以防止整个系统瘫痪。然而，该处理假设存在着运行的可替换组件。换句话说，除非存在这样的组件，否则就不可能获得防止整个系统瘫痪的效果。另一方面，根据第二实施例的分布式系统10并不需要考虑组件的替换。即使应用的组件包含缺陷，该分布式管理系统也能够通过识别该缺陷来控制应用的操作，以及以并不出现系统故障的方式最大程度地对组件加以利用。根据第二实施例的分布式管理系统还产生以下效果。当应用中出现故障时，应用服务器11A生成包括识别应用服务器11A从故障恢复所必需的恢复动作（恢复处理）的信息在内的故障事件（故障信息）。分布式管理服务器27从应用服务器11A所发布的故障事件中提取识别恢复动作的信息并且将该信息传送至应用服务器11A。基于分布式管理服务器27所传送的识别恢复动作的信息，应用服务器11A执行故障恢复动作。因此，即使在出现故障时应用服务器11A无法自己执行故障恢复动作的情况下，其也能够通过执行基于来自分布式管理服务器27的请求的处理而执行故障恢复动作。另外，即使在出现故障时，系统操作人员也无需在每个应用服务器11中执行恢复动作的控制，并且分布式管理服务器27能够控制恢复动作。因此，能够减少系统操作人员的负担。应用服务器11A的应用中的故障基于来自其客户端的请求而出现。应用服务器11B对基于应用服务器11A所生成的故障事件而监视来自其客户端的请求。因此，分布式管理系统10能够防止由来自客户端的请求所导致的故障。当在应用服务器11A中的组件的接口（第一接口）中出现了大于或等于阈值的故障时，应用服务器11A将第一接口识别为该故障的原因。另外，应用服务器11A输出包括作为故障相关信息的另一个接口（第二接口）的故障事件，在该另一个接口中已经以第一接口之后的最后频率出现了故障。当第一接口被客户端所请求时，应用服务器11B基于故障事件确定第二接口是否在被线程正在执行。如果第二接口正在被执行，则应用服务器11B暂停该请求的执行。这防止了被估计与故障原因相关的处理的执行。结果，分布式管理系统10能够更为准确地防止故障。当在应用服务器11A中的组件的接口（第一接口）中出现了大于或等于阈值的故障时，应用服务器11A将第一接口识别为该故障的原因。另外，应用服务器11A输出包括作为故障相关信息的另一个接口（第三接口）的故障事件，在该另一个接口中已经出现了大于或等于阈值的故障。当第一接口被客户端所请求时，应用服务器11B基于故障事件确定第三接口是否正在被线程所执行。如果第三接口正在被执行，则应用服务器11B暂停该请求的执行。这防止了被估计与故障原因相关的处理的执行。结果，分布式管理系统10能够更为准确地防止故障。当在应用服务器11A中的组件的接口（第一接口）中出现了大于或等于阈值的故障时，应用服务器11A将第一接口识别为该故障的原因。另外，应用服务器11A输出包括作为故障相关信息的另一个接口（第二接口）的故障事件，在该另一个接口中已经出现了故障。当第一接口被客户端所请求时，应用服务器11B基于故障事件确定第二接口是否正在被线程所执行。如果第二接口正在被执行，则应用服务器11B暂停该请求的执行。这防止了被估计与故障原因相关的处理的执行。结果，分布式管理系统10能够更为准确地防止故障。在以上情况下，当第一接口被客户端所请求时，应用服务器11B基于故障事件确定第一接口是否正在被线程所执行。如果第一接口正在被执行，则应用服务器11B暂停请求的执行。因此，可能进一步减少同时执行被识别为故障原因的处理的线程的数量。结果，分布式管理系统10能够更为准确地防止故障。第一接口中的故障和第二接口中的故障均是针对存储器使用达到或超出标准或者针对CPU使用达到或超出标准。因此，分布式管理系统10能够准确防止由应用所导致的故障频繁出现。第一接口中的故障可以是针对存储器使用达到或超出标准，并且第二接口中的故障可以是针对CPU使用达到或超出标准。如以上所看到的，关于属于不同类型但是具有在应对时耗费时间这一共同特征的故障，应用服务器将作为识别故障的信息的与已经导致了故障的组件和接口相关的信息以及涉及该故障的信息包括在故障事件中，并且传送该故障事件。因此，可能进一步减少同时执行导致具有类似特征的故障的处理的线程的数量。结果，分布式管理系统10能够更为准确地防止故障。当在应用服务器11A的组件（第一接口）和另一组件（第二接口）的接口之间发生了作为故障的死锁时，应用服务器11A输出将第一和第二接口识别为故障原因的故障事件。当第一接口被客户端所请求时，应用服务器11B基于该故障事件确定第二接口是否正在被线程执行。当第二接口正在被执行时，应用服务器11B暂停请求的处理。结果，分布式管理系统10的应用服务器11能够可靠地防止死锁。根据第二实施例的分布式管理系统可应用于诸如Web应用服务器或计算机管理应用之类的中间件。因此，可能抑制与应用中的缺陷相关的系统停机（或其周期）。还可能减少系统操作人员在应对故障时的负担。本发明并不局限于以上实施例，并且能够在不背离本发明的精神和范围的情况下对实施例适当进行改变。例如，根据第二实施例的分布式管理系统10中的应用组件可以被形成Web应用服务器等的模块或系统组件所替换，并且随后，如此形成的分布式管理系统的配置和处理可以如图1至11那样进行配置。甚至在这种情况下，也可能在对分布式应用服务器进行操作时防止诸如死锁或存储器短缺的故障。虽然在第二实施例中使用了死锁和过度CPU或存储器消耗作为示例，但是故障的类型并不局限于此。可以关于计算机的其它资源的消耗而执行类似处理。根据本发明的一个方面，可能提供一种防止服务器中的故障而并不增加系统操作人员的负担的分布式系统、服务器计算机、分布式管理服务器和故障防止方法。以上所公开的全部或部分示例性实施例可以被描述为以下补充说明，但并不局限于此。（补充说明1）一种分布式系统，该分布式系统包括能够执行相同应用的第一和第二服务器，其中当该第一服务器中的该应用中出现故障时，该第一服务器生成识别该应用中的故障的原因的故障信息，并且该第二服务器执行基于该故障信息所确定并且意在防止该应用中的故障的故障防止处理。（补充说明2）根据补充说明1的分布式系统，进一步包括被配置为管理该第一和第二服务器的分布式管理服务器，其中当该应用中出现故障时，该第一服务器生成包括识别该第一服务器从该故障中恢复所必需的恢复处理的信息的该故障信息，该分布式管理服务器从该故障信息提取识别该恢复处理的信息并且将所提取的信息传送至该第一服务器，并且该第一服务器基于从该分布式管理服务器传送的识别该恢复处理的信息执行从该故障恢复的该恢复处理。（补充说明3）根据补充说明1或2的分布式系统，其中该第一服务器中的该应用中的故障基于来自该第一服务器的客户端的请求而出现，并且该第二服务器基于该故障信息对来自该第二服务器的客户端的请求进行监视。（补充说明4）根据补充说明3的分布式系统，其中该第一和第二服务器中的每一个均包括与该应用相关的多个组件，当在该第一服务器中的第一组件的第一接口中出现大于或等于阈值的故障时，该第一服务器将该第一接口识别为该故障的原因并且输出包括作为与该故障相关的信息的第二组件的第二接口的该故障信息，该第二接口是该多个组件中的接口中在该第一接口之后已经具有最多故障的接口，并且当该第一接口被该第二服务器的客户端所请求时，该第二服务器基于该故障信息确定该第二接口是否正在被线程所处理，并且如果该第二接口正在被处理，则阻止对该请求的处理。（补充说明5）根据补充说明3或4的分布式系统，其中第一和第二服务器中的每一个均包括与该应用相关的多个组件，当在该第一服务器中的第一组件的第一接口中出现大于或等于阈值的故障时，并且当除该第一接口之外在第二组件的第二接口中出现了大于或等于阈值的故障时，该第一服务器将该第一接口识别为该故障的原因并且输出包括作为与该故障相关的信息的该第二接口的该故障信息，并且当该第一接口被该第二服务器的客户端所请求时，该第二服务器基于该故障信息确定该第二接口是否正在被线程所处理，并且如果该第二接口正在被处理，则阻止对该请求的处理。（补充说明6）根据补充说明4或5的分布式系统，其中当该第一接口被该第二服务器的客户端所请求时，该第二服务器基于该故障信息确定该第一接口是否已经在被线程所处理，并且如果该第一接口正在被处理，则阻止对该请求的处理。（补充说明7）根据补充说明3、4或5的分布式系统，其中第一和第二服务器中的每一个均包括与该应用相关的多个组件，当在该第一服务器中的第一组件的第一接口和第二组件的第二接口之间出现作为该故障的死锁时，该第一服务器输出将该第一和第二接口识别为该故障的原因的的该故障信息，并且当该第一接口被该第二服务器的客户端所请求时，该第二服务器基于该故障信息确定该第二接口是否正在被线程所处理，并且如果该第二接口正在被处理，则阻止对该请求的处理。（补充说明8）一种服务器计算机，该服务器计算机部署在分布式系统中并且连接至能够执行相同应用的另一服务器计算机，其中当该应用中出现故障时，该服务器计算机生成识别该应用中的故障的原因的故障信息，并且当所述另一服务器生成识别该应用中的故障的原因的故障信息时，该服务器计算机执行基于该故障信息所确定并且意在防止该应用中的故障的故障防止处理。（补充说明9）一种分布式管理服务器，该分布式管理服务器部署在包括能够执行相同应用的第一和第二服务器的分布式系统中，其中当该分布式管理服务器从该第一服务器接收到识别该第一服务器中的该应用中的故障的原因的故障信息时，该分布式管理服务器向该第二服务器传送该故障信息，该故障信息用作由该第二服务器用来执行防止该应用中的故障的故障防止处理的信息。（补充说明10）在包括能够执行相同应用的第一和第二服务器的分布式系统中，一种用于防止该应用中的故障的故障防止方法，包括：当该第一服务器中的该应用中出现故障时，由该第一服务器生成识别该应用中的该故障的原因的故障信息，并且由该第二服务器执行基于该故障信息所确定并且意在防止该应用中的故障的故障防止处理。（补充说明11）根据补充说明4、5或6的分布式系统，其中该第一接口中的故障和该第二接口中的故障均是针对存储器使用超出标准或者针对CPU使用超出标准。（补充说明12）根据补充说明11的分布式系统，其中该第一接口中的故障是针对存储器使用超出标准或者针对CPU使用超出标准之一，并且该第二接口中的故障是针对存储器使用超出标准或者针对CPU使用超出标准中的另一个。虽然已经关于其示例性实施例特别示出并描述了本发明，但是本发明并不局限于这些实施例。本领域技术人员将会理解的是，在不背离如权利要求所限定的本发明的精神和范围的情况下，可以对形式和细节进行各种改变。