一种根因诊断的方法、装置与流程

本申请涉及存储领域，并且更具体地，涉及一种根因诊断的方法、装置。

背景技术：

应用中超时类问题不可避免，而超时类问题可能会引起应用程序崩溃或者长时间的无法响应。无法响应可以表现为应用或服务依然存在，但是实际却不能提供功能，有时候应用中严重的无法响应可能会导致业务中断。

现有技术中，仅仅是将上报超时类故障的控制器或所述控制器运用的应用确定为超时类故障的根因。但是，超时类故障的根因并不一定是上报所述超时类故障的控制器或应用。例如，上报超时类故障的控制器为控制器a，而超时类故障的根因是控制器b。如果将控制器a确定为超时类故障的根因，并对控制器a进行恢复，没有对控制器b进行恢复，那么控制器a上运行的应用还是会存在超时类问题。

因此，如何准确的检测应用中超时类问题产生的根因成为业界亟需要解决的问题。

技术实现要素：

本申请提供一种超时根因的诊断方法，可以准确的判断出超时类问题产生的根因，并可以对准确的根因故障点进行恢复。

第一方面，提供了一种超时根因的诊断方法，由主控制器执行，所述主控制器接收其他控制器发送的消息超时信息，包括：根据第一控制器发送的第一消息的超时信息，确定所述第一消息由所述第一控制器发送至第二控制器；检测所述第二控制器是否上报第二消息的超时信息，所述第二消息由所述第二控制器发送至第三控制器；若所述第二控制器没有上报所述第二消息的超时信息，确定所述第二控制器为导致所述第一消息的超时根因控制器。

上述技术方案可以准确的诊断出超时类问题产生的根因，并可以对准确的根因故障点进行恢复。

结合第一方面，在第一方面的某些实现方式中，还包括：若所述第二控制器上报所述第二消息的超时信息，检测所述第三控制器是否上报第三消息的超时信息，所述第三消息由所述第三控制器发送至第四控制器；若所述第三控制器没有上报所述第三消息的超时信息，确定所述第三控制器为导致所述第一消息的超时根因控制器。

结合第一方面，在第一方面的某些实现方式中，所述第一消息的超时信息包括：第一控制器标识id、第二控制器标识id、消息转发超时时间，根据所述第一消息的超时信息中包括的第二控制器标识id，确定所述第一消息由所述第一控制器发送至第二控制器。

第二方面，提供了一种超时根因的诊断方法，由控制器执行，所述控制器运行有第一应用，所述第一应用接收或者发送消息至其他控制器，包括：获取所述第一应用发送的超时信息；判断所述超时信息是否为持有锁超时信息或流程超时信息；若所述超时信息为持有锁超时信息或流程超时信息，则确定所述控制器为导致所述超时的根因控制器。

结合第二方面，在第二方面的某些实现方式中，在确定所述超时根因控制器后，所述方法还包括：若判断所述第一应用发送的超时信息为持有锁超时信息，则判断所述第一应用是否存在消息转发超时或申请锁超时；若判断所述第一应用没有所述消息转发超时或申请锁超时，确定所述第一应用所述超时的根因应用。

结合第二方面，在第二方面的某些实现方式中，还包括：若判断所述第一应用存在申请锁超时，则判断所述控制器运行的其他应用是否存在针对所述申请锁超时对应的区域的持有锁超时；若判断所述其他应用没有针对所述申请锁超时对应的区域的持有锁超时，确定所述第一应用为所述超时的根因应用。

结合第二方面，在第二方面的某些实现方式中，若判断所述第一应用发送的超时信息为流程超时信息，则判断所述第一应用是否存在消息转发超时或申请锁超时；若判断所述第一应用没有所述消息转发超时或申请锁超时，确定所述第一应用所述超时的根因应用。

结合第二方面，在第二方面的某些实现方式中，所述超时信息包括锁的标识，根据所述超时信息中的锁的标识确定所述超时信息为锁超时信息。

结合第二方面，在第二方面的某些实现方式中，所述超时信息包括流程的标识，根据所述超时信息中的流程的标识确定所述超时信息为流程超时信息。

第三方面，提供了一种超时根因的诊断装置，由主控制器执行，所述主控制器接收其他控制器发送的消息超时信息，包括：

检测模块，用于根据第一控制器发送的第一消息的超时信息，确定所述第一消息由所述第一控制器发送至第二控制器。

检测模块，还用于检测所述第二控制器是否上报第二消息的超时信息，所述第二消息由所述第二控制器发送至第三控制器。

诊断模块，用于若所述第二控制器没有上报所述第二消息的超时信息，确定所述第二控制器为导致所述第一消息的超时根因控制器。

结合第三方面，在第三方面的某些实现方式中，所述检测模块还用于：若所述第二控制器上报所述第二消息的超时信息，检测所述第三控制器是否上报第三消息的超时信息，所述第三消息为导致所述第三控制器发送至第四控制器。

所述诊断模块还用于：若所述第三控制器没有上报所述第三消息的超时信息，确定所述第三控制器为所述第一消息的超时根因控制器。

结合第三方面，在第三方面的某些实现方式中，所述第一消息的超时信息包括：第一控制器标识id、第二控制器标识id、消息转发超时时间，根据所述第一消息的超时信息中包括的第二控制器标识id，确定所述第一消息由所述第一控制器发送至第二控制器。

第四方面，提供了一种超时根因的诊断装置，由控制器执行，所述控制器运行有第一应用，所述第一应用接收或者发送消息至其他控制器，包括：

检测模块，用于获取所述第一应用发送的超时信息。

检测模块，还用于判断所述超时信息是否为持有锁超时信息或流程超时信息。

诊断模块，用于若所述超时信息为持有锁超时信息或流程超时信息，则确定所述控制器为导致所述超时的根因控制器。

结合第四方面，在第四方面的某些实现方式中，所述检测模块具体用于：若判断所述第一应用发送的超时信息为持有锁超时信息，则判断所述第一应用是否存在消息转发超时或申请锁超时。

所述诊断模块具体用于：若判断所述第一应用没有所述消息转发超时或申请锁超时，确定所述第一应用所述超时的根因应用。

结合第四方面，在第四方面的某些实现方式中，所述检测模块还用于：若判断所述第一应用存在申请锁超时，则判断所述控制器运行的其他应用是否存在针对所述申请锁超时对应的区域的持有锁超时。

所述诊断模块还用于：若判断所述其他应用没有针对所述申请锁超时对应的区域的持有锁超时，确定所述第一应用为所述超时的根因应用。

结合第四方面，在第四方面的某些实现方式中，所述检测模块具体用于：若判断所述第一应用发送的超时信息为流程超时信息，则判断所述第一应用是否存在消息转发超时或申请锁超时。

所述诊断模块具体用于：若判断所述第一应用没有所述消息转发超时或申请锁超时，确定所述第一应用所述超时的根因应用。

结合第四方面，在第四方面的某些实现方式中，所述超时信息包括锁的标识，所述检测模块具体用于：根据所述超时信息中的锁的标识确定所述超时信息为锁超时信息。

结合第四方面，在第四方面的某些实现方式中，所述超时信息包括流程的标识，所述检测模块具体用于：根据所述超时信息中的流程的标识确定所述超时信息为流程超时信息。

第五方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。

第六方面，提供了一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。

附图说明

图1是本申请实施例提供的一种应用场景的示意图。

图2是本申请实施例提供的一种超时根因的诊断方法的示意性流程图。

图3是本申请实施例提供的一种可能的消息转发超时处理的示意性框图。

图4是本申请实施例提供的一种检测消息转发超时故障的注册过程的示意性流程图。

图5是本申请实施例提供的一种检测上报消息转发超时故障的示意性流程图。

图6是本申请实施例提供的一种硬件结构图。

图7是本申请实施例提供的一种检测持有锁超时故障的注册过程的示意性流程图。

图8是本申请实施例提供的一种检测上报持有锁超时故障的示意性流程图。

图9是本申请实施例提供的一种检测流程超时故障的注册过程的示意性流程图。

图10是本申请实施例提供的一种检测流程超时故障的示意性流程图。

图11是本申请实施例提供的一种流程信息的记录方法的示意性流程图。

图12是本申请实施例提供的一种流程信息删除方法的示意性流程图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行描述。

应用中超时类问题不可避免，超时类问题可以包括但不限于：消息转发超时、申请锁/持有锁超时、流程超时。下面结合图1，对上述几种超时类问题进行详细描述。

图1是本申请实施例提供的一种应用场景的示意图。图1中的数据中心100可以包括主控制器110、控制器120、控制器130、控制器140。

控制器120中包括：应用126、应用127。控制器130中包括：应用136、应用137。控制器140中包括：应用146、应用147。

应理解，每个控制器上运行的应用用于为控制器提供一定功能，例如，可以是word、excel等应用。

本申请实施例中，控制器可以转发消息至其他控制器，也可以接收其他控制器发送的消息。

参见图1，以控制器120作为示例。控制器120运行的应用126可以向控制器130运行的应用136发送消息。相应的，控制器130运行的应用136可以向控制器120运行的应用126反馈响应消息。应用126或应用127还可以在进行读操作或写操作的时候，进行锁申请。

应理解，应用126与应用127可以是相同的应用程序，也可以是不同的应用程序。

在应用运行过程中，可能会存在消息转发超时、申请锁超时、持有锁超时、流程超时等。下面结合图1，以控制器120为例，对上述几种超时类问题进行详细描述。

1、消息转发超时：控制器120上运行的应用126向控制器130发送消息，逻辑上控制器130运行的必然会返回响应消息。

对于控制器120而言，如果控制器120在指定的时间内没有接收到控制器130返回的响应消息，可以称之为控制器120转发超时。控制器120运行的应用126可以上报此错误的超时信息.该超时信息可以包括但不限于：应用标识id、消息的转发超时时间、消息的操作码(operationcode，opcode)、消息发送端的控制器标识id、消息接收端的控制器标识id。

2、申请锁超时：控制器120运行的应用126在进行某种操作(例如，读操作或写操作)申时，需要申请锁。逻辑上应用126可以在指定时间内申请成功。如果应用126在指定的时间内没有申请到锁，可以称之为应用126申请锁超时。应用126可以上报此错误的超时信息，该超时信息可以包括但不限于：应用id、锁id、申请锁超时时间。

3、持有锁超时：应用126在申请锁成功之后，逻辑上应该在指定时间内将申请的锁释放。如果应用126在该锁被申请后没有在指定时间内释放，则称之为应用126持有锁超时。应用126可以上报此错误的超时信息，该超时信息可以包括但不限于：应用id、锁id、申请锁超时时间。

4、流程超时：应用126触发的流程或是流程运行过程中的输入输出(inputoutput，i/o)接口，逻辑上在指定时间必然会结束。如果流程在指定时间没有结束(程序流程本身的bug问题)，则称之为应用126流程超时。应用126可以上报此错误的超时信息，该超时信息可以包括但不限于：流程id、控制器id、流程开始时间。

本申请实施例中每个控制器中可以有一个故障检测单元，该故障检测单元为运行在所述控制器中的控制软件，用于对控制器运行的应用上报的超时类故障的根因进行诊断。并可以对诊断出的故障点进行相应的恢复动作，以便于对控制器上运行的应用进行管理。例如，控制器120上的故障检测单元121，控制器130上的故障检测单元131，控制器140上的故障检测单元141。

下面以控制器120为例，对控制器120中的故障检测单元121进行详细描述。

控制器120上运行的故障检测单元121可以包括：检测模块122、上报模块123、诊断模块124、恢复模块125。

检测模块122：可以周期性的分别检测控制器120上运行的应用(例如，应用126或应用127)存在的各种超时类故障。控制器120上运行的应用也可以向检测模块122主动上报超时信息。下面会结合图3至图9进行详细描述，此处不再赘述。检测模块122可以将接收到的超时信息发送到上报模块123。

上报模块123：可以在接收到检测模块122发送的超时信息之后，可以根据超时不同的超时类故障，决定是否将该超时信息发送至主控制器110。

作为一个示例，如果控制器120上运行的应用上报的是消息转发超时故障，那么其故障点可能是其他控制器，需要进行全局处理。因此，上报模块123可以将该超时信息发送至主控制器110。

作为另一个示例，如果控制器120上运行的应用上报的是持有锁超时和/或流程超时，其故障点可能在控制器120，需要在本地进行诊断。因此，上报模块123可以将该超时信息发送至诊断模块124，以便于诊断模块124对控制器120中的故障点进行诊断。

诊断模块124：可以在接收到上报模块123发送的超时信息之后，基于超时信息进行故障诊断。并可以在确定故障点之后，可以将该故障点上报至恢复模块125。

恢复模块125：可以在接收到诊断模块124发送的故障点之后，对故障点进行相应的恢复恢复动作。

下面对主控制器110中的故障检测单元111进行详细描述。

主控制器110上运行的故障检测单元111可以包括：检测模块112、诊断模块113。

检测模块112：可以分别检测各个控制器(例如控制器120、控制器130、控制器140)是否上报有消息超时信息。如果控制器120向控制器130发送的消息有消息超时故障，控制器120向检测模块112上报的消息超时信息包括：控制器120(消息发送端控制器)标识id、控制器130(消息接收端控制器)标识id、上报超时信息的应用id、消息的转发超时时间。检测模块112可以将消息超时信息发送给诊断模块113。

诊断模块113：可以在接收到检测模块112发送的消息超时信息之后，根据消息超时信息中的消息接收端控制器id，判断消息转发超时的根因是控制器130(消息接收端控制器)。并可以将诊断结果发送至控制器130。

现有技术中，诊断模块113根据控制器120上报的消息超时信息，可以直接诊断控制器120消息转发超时的根因是控制器130。因此，控制器130中的恢复模块135可以直接对控制器130进行恢复。但是，如果导致控制器120消息转发超时故障的根因不是控制器130，那么对控制器130进行恢复动作还是不能解决控制器120存在的消息转发超时故障。

本申请实施例提供了一种超时根因的诊断方法，可以准确的判断出超时类问题产生的根因，并可以对准确的根因故障点进行恢复。下面结合图2，对本申请实施例提供的超时根因的诊断方法进行详细描述。

图2是本申请实施例提供的一种超时根因的诊断方法的示意性流程图。图2所示的方法可以包括步骤210-230，下面对步骤210-230进行详细描述。

步骤210：获取第一控制器发送的第一消息的超时信息。

参见图1，以主控制器为主控制器110，第一控制器为控制器120作为示例。

控制器120向控制器130发送第一消息，在控制器120中的故障检测单元121检测到第一消息转发超时的故障之后，控制器120可以将该第一消息的超时信息上报至主控制器110。第一消息的超时信息可以包括但不限于：第一消息的转发超时时间、第一消息的操作码(operationcode，opcode)、第一消息发送端的控制器(例如，控制器120)标识id、第一消息接收端的控制器(例如，控制器130)标识id。

主控制器110可以根据接收到的第一消息的超时信息，确定所述控制器120发送的第一消息的响应控制器为控制器130。例如，可以根据第一消息的超时信息中包括的第一消息接收端的控制器(例如，控制器130)标识id，确定所述第一消息由控制器120发送至控制器130。

步骤220：检测所述第二控制器是否上报第二消息的超时信息。

主控制器110可以在确定第一消息的响应控制器为控制器130之后，主控制器110可以检测所述控制器130是否上报第二消息的超时信息。第一消息为控制器130发送至控制器140的消息。

应理解，控制器130可以向控制器140发送第二消息，如果控制器130通过其上运行的故障检测单元131，检测出该第二消息存在转发超时，该控制器130可以向主控制器110上报第二消息的超时信息。第二消息的超时信息可以包括但不限于：第二消息的转发超时时间、第二消息的opcode、第二消息发送端的控制器(例如，控制器130)标识id、第二消息接收端的控制器(例如，控制器140)标识id。

步骤230：若所述第二控制器没有上报所述第二消息的超时信息，确定所述第二控制器为所述第一消息的超时根因控制器。

本申请实施例中，如果主控制器110没有接收到控制器130发送的第二消息的超时信息。可以理解为由于控制器130的原因，所以没有在指定时间内向控制器120发送响应消息，因此，可以将控制器130确定为根因控制器。

可选地，在一些实施例中，如果主控制器110接收到控制器130发送的第二消息的超时信息。控制器130向控制器140发送了第二消息，该第二消息存在超时故障。可能是由于控制器140没有在指定时间内向控制器130发送该第二消息的响应消息，所以导致控制器130没能在指定时间内向控制器120发送该第一消息的响应消息。因此，可以诊断第一消息的超时根因控制器为控制器130。主控制器110还需要重复上述的判断过程，确定控制器130是否为第一消息的超时根因控制器。

本申请实施例中提供的超时根因诊断方法，可以准确的判断出超时类问题产生的根因，并可以对准确的根因故障点进行恢复。

可选地，在一些实施例中，如果故障检测单元诊断出超时类故障的根因控制器，本申请实施例提供的根因诊断方法还可以进一步诊断出超时类故障的根因是控制器中的哪个应用。

参见图1，以控制器120中的检测模块122检测到控制器120存在消息转发超时故障为例。参见图1，假设控制器120上运行的应用126向控制器130上运行的应用136发送消息，如果控制器130上运行的应用136没能在指定时间向控制器120上运行的应用126发送响应消息。主控制器110可以通过执行图2中所述的根因诊断方法，诊断出消息转发超时的根因可能是控制器130。本申请实施例中，控制器130中的故障检测单元131可以进一步诊断出根因应用。

本申请实施例中，控制器130中的故障检测单元131可以在排除如下可能之后，可以确定根因是控制器130运行的应用136。

1、申请锁超时。控制器130中的故障检测单元131判断应用136是否上报了申请锁超时。如果应用136有申请锁超时，那么由于应用136在指定时间内没有成功申请到锁，从而导致应用136没能在指定时间内向应用126反馈响应消息。因此，故障检测单元131还需要进一步判断应用136申请锁超时的根因。

如果应用136所依赖的锁没有被控制器130上运行的其他应用占用(其他应用没有上报持有锁超时)，那么可以判断应用126消息转发超时故障的根因可能是控制器130上运行的应用136自身的软件bug问题。因此，故障检测单元131中的恢复模块135需要对应用136进行恢复。

如果应用136所依赖的锁被控制器130上运行的其他应用占用(其他应用上报持有锁超时)，故障检测单元131中的诊断模块134可以进一步判断控制器130上运行的其他应用的持有锁超时的根因，有关持有锁超时的根因判断下文会进行详细描述，此处不再赘述。

可选地，在一些实施例中，故障检测单元接收到控制器上运行的应用上报的持有锁超时故障。下面对诊断模块进行持有锁超时根因的判断过程进行详细描述。

假设故障检测单元131中的诊断模块134接收到应用137上报的持有锁超时故障。控制器130中的故障检测单元131在排除以下可能之后，可以确定持有锁超时的根因是控制器130运行的应用137。

1、消息转发超时。控制器130中的故障检测单元131判断应用137是否向控制器140发送消息。如果应用137向控制器140发送消息，并且在指定时间内未接收到控制器140发送的响应消息，该应用137可以向控制器130上报消息转发超时故障。可以理解为，如果应用137有消息转发超时故障，由于控制器140没有及时向应用137反馈响应消息，应用137在等待控制器140反馈响应消息，因此导致应用137没能在指定时间内将锁释放。有关控制器130上报的消息转发超时故障的诊断过程请参考上文中的描述，此处不再赘述。

下面以控制器130上运行的应用137接收到一个写请求作为示例对上述持有锁的根因判断过程进行详细说明。若应用137接收到写请求，该应用需要申请一把锁对写数据的存储区域进行锁定。如果该应用137在该存储区域写完数据之后，需要将该数据备份至其他控制器(例如，控制器140)。该应用137需要向控制器140发送数据，控制器140需要在指定时间内向控制器130上运行的应用137发送反馈响应消息。若控制器140没有在指定时间内向应用137发送反馈响应消息，应用137在等待控制器140反馈的响应消息，从而导致应用137没能在指定时间内将锁释放。

2、申请锁超时。控制器130中的故障检测单元131判断应用137是否有申请锁超时。如果应用137在持有锁的期间，还需要再申请另一把锁。假如应用137上报了申请锁超时，那么应用137没能在指定时间内释放该锁的原因有可能是应用137没有成功申请到另一把锁。因此，还需要进一步判断应用137申请锁超时的根因。

如果应用137所依赖的另一把锁没有被控制器130上运行的其他应用占用(其他应用没有上报持有锁超时)，那么可以判断应用137持有锁超时的根因可能是应用137自身的bug问题。因此，故障检测单元131中的恢复模块135需要对需要对应用137进行恢复。

如果应用137所依赖的另一把锁被控制器130上运行的其他应用占用(其他应用上报持有锁超时)，控制器130中的故障检测单元131可以用相同的机制进一步判断控制器130上运行的其他应用的持有锁超时的根因。

应理解，例如应用137需要在存储区域a上写数据，该应用137可以申请锁a对该存储区域a进行锁定。如果控制器130上运行的其他应用正在使用存储区域a，并且该其他应用上报了持有锁a超时，那么应用137申请不到锁a的原因在于控制器130上运行的其他应用没有在指定时间内释放该锁a。控制器130中的故障检测单元131可以用相同的机制进一步判断控制器130上运行的其他应用的持有锁a超时的根因。

下面以控制器130上运行的应用137接收到一个写请求作为示例对上述持有锁的判断依据进行详细说明。若应用137接收到写请求，该应用137需要申请锁a对写数据的存储区域a进行锁定。如果应用137在该存储区域a写完数据之后，需要将该数据备份至本地的其他存储区域(例如，控制器130中的存储区域b)。该应用137需要申请锁b对存储区域b进行锁定，直到应用137将数据全部备份至存储区域b，该应用137才可以将锁a以及锁b释放。如果应用137在申请到锁a之后，在指定时间内没有申请到锁b，可能会导致申请锁a超时。

那么应用137没能在指定时间内释放锁a的原因有可能是应用137没有成功申请到锁b。因此，还需要进一步判断应用137中导致申请锁b根因。

可选地，在一些实施例中，故障检测单元接收到控制器上运行的应用上报的流程超时故障。下面对诊断模块进行流程超时根因的判断过程进行描述。

假设故障检测单元131中的诊断模块134接收到应用137上报了流程超时控制器130中的故障检测单元131在排除以下可能之后，可以确定持有锁超时的根因是控制器130运行的应用137。

如果控制器120运行的应用126向控制器120上报了流程超时，该控制器120中的故障检测恢复模块可以在排除如下可能之后，可以确定根因是控制器120运行的应用126自身bug问题，需要对应用11进行恢复。

1、消息转发超时。具体的诊断过程请参考上文中消息转发超时的根因分析过程，此处不再赘述。

2、申请锁超时。具体的请参考上文中申请锁超时的根因分析过程，此处不再赘述。

上文描述了诊断模块通过应用上报的超时信息进行根因诊断的过程，下面结合图3，以消息转发超时故障为例，更加详细的描述本申请实施例中的根因诊断方法。应注意，图3的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将本申请实施例限于所例示的具体数值或具体场景。本领域技术人员根据所给出的图3的例子，显然可以进行各种等价的修改或变化，这样的修改或变化也落入本申请实施例的范围内。

图3是本申请实施例提供的一种可能的消息转发超时处理的示意性框图。参见图3，存在如下超时类故障：

(1)opcode1：应用312(运行在控制器310上)发往应用322(运行在控制器320上)超时(3分钟)。

(2)opcode2：应用312(运行在控制器310上)发往应用322(运行在控制器320上)超时(3分钟)。

(3)opcode3：应用322(运行在控制器320上)发往应用331(运行在控制器330商)超时(3分钟)。

图3所示的消息转发超时的真实根因是：opcode1消息转发超时的根因在于控制器320运行的应用322的软件bug问题。opcode2消息转发超时的根因在于opcode3消息转发超时。opcode3消息转发超时的根因在于控制器330运行的应用331的软件bug问题。

下面结合上文描述的消息转发超时根因诊断的方法，对图3中所示的消息转发超时的根因进行诊断。

(1)根据opcode1是应用312(运行在控制器310上)发往应用322(运行在控制器320上)所导致的消息转发超时故障，因此，可能的根因是控制器320运行的应用322。但是，由于应用322存在转发至控制器330运行的应用331所导致的消息转发超时故障，因此，暂时排除应用322作为opcode1的故障点。

(2)根据opcode2是应用312(运行在控制器310上)发往应用322(运行在控制器320上)所导致的消息转发超时故障，因此，可能的根因是控制器320运行的应用322。但是，由于应用322存在转发至控制器330运行的应用331所导致的消息转发超时故障，因此，暂时排除应用322作为opcode2的故障点。

(3)根据opcode3是应用322(运行在控制器320上)发往应用331(运行在控制器330上)所导致的消息转发超时故障，由于应用331没有发往其他控制器的消息而导致的转发超时故障，因此，可以确定opcode3的故障点为应用331。

根据上述判断结果，可以确定应用331为opcode3的故障点。因此，可以对应用331进行恢复(恢复动作例如可以是对应用331进行重启)。

本申请实施例中可以在对应用331进行恢复之后，opcode2的响应消息可以在指定时间内返回，opcode2不存在消息转发超时故障。但是，opcode1还存在消息转发超时故障。由于opcode1消息转发超时的根因在于应用322的软件bug问题，因此，在下一个检测周期内，需要进行第二轮的判断。

在第二轮的检测周期内，opcode2以及opcode3的消息转发超时故障已经解决。opcode1是应用312发往应用322所导致的消息转发超时故障，由于此时应用322不存在转发至其他控制器(例如，控制器330)的消息超时故障，因此可以判定opcode1的故障点为应用322自身的软件bug问题。需要对应用322进行恢复(恢复动作例如可以是对应用322进行重启)。

本申请实施例提供的根因诊断方法，可以准确的诊断出超时类问题产生的根因，并可以对准确的根因故障点进行恢复。

上文描述了诊断模块通过应用上报的超时信息进行根因诊断的过程，下面对控制器中的故障检测单元进行超时类故障的检测过程进行详细描述。

可选地，在一些实施例中，以控制器120中，故障检测单元121主动周期性地检测消息转发超时的故障为例。检测模块122可以在控制器中注册超时检测处理任务。该任务可以包括注册检测的周期以及超时检测逻辑函数(检测模块122可以调用该检测逻辑函数判断消息是否超时)。下面会结合图4-图12对检测模块122主动周期性地检测应用是否存在超时类故障的具体实现方式进行详细描述。

以故障检测单元121中的检测模块122检测消息转发超时故障为例。图4是本申请实施例提供的一种检测消息转发超时故障的注册过程的示意性流程图。图4所示的流程图可以包括步骤410-420，下面对步骤410-420进行详细描述。

步骤410：应用注册消息转发超时信息。

结合图1，控制器上运行的应用可以调用检测模块122接口，向检测模块122注册消息转发超时信息。应用上报的消息转发超时信息可以包括：应用所在的控制器的标识(identification，id)、应用的标识id、消息的操作码opcode、消息的转发超时时间。

应理解，控制器id、应用id可以是固定的参数，消息的opcode可以是一种用于标识消息的一种编码，例如，opcode1、opcode2、opcode3等。消息转发超时时间可以是控制器上运行的应用根据其业务内容凭经验确定的超时时间。例如，某个应用的消息转发时间(可以理解为消息返回的时间)凭经验大约可以在5分钟内必然返回，那么可以将超时时间设置为大于5分钟(例如，消息转发的超时时间为6分钟)。

步骤420：检测模块122向应用注册消息转发超时的检测任务。

参见图1，检测模块122可以向应用注册消息转发超时的检测任务。该任务可以包括检测周期、超时检测逻辑函数。作为一个示例，检测模块122可以注册在5分钟内遍历发送消息的消息队列中所有的消息，并可以根据注册的超时逻辑检测函数判断消息是否超时，如果该消息转发超时，可以上报该消息转发超时故障。具体的实现过程请参考图5中每个周期的检查逻辑流程图。

图5是本申请实施例提供的一种检测上报消息转发超时故障的示意性流程图。图5所示的流程图可以包括步骤510-540，下面对步骤510-540进行详细描述。

步骤510：获取超过指定时间的消息。

需要说明的是，指定时间可以理解为转发的消息超过一定的时间。指定超时时间是一个普遍的超时时间，小于或等于应用的消息转发超时时间。例如，应用a注册的消息转发超时时间为15分钟，应用b注册的消息转发超时时间为16分钟，应用c注册的消息转发超时时间为17分钟。本申请实施例中可以将该指定时间设置为15分钟，可以将超过指定时间的消息返回供检测模块122判断是否超时，避免每次查询时接口复制的数据所占用的内存。

检测模块122可以通过通讯管理模块中的底层接口查询消息超过指定时间的消息。

具体的，可以参见图6中的硬件结构图，如图6所示，在控制器610的应用层面(操作系统620)的底层可以有通信管理模块630。通信管理模块630可以提供统一提供接口给应用提供通讯功能。通信管理模块630可以记录消息的操作码opcode、控制器id、应用id等信息。检测模块122可以查询通信管理模块630，该通信管理模块630中的底层接口可以将消息返回(该接口可以复制一份消息数据，并可以将复制的该消息数据发送至查询的模块，例如，检测模块122模块)。

可选地，通信管理模块630中的底层接口还可以将超过指定时间的消息发送至检测模块122。

步骤520：根据应用id、超时时间判断消息是否超时。

检测模块122可以在获取超过指定时间的消息之后，遍历返回的记录的消息的操作码(opcode)、控制器id、应用id以及应用在图4中的步骤410中注册的超时信息，判断是否存在消息转发超时。

具体的，检测模块122在图4中的步骤410中注册的超时检测逻辑函数判断消息的超时时间(该消息的当前时间减去消息转发的时间戳)是否大于应用注册的消息转发超时时间。

如果消息的当前时间减去消息转发的时间戳大于应用注册的消息转发超时时间(例如，消息的当前时间减去消息转发的时间戳为8分钟，应用注册的消息转发超时时间为5分钟，可以理解为该消息的转发时间超过注册的消息转发超时时间)，可以确定该消息转发超时。

如果消息转发超时，可以执行步骤530，如果消息转发没有超时，可以执行步骤540。

步骤530：上报消息转发超时故障。

检测模块122可以在判断存在消息转发超时故障，可以将该超时故障信息发送至上报模块123。

步骤540：结束。

以故障检测单元121中的检测模块122检测持有锁超时故障为例。图7是本申请实施例提供的一种检测持有锁超时故障的注册过程的示意性流程图。图7所示的流程图可以包括步骤710-720，下面对步骤710-720进行详细描述。

步骤710：应用注册持有锁超时信息。

结合图1，控制器上运行的应用可以调用检测模块122接口，向检测模块122注册持有锁超时信息。应用上报的持有锁超时信息可以包括：应用所在的控制器的标识id、应用的id、锁id、持有锁超时时间。

应理解，控制器id、应用id、锁id可以是固定的参数，持有锁超时时间可以是各个应用根据其业务内容凭经验确定的超时时间，例如，某应用中申请的锁可能凭经验可能大约5分钟内必然释放，那么可以将持有锁超时时间设置为大于5分钟(例如，持有锁的超时时间为6分钟)。

步骤720：检测模块122向应用注册持有锁超时的检测任务。

结合图2，检测模块122可以向应用注册持有锁超时的检测任务。该任务可以包括检测周期、超时检测逻辑函数。作为一个示例，检测模块122可以注册在5分钟内遍历发送消息的消息队列中所有的消息，并可以根据注册的超时逻辑检测函数判断消息是否存在持有锁超时。如果大于该持有锁超时时间，则认为该应用存在持有锁超时，可以上报该持有锁超时故障。具体的实现过程请参考图8中每个周期的检查逻辑流程图。

图8是本申请实施例提供的一种检测上报持有锁超时故障的示意性流程图。图7所示的流程图可以包括步骤810-840，下面对步骤810-840进行详细描述。

步骤810：获取超过指定时间的消息数据。

需要说明的是，指定时间可以理解为应用的持有锁时间超过指定的时间。指定超时时间是一个普遍的超时时间，可以小于或等于应用的锁持有的超时时间。例如，应用a注册的锁持有超时时间为15分钟，应用b注册的锁持有超时时间为16分钟，应用c注册的锁持有超时时间为17分钟，本申请实施例中可以将该指定时间设置为15分钟，可以将超过指定时间的消息返回供主动检测模块220判断是否超时，避免每次查询时接口复制的数据所占用的内存。

本申请实施例中检测模块122可以通过锁管理模块640中的底层接口查询超过指定时间的消息。具体的，可以参见图6中的硬件结构图，如图6所示，在控制器610的应用层面(操作系统620)的底层可以有锁管理模块640。锁管理模块640可以提供统一的加锁解锁应用接口给各个应用调用。锁管理模块640可以在持有锁数据中记录的有锁id，控制器id，应用id等信息。检测模块122可以查询锁管理模块640，该锁管理模块640中的底层接口可以将消息返回(该接口可以复制一份消息数据，并可以将复制的该消息数据发送至查询的模块，例如，检测模块122)。

可选地，锁管理模块640中的底层接口还可以将超过指定时间的消息发送至检测模块122。

步骤820：根据应用id、超时时间判断是否存在锁持有超时。

检测模块122可以遍历返回的持有锁超时信息，根据锁id、控制器id、应用id、超时时间判断是否存在锁持有超时。

具体的，根据检测模块122在图7中的步骤720中注册的超时检测逻辑函数判断消息的持有锁超时时间(该应用申请锁的时间减去当前的时间戳)是否大于该应用注册的持有锁超时时间。

如果应用的申请锁的时间减去当前的时间戳大于应用注册的持有锁超时时间(例如，当前时间减去应用申请锁的时间戳为8分钟，应用注册的持有锁超时时间为5分钟，可以理解为该应用的持有锁超时时间超过注册的持有锁超时时间)，可以确定该应用持有锁超时。

如果存在持有锁超时，可以执行步骤830，如果没有持有锁超时，可以执行步骤840。

步骤830：上报持有锁超时故障。

检测模块122可以在判断出存在持有锁超时故障的情况下，可以将该超时故障信息发送至上报模块123。

步骤840：结束。

以检测流程超时故障为例。图9是本申请实施例提供的一种检测流程超时故障的注册过程的示意性流程图。图9所示的流程图可以包括步骤910-920，下面对步骤910-920进行详细描述。

步骤910：应用注册流程超时信息。

结合图1，控制器上运行的应用可以调用检测模块122接口，向检测模块122注册流程超时信息。应用上报的流程超时信息可以包括：应用所在的控制器id、流程id、流程超时时间。

应理解，控制器id、流程id是固定的参数，流程超时时间可以是各个流程根据其业务内容凭经验确定的超时时间，例如，某流程的最长执行时间凭经验可能大约在5分钟内必然结束，那么可以将流程超时时间设置为大于5分钟(例如，流程超时时间为6分钟)。

需要说明的是，基本的设计原则为同一个模块的流程的超时时间大于模块的持有锁时间和/或消息转发超时时间。

步骤920：检测模块122注册流程超时的检测任务。

结合图1，检测模块122可以注册流程超时的检测任务，该任务可以包括检测周期、超时检测逻辑函数。作为一个示例，主检测模块122可以注册在5分钟内遍历所有消息，并可以根据注册的超时逻辑检测函数判断是否存在流程超时(流程执行时间是否大于注册的流程超时时间)。如果大于该流程超时时间，则认为该应用存在流程超时，可以上报该流程超时故障。具体的实现过程请参考图10中每个周期的检查逻辑流程图。

图10是本申请实施例提供的一种检测流程超时故障的示意性流程图。图10所示的流程图可以包括步骤1010-1040，下面对步骤1010-1040进行详细描述。

步骤1010：获取超过指定时间的流程超时数据。

检测模块122可以通过主控制器110中的检测模块112查询超过指定时间的消息。具体的，主控制器110的检测模块112可以提供统一的接口给应用调用。主控制器110中的检测模块112在链表中记录的有流程id，控制器id，应用id等信息。底层接口可以将消息返回(该接口可以复制一份消息数据，并可以将复制的该消息数据发送至查询的模块，例如，检测模块122)。

可选地，主控制器110中的检测模块112接口可以将超过指定时间的消息数据发送至检测模块122。指定超时时间是一个普遍的流程超时时间，小于等于所有流程超时时间。例如，应用a注册的流程超时时间为15分钟，应用b注册的流程超时时间为16分钟，应用c注册的流程超时时间为17分钟，本申请实施例中可以将该指定时间设置为15分钟，可以将超过指定时间的消息返回供检测模块122判断是否超时，避免每次查询时接口复制的数据所占用的内存。

通过遍历返回的流程超时信息，根据流程id、控制器id、应用id、超时时间判断是否存在流程超时，其中流程id、控制器id、应用id是固定参数，超时时间是由应用根据业务内容凭经验确定的值，例如某流程的最长执行时间凭经验大概5分钟内必然结束，那么超时时间可以适当放宽为6分钟。

步骤1020：根据应用id、超时时间判断是否存在流程超时。

检测模块122可以遍历返回的流程超时信息，根据流程id、控制器id、应用id、超时时间判断是否存在流程超时。

具体的，根据检测模块122在图9中的步骤920中注册的超时检测逻辑函数判断模块的流程超时时间是否大于应用注册的流程的超时时间。如果流程超时时间大于应用注册的流程的超时时间，可以确定该应用流程超时。

如果存在流程超时，可以执行步骤4030，如果流程没有超时，可以执行步骤1040。

步骤1030：上报流程超时故障。

检测模块122可以在判断存在流程超时故障，可以将该超时故障信息发送至上报模块123。

步骤1040：结束。

可选地，在一些实施例中，与上述图9以及图10所示的流程检测逻辑同时存在另外2个系统流程，用于记录和删除流程信息，下面结合图11至12进行详细描述。

图11是本申请实施例提供的一种流程信息的记录方法的示意性流程图。图11所示的流程图可以包括步骤1110-1140，下面对步骤1110-1140进行详细描述。

步骤1110：告知检测模块122流程开始。

在某流程正式开始之前，应用会调用检测模块122的流程开始接口。

步骤1120：检测模块122记录流程id、控制器id、应用id、开始时间。

检测模块122的流程开始接口可以记录下流程的id(由应用自己定义)、控制器id、应用id和开始时间(即当前时间)，记录下来之后会发送该信息到主控制器110中的检测模块112。

步骤1130：检测模块122将记录的信息发送至主控制器110中的检测模块112。

步骤1140：主控制器110中的检测模块112将信息存在到内存中。

主控制器110中的检测模块112在收到该超时信息(记录下的流程id、控制器id、应用id和开始时间)后将该数据添加到内存的链表中。在图10中的步骤1020判断是否存在流程超时的过程中，可以查询这个链表，用当前时间减去开始时间即可计算一个流程的超时时间。

图12是本申请实施例提供的一种流程信息删除方法的示意性流程图。图12所示的流程图可以包括步骤1210-1240，下面对步骤1210-1240进行详细描述。

步骤1210：告知检测模块122流程结束。

在某流程正式结束之前，应用会调用检测模块122的流程开始接口。

步骤1220：检测模块122记录流程id、控制器id、应用id、开始时间。

检测模块122的流程开始接口可以记录下流程的id(由应用自己定义)、控制器id、应用id和开始时间(即当前时间)，记录下来之后会发送该信息到主控制器110中的检测模块112。

步骤1230：检测模块122将记录的信息发送至主控制器110中的检测模块112。

步骤1240：主控制器110中的检测模块112删除相同的信息。

主控制器110中的检测模块112在收到该超时信息(记录下的流程id、控制器id、应用id和开始时间)后，遍历当前流程信息的链表，将相同流程id、控制器id、应用id的数据删除。

上文结合图1至图12，详细描述了本申请实施例提供的一种超时根因的诊断方法，下面详细描述本申请的装置的实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。

参见图1，主控制器110中的故障检测单元111可以用于执行本申请实施例提供的超时根因的诊断方法。故障检测单元111可以包括：检测模块112、诊断模块113。

检测模块112用于：根据第一控制器发送的第一消息的超时信息，确定所述第一消息由所述第一控制器发送至第二控制器。

所述检测模块112还用于：检测所述第二控制器是否上报第二消息的超时信息，所述第二消息由所述第二控制器发送至第三控制器。

诊断模块113：若所述第二控制器没有上报所述第二消息的超时信息，确定所述第二控制器为导致所述第一消息的超时根因控制器。

可选地，在一些实施例中，所述检测模块112还用于：若所述第二控制器上报所述第二消息的超时信息，检测所述第三控制器是否上报第三消息的超时信息，所述第三消息为所述第三控制器发送至第四控制器。

所述诊断模块113还用于：若所述第三控制器没有上报所述第三消息的超时信息，确定所述第三控制器为所述第一消息的超时根因控制器。

可选地，在一些实施例中，所述第一消息的超时信息包括：第一控制器标识id、第二控制器标识id、消息转发超时时间，

所述检测模块具体用于：根据所述第一消息的超时信息中包括的第二控制器标识id，确定所述第一消息由所述第一控制器发送至第二控制器。

可选地，在一些实施例中，本申请实施例还提供了一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。

可选地，在一些实施例中，本申请实施例还提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机应用产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。