CN114116428A - 调度***的故障诊断方法及设备 - Google Patents

Abstract

本申请实施例提供了一种调度***的故障诊断方法及设备，方法包括：接收调度***发送的指标数据，并对接收到的指标数据进行聚合处理后，将聚合处理后的指标数据上传至第一数据库；在接收到用户发送的诊断请求时，根据诊断请求对应的诊断类型，从第二数据库中获取目标诊断规则；根据所述诊断类型从第一数据库中获取诊断所需的目标指标数据，并根据目标诊断规则，对目标指标数据进行处理，以得到诊断报告；将诊断报告的文件地址发送至所述调度***。本申请能够更好地向用户展示作业流/作业以及调度服务的故障点，便于用户自行排障或者及时联系运维人员进行处理，降低平台用户的使用门槛，并提升了故障诊断效率。

Description

调度***的故障诊断方法及设备

技术领域

本申请实施例涉及公有云技术领域，尤其涉及一种调度***的故障诊断方法及设备。

背景技术

从服务对象和范围来讲，云计算平台可以被分为公有云、私有云和混合云。其中，公有云平台一般通过作业调度***对接收到的任务进行响应、分配以及重发。

面对公有云平台中海量的任务，在作业调度过程中难免会出现一些故障，因此需要随时对调度过程中产生的故障进行分析诊断。现有的云平台用户在对调度过程中的故障进行分析诊断时，一般会遇到如下问题：1)现有的调度流程步骤比较多，作业流和作业的状态转移关系复杂，任意转换过程中都涉及不少关键步骤，任意环节出错都会导致作业无法正常调度运行，但故障定位手段只能依靠翻查后台日志中的报错点；2)现有的运行指标都是对应整个调度***的统计指标，没有针对单个作业的指标记录，难以聚合出单个作业的调度过程的记录，并找出调度流程中的故障点；3)现有调度框架缺失对调度服务故障的分析手段，导致使用门槛比较高。

因此，如何提升对调度***中的作业流、作业或调度服务的故障诊断能力，是目前亟需解决的技术问题。

发明内容

本申请实施例提供一种调度***的故障诊断方法及设备，可以有效提升对调度***中的作业流、作业或调度服务的故障诊断能力。

第一方面，本申请实施例提供一种调度***的故障诊断方法，该方法包括：

接收调度***发送的指标数据，并对接收到的所述指标数据进行聚合处理后，将聚合处理后的指标数据上传至第一数据库；

在接收到用户发送的诊断请求时，根据所述诊断请求对应的诊断类型，从第二数据库中获取目标诊断规则，所述诊断请求对应的诊断类型包括作业流诊断、作业诊断以及调度服务诊断中的任意一种；

根据所述诊断类型从所述第一数据库中获取诊断所需的目标指标数据，并根据所述目标诊断规则，对所述目标指标数据进行处理，以得到诊断报告；

将所述诊断报告的文件地址发送至所述调度***。

第二方面，本申请实施例提供一种调度***的故障诊断装置，包括：

指标聚合模块，用于接收调度***发送的指标数据，并对接收到的所述指标数据进行聚合处理后，将聚合处理后的指标数据上传至第一数据库；

诊断分析模块，用于在接收到用户发送的诊断请求时，根据所述诊断请求对应的诊断类型，从第二数据库中获取目标诊断规则，所述诊断请求对应的诊断类型包括作业流诊断、作业诊断以及调度服务诊断中的任意一种；

所述诊断分析模块，还用于根据所述诊断类型从所述第一数据库中获取诊断所需的目标指标数据，并根据所述目标诊断规则，对所述目标指标数据进行处理，以得到诊断报告；

所述诊断分析模块，还用于将所述诊断报告的文件地址发送至所述调度***。

第三方面，本申请提供一种电子设备，包括：至少一个处理器和存储器；

所述存储器存储计算机执行指令；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如第一方面提供的调度***的故障诊断方法。

第四方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如第一方面提供的调度***的故障诊断方法。

本申请提供了一种调度***的故障诊断方法，通过聚合指标数据来形成对作业流、作业调度过程的记录以及对调度服务的诊断，并且进一步对聚合指标数据进行分析诊断，能够更好地向用户展示作业流/作业以及调度服务故障点，便于用户自行排障或者及时联系运维人员进行处理，降低平台用户的使用门槛，并提升了故障诊断效率。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对本申请实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。

图1为本申请实施例提供的一种调度***的故障诊断方法的流程示意图；

图2为本申请实施例提供的一种调度***的故障诊断***的架构示意图；

图3为本申请实施例中提供的一种作业流状态流转图；

图4为本申请实施例中提供的一种作业状态流转图；

图5为本申请实施例中作业流或作业诊断分析流程示意图；

图6为本申请实施例中服务指标诊断分析流程示意图；

图7为本申请实施例中提供的一种调度***的故障诊断装置的程序模块示意图；

图8为本申请实施例中提供的一种电子设备的硬件结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。此外，虽然本申请中公开内容按照示范性一个或几个实例来介绍，但应理解，可以就这些公开内容的各个方面也可以单独构成一个完整实施方式。

需要说明的是，本申请中对于术语的简要说明，仅是为了方便理解接下来描述的实施方式，而不是意图限定本申请的实施方式。除非另有说明，这些术语应当按照其普通和通常的含义理解。

本申请中说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似或同类的对象或实体，而不必然意味着限定特定的顺序或先后次序，除非另外注明。应该理解这样使用的用语在适当情况下可以互换，例如能够根据本申请实施例图示或描述中给出那些以外的顺序实施。

此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖但不排他的包含，例如，包含了一系列组件的产品或设备不必限于清楚地列出的那些组件，而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。

本申请中使用的术语“模块”，是指任何已知或后来开发的硬件、软件、固件、人工智能、模糊逻辑或硬件或/和软件代码的组合，能够执行与该元件相关的功能。

本申请涉及公有云平台中的作业调度***，为公有云平台中海量作业调度提供一种调度业务和调度服务的指标聚合与故障分析诊断的方法，实现对作业调度流程的智能诊断。

目前，云平台用户在对调度过程进行故障分析诊断时一般会遇到如下问题：

(1)现有调度框架的调度流程步骤比较多，作业流和作业的状态转移关系复杂，任一转换过程中都涉及很多关键步骤，任一环节出错都会导致作业无法正常调度运行，但故障定位手段基本只能翻查后台日志中的报错点。

(2)现有调度框架的运行指标都是对应整个调度***的统计指标，没有针对单个作业的指标记录，难以聚合出单个作业的调度过程的记录，并找出调度流程中的故障点。

(3)现有调度框架缺失对调度服务故障的分析诊断的手段，导致框架对普通用户使用门槛比较高。

(4)目前异构、多样化的计算平台产生了多种类型的作业，现有框架一般是将特定平台的作业提交到对应计算平台，缺失监控作业状态，现有框架的作业状态监控指标也没有对外暴露，导致用户排查时需要关联特定计算平台日志，造成运维排查困难。

示例性的，在一些实施例中，Apache Airflow调度***通常应用StatsD框架实现指标聚合和诊断分析。该技术方案中，Apache Airflow调度***主要分成三个组件，Airflow WebServer(页面服务端)、Airflow Scheduler(后端调度引擎)及Airflow Woker(执行作业客户端)。这三个组件的代码里都嵌入了创建StatsD客户端并发送响应的指标给StatsD服务端。StatsD服务端是服务器上一个监听UDP和TCP请求中的统计指标并发送聚合结果到后端数据库的守护进程。StatsD服务端接收到指标后，会解析数据并进行聚合，然后定时推送到后端的数据库，如influxDB或者ElasticSearch。外部的监控告警***可以请求后端数据库来获取指标以完成监控告警功能。该技术方案的诊断分析相对简单，调度整体情况可以通过分析指标数据，如用户可以使用Kibana或者Grafana等工具来进行分析；另外，用户可以通过分析日志来得出服务异常和作业异常的诊断结论。

上述技术方案中，Airflow调度***支持的指标主要包含三种类型：计数类型(Counters)、标量类型(Gauges)及计时器类型(Timers)。这三类指标基本是都是反应调度全局层面的情况，只有计时器指标能针对特定作业有响应的记录。其中，计数类型是指指标聚合是以计数总和的方式，Airflow调度***中支持26个计数指标包括成功/失败/排队中作业实力总数，正在运行的作业流总数等计数指标；标量类型是指无需对指标进行聚合，如果下一次指标没有更新，则保持原值，Airflow调度***中支持22个标量指标包括Worker服务节点上正在运行/排队中的作业总数，解析dag文件超时的任务总数等。计时器类型是指指标聚合是有带时间窗口的方式，能表示指定直接内特点数据的平均值/总数/百分位数等，Airflow中支持了9个计时器指标包括特定任务执行时间，特定任务调度延迟，特定任务执行到成功状态所用时间等。

除此之外，如果StatsD服务如果要进行横向扩展时，需要再部署StatsD Proxy服务，该服务能保证同一个指标发送到固定的节点。

上述技术方案存在的缺陷在于：StatsD服务端需要先解析数据并聚合指标，当数据上报量过大时，需要调度框架在发送时修改采样率，否则会使服务端数据处理形成性能瓶颈；需要用户按经验来确定采样率，局限性较大；StatsD服务端进行服务横向扩展时，无法解决特定指标流量过大需要负载均衡的场景；框架本身没有提供对应单个作业流或者作业的调度指标，难以形成对作业流和作业的异常诊断分析，需要用户自行查看日志；框架本身不提供诊断分析功能，需要用户自行分析指标数据，甚至是服务日志和作业日志。

在另一些实施例中，调度***可以应用Apache Azkaban框架内部实现任务指标收集和诊断分析。该技术方案中，Apache Azkaban调度***主要由三个关键组件构成：WebServer、ExecutorServer和MySQL关系数据库。其中，Azkaban ExecutorServer主要负责具体的作业流的提交、执行，可以通过启动多个执行服务器扩展调度能力，ExecutorServer通过Mysql数据库来协调任务的执行。ExecutorServer在负责作业流提交和执行的过程中，代码中嵌入指标聚合的代码，并将指标写入到MySQL数据库中，定时上报给WebServer。Azkaban调度***会通过WebServer暴露对应指标的***给外部应用，外部应用可以通过http请求来获取指标数据。然而，目前Azkaban框架只提供了5个指标数据，包括成功/失败/排队中的作业流总数以及运行中/失败作业总数，并通过修改http请求参数，可以实现按时间窗口和按实例数的聚合。

上述技术方案中，框架核心组件会将服务日志和作业日志都提供给用户，用户可以自行分析日志内容来诊断异常。

上述技术方案存在的缺陷在于：框架本身没有提供对应单个作业流或者作业的调度指标，难以形成对作业流和作业的异常诊断分析，需要用户自行查看日志；框架本身不提供诊断分析功能，需要用户自行分析指标数据，甚至是服务日志和作业日志；提供指标数据较少，如果外部***高频请求指标数据，容易影响核心调度组件的处理性能。

面对上述技术问题，本申请提供了一种调度***的故障诊断方法，通过聚合指标数据来形成对作业流、作业调度过程的记录以及对调度服务的诊断，并且进一步对聚合指标数据进行分析诊断，能够更好地向用户展示作业流/作业以及调度服务故障点，便于用户自行排障或者及时联系运维人员进行处理，降低平台用户的使用门槛，并提升了故障诊断效率。

在一些实施例中，面对现有调度***一般只提供表达调度全局情况的聚合指标，对于单一作业流或者作业只有少量甚至没有相应的指标来表达。当前多种异构计算平台上作业的调度运行指标也少有***支持，这个现状导致了对现有调度***而言，故障定位手段基本只能翻查服务日志或者作业日志中的报错点。本申请在常见的聚合指标数据之上，抽象并扩展了单一作业流或者作业对应调度各阶段的业务指标，并通过定义和构建调度业务规则树来形成对指标数据的清洗，剪枝和加工，最后形成对应作业流或作业的诊断报告。

在一些实施例中，面对现有调度***需要用户主动去分析服务日志，或者利用Kibana或者Grafana等工具可视化分析聚合指标数据来分析出调度服务的诊断报告，用户使用门槛较高。本申请通过定义构建服务指标规则，等价于对聚合指标数据的展示模版，根据模版来对现有的多种指标数据进行清洗和加工，最后形成对应调度服务的整体诊断报告。

在一些实施例中，面对现有技术方案中指标聚合服务的服务横向扩展能力有限，本申请中将指标聚合和诊断分析两者功能合并抽象为一个指标诊断模块，在微服务架构中支持流量负载均衡以及灵活的扩缩容。指标诊断模块与调度***通过http方式进行解耦，不会直接影响调度***性能，并且调度***能够通过配置文件灵活地选择是否开启该功能。

下面采用详细的实施例进行详细说明。

参照图1，图1为本申请实施例提供的一种调度***的故障诊断方法的流程示意图。如图1所示，该调度***的故障诊断方法包括：

S101、接收调度***发送的指标数据，并对接收到的所述指标数据进行聚合处理后，将聚合处理后的指标数据上传至第一数据库。

本申请实施例中，可以预先构建一个指标诊断模块，该指标诊断模块分为两个子模块，分别为指标聚合模块和诊断分析模块。

在一种可行的实施方式中，调度***的各个核心组件可以以Http方式上报指标数据给指标聚合子模块，该标聚合子模块接收到调度***发送的指标数据后，解析报文中的指标数据，并判断具体的指标类型，按需进行聚合计算。

其中，指标聚合模块会有定时线程定时地将指标数据推送到后端的第一数据库。

可选的，该第一数据库可以是时序数据库(influxDB)或者非关系型数据库(ElasticSearch)。

在一些实施例中，对于调度流程业务指标数据，如作业流和作业的调度业务指标，会以时间顺序存储，便于根据作业流或作业的开始和结束时间来筛选指标数据；对于调度服务指标数据，如作业运行中/成功/失败/排队中总数，服务心跳时间，作业流执行所需时间等数据，是以对应指标含义存储在特定数据区，便于外部服务读取。

S102、在接收到用户发送的诊断请求时，根据所述诊断请求对应的诊断类型，从第二数据库中获取目标诊断规则。

本申请实施例中，当用户发起一个诊断请求给调度***时，调度***会进行用户鉴权，如果用户鉴权通过，就将诊断请求转发给诊断分析模块，否则就不会将诊断请求转发给诊断分析模块。

诊断分析模块接收到诊断请求后，从报文中解析出诊断类型，然后从第二数据库中获取诊断规则，并组装诊断规则树或诊断规则列表。

可选的，上述第二数据库为关系型数据库。

上述诊断类型一般包括：作业流诊断，作业诊断和调度服务诊断。

S103、根据所述诊断类型从所述第一数据库中获取诊断所需的目标指标数据，并根据所述目标诊断规则，对所述目标指标数据进行处理，以得到诊断报告。

本申请实施例中，根据所述诊断类型从所述第一数据库中获取诊断所需的目标指标数据。

在一些实施例中，当上述诊断请求对应的诊断类型为调度服务诊断时，获取第一数据库当前最新上传的目标指标数据；当上述诊断请求对应的诊断类型为作业流诊断或作业诊断时，根据诊断请求中的作业流运行起始时间，获取第一数据库中指定时间范围内上传的目标指标数据。

其中，上述指定时间范围为诊断请求中的作业流运行起始时间到上述诊断分析模块接收到诊断请求的时间。

在一些实施例中，当上述诊断类型为作业流诊断或作业诊断时，根据获取的诊断规则组装为诊断规则树，并根据诊断规则树，来对获取的指标数据进行清洗，裁剪和加工等处理后，生成诊断报告；当上述诊断类型为调度服务诊断时，根据获取的诊断规则组装为诊断规则列表，并根据诊断规则列表，来对获取的指标数据进行清洗，裁剪和加工等处理后，生成诊断报告。

S104、将所述诊断报告的文件地址发送至所述调度***。

本申请实施例中，在生成诊断报告后，将诊断报告文件地址返回给调度***。调度***异步获取到诊断报告文件地址后，读取相应内容并展示到前端页面供用户查看。

除此之外，用户根据调度***的迭代演进，访问诊断分析子模块的web接口来上传json格式数据，可以对已有诊断规则进行修改和增减。

本申请实施例提供的一种调度***的故障诊断方法，通过聚合指标数据来形成对作业流、作业调度过程的记录以及对调度服务的诊断，并且进一步对聚合指标数据进行分析诊断，能够更好地向用户展示作业流/作业以及调度服务故障点，便于用户自行排障或者及时联系运维人员进行处理，降低平台用户的使用门槛，并提升了故障诊断效率。

参照图2，图2为本申请实施例提供的一种调度***的故障诊断***的架构示意图。

在一些实施例中，上述指标聚合模块负责接收调度***发送的指标数据，并按需进行聚合操作后，定时地发送到第一数据库。

其中，上述指标数据源自于调度***的逻辑代码，需要其在代码逻辑中嵌入指标发送的逻辑。

在一些实施例中，发送指标数据的报文包含以下信息：metricName(指标名称)、metricTime(指标发送时间)、metricType(指标类型)、operator(指标操作数)、operatorElement(指标操作对象)、operatorResult(指标操作结果)、instId(实例id)、instStatus(实例状态)、zxid(全局唯一id)、metricContext(指标内容)、errCauseReason(操作步骤错误原因)、errMsg(错误具体信息)、module(调度模块名称)、hostIP(模块网络IP)等。

由于指标分为调度业务指标和调度服务指标，区分在于调度业务指标偏向于记录过程结果，所以需要增加操作对应的实例状态和实例id，而服务指标偏向于统计和记录最新信息，是指标聚合模块进行处理，所以不需要填写操作错误和对应实例信息。

在一些实施例中，调度业务指标又细分为作业流调度业务指标和作业调度业务指标，而调度服务指标一般则根据聚合模式分为计数型，标量型和计时型。因此，虽然业务上只有三种不同指标，但metricType需要映射为5种类型，对应5个数值。

指标聚合子模块收到报文时，需要首先校验指标类型，其次根据指标类型来校验报文信息是否正确和完整，然后分别对调度业务指标和调度服务指标做不同逻辑处理。

需要补充说明的是，首先由于调度***各核心组件可能分布式部署，所以需要发送全局唯一id来进行区分，而且模块名称和模块网络IP也是用来区分；其次是调度操作过程中可能报错，所以需要额外补充操作步骤错误原因和具体信息；最后关于指标内容，对于业务指标来说会是流程记录信息，而对于服务指标来说则是对应指标的值。

其中，调度业务指标是调度***中关于作业流和作业实例从创建到销毁的全流程的埋点记录指标数据。在调度***中，作业流和作业的状态有不少，状态流转时也有很多情况。对于作业流状态流转图来说，作业流状态有7种，而状态流转的情况共有8种。而对于作业状态流转图来说，作业状态有11种，而作业状态流转的情况共有14种。对于不同调度***来说，作业流和作业状态流转图相对具有共性，但是状态流转中具体涉及的中间步骤则大不相同。

为了更好的理解本申请实施例，参照图3与图4，图3为本申请实施例中提供的一种作业流状态流转图；图4为本申请实施例中提供的一种作业状态流转图。

在本申请实施例中，抽象化业务指标的操作，即包含了操作数，操作对象和操作结果。为了尽可能地覆盖不同***的中间操作的技术能力，比如包含文件、消息队列、关系型数据库、Redis、Kubernetes、Yarn、内存队列以及Zookeeper等，共抽象了15种操作对象，以及对应的19种操作数和对应的操作结果。

当调度***中的业务关键中间步骤能够被梳理时，同时由调度***进行指标上报后，只需要通过算法将指标和中间步骤的顺序相对应，就能够获取一个作业流或者作业实例的调度全流程的报告，并能够简单对其加工或分析得出异常点。而被梳理的确定性的关键中间步骤就可以被这里抽象的操作表示成诊断规则，并通过构建诊断规则树就能够表示调度全流程中状态流转操作后的各种可能结果。

为了更好的理解本申请实施例，参照表1，表1为指标对应的操作数、操作对象和操作结果示意表

表1：指标对应的操作数、操作对象和操作结果示意表

由调度***中的不同模块，对应执行了作业流和作业状态流转图中的不同中间关键步骤，在执行完成之后，对应执行的结果或者异常，都需要增加发送业务指标的逻辑。例如，调度***中负责作业运行的执行模块，接收到作业信息之后，解析作业参数并成功提交到Kubernetes来创建作业运行实例之后，需要发送http请求到指标聚合子模块，请求包含的信息有操作数为提交，操作对象为Kubernetes，操作结果为成功，并带上实例id和实例状态为运行中，以及对应指标内容为成功提交作业到Kubernetes并创建作业实例等信息。后续运行模块还需要不断地去请求Kubernetes的Api Server服务来获取作业实例的运行状态，每次获取到监控数据也需要再发一次http请求给指标聚合子模块，而冗余的指标内容会在诊断分析时进行清洗。

在一些实施例中，当指标聚合模块接收到http请求之后，先根据指标类型，如果不是业务指标数据转向其它指标类型的处理流程，如果是业务指标，则验证其信息的完整，解析指标数据，调用业务指标处理服务并将其转换成服务处理队列的Append命令，并添加到队列中，如果添加队列成功，则返回请求成功，反之则失败。业务指标处理服务包含了一个Sender实例，会根据配置文件来选择Sender实例是发送数据到ElasticSearch还是influxDB。其次，业务指标处理服务会有线程不断从处理队列中拿出处理命令，当处理命令是Append时，会将指标数据添加到Sender实例的内存队列中，此时会根据业务指标类型放到作业流或者作业的内存队列。再者，业务指标处理服务还会起一个定时线程，定时间隔就是配置文件中的业务指标发送后端数据库的刷新间隔，间隔往处理队列放Flush命令。最后当有线程从处理队列中拿出Flush命令时，会先查看数据区有没有存在，如果不存在要先创建，对应ES数据库的话是创建index，如果存在数据区了，那么会异步把Sender实例内存队列中的数据，调用数据库对应Api批量写入后端数据库的对应数据区。对于数据区的命名，用户可以在配置文件中设置前缀，业务指标会以日期作为后缀，并以此为名称创建数据区。最后，当业务处理指标服务要关闭时，需要先向处理队列先加入一个flush命令再加一个close命令，如果业务指标处理服务的线程处理到close命令，那么会停止指标处理服务的队列处理线程的轮询操作，并等待定时线程一起退出，同时关闭后端处理库的连接。

在一些实施例中，调度服务指标是调度***中关于调度服务的性能层面的相关指标，主要分为三种类型：标量型、计数型和计时型。这三种类型根据报文中的指标类型来进行区分。当调度***发送调度服务指标时，报文中不需要实例id和实例状态。

需要注意的是，由于复用的是一套报文结构，但是指标内容字段，在调度业务指标中表示的是记录操作过程信息，而在服务指标中则表示对应指标的值。

在一些实施例中，根据调度***的不同，用户可以自定义不同的调度服务指标，只需要该服务指标的报文结构，并确认好指标聚合方式，以http的方式发送给指标聚合子模块，那么指标就能记录到用户在配置文件配置的数据区中。比如说，调度***的执行模块的心跳时间，用户需要诊断报告中展示的是一个最新的时间，那么就可以配置为标量型，同时在调度***中的执行模块里嵌入代码，来上报指标，并在报文中指定指标名称为执行模块的心跳时间，以及指标内容中上报心跳时间，操作对象是Time。再者，如果用户需要在诊断报告中展示的是调度***的执行成功的作业实例总数，那么就可以配置为计数型，同时在执行模块每次执行完成一个作业时上报计数指标，并在报文中指定指标名称为执行模块执行成功的作业实例总数，以及指标内容为1，而操作对象是NUM。服务指标在检验的时候，操作对象是否是NUM和TIME，如果是其他对象会直接返回失败并丢弃该数据。

在一些实施例中，当指标聚合模块接收到http请求之后，先根据指标类型，如果不是服务指标数据转向其他指标类型的处理流程，如果是服务指标，则验证其信息的完整，解析指标数据，调用服务指标处理服务并将其转换成处理队列的Append命令，如果服务指标的类型是计数型或者计时型，需要再往处理队列中添加一个Compute命令，如果都添加队列成功，则返回请求成功，反之则失败。服务指标处理服务包含了一个Sender实例，会根据配置文件来选择Sender实例是发送数据到ElasticSearch还是influxDB。

其次，服务指标处理服务会有线程不断从处理队列中拿出处理命令，当处理命令是Append时，会将指标数据添加到Sender实例的内存结构中。这时分为三种情况，在Sender实例中，对于计数型的指标维护了一个Map，key值是指标名称，value是一个List，对于Append命令，只需要将指标值添加到List中；对于计时型的指标也维护了两个Map，这两个Map的key值都是指标名称，其中一个的value是一个定长Queue，对于Append命令，也只需要将指标值添加到Queue中，而另一个则是Pair，是在计算完成之后存储，指标对应内存计算得到的总时长和累加指标个数；对于标量型的指标也维护了一个Map，key值是指标名称，value是指标的值，Append指令会直接将value修改为当前value。当处理命令是Compute时，只对于计时型，相对比较特殊的是，对于时间范围容易有异常极值的存在，比如说某个服务异常时，作业从创建到完成所消耗的时间就会比正常的大得多，所以需要对Queue中的数据进行排序，同时去掉前后的10％再进行累计，累计的结果会存储到内存。

再者，业务指标处理服务还会起一个定时线程，定时间隔就是配置文件中的业务指标发送后端数据库的刷新间隔，间隔往处理队列放SingleFlush命令和ReadFlush命令。接着，当有线程从处理队列中拿出命令是SingleFlush命令和ReadFlush命令时，SingleFlush命令只会处理标量型指标，ReadFlush则只会处理计数型和计时型指标。两者都会先查看数据区有没有存在，如果不存在要先创建，对应ES数据库的话是创建index。如果存在数据区了，SingleFlush命令中异步把Sender实例关于标量型的内存Map中的数据，调用数据库对应Api逐个写入后端数据库的对应数据区。而ReadFlush命令首先会处理计数型指标，即循环Sender实例内存中维护的计数型对应的Map，对应每一个指标以乐观锁机制，从数据区读取对应累加值，与List中元素的累加后得到新的数值并更新到数据区，同时清空List，然后处理计时型指标，同样以乐观锁机制，从数据区读取计时型对应指标的值，能获取到总时长和计数值，与内存Map中的总时长和计数值进行累计。

当业务处理指标服务要关闭时，需要先向处理队列先加入两个flush命令(即SingleFlush和ReadFlush命令)再加一个close命令，如果业务指标处理服务的线程处理到close命令，那么会停止指标处理服务的队列处理线程的轮询操作，并等待定时线程一起退出，同时关闭后端处理库的连接。

需要说明的是，本发明在服务指标聚合上，虽然聚合模式和StatsD的基本一致，但是聚合计算的方式与StatsD有本质的区别。原因是由于StatsD在集群部署时，依赖StatsDproxy服务，这个服务为了兼容单服务的逻辑，固定将一个指标发给固定的一个节点，简单地避免多节点写入时的并发问题。但是，当特定指标的请求流量激增时，即便扩展了N个服务节点，也没办法做到流量的负载均衡。而本发明关于计数型和计时型的服务指标，在多节点并发写入时引入了乐观锁能很大程度上做到性能和扩展性的平衡，对于流量激增的情况，水平扩容的情况下也能够直接支持流量的负载均衡。

在一些实施例中，由于调度***中作业流和作业状态流转情况复杂，所以要进行诊断分析之前，在指标上报阶段先抽象了状态流转中关键中间步骤的操作。

在抽象操作中，本申请定义了15种操作对象和19种操作数和对应操作结果。在定义诊断规则时，诊断规则就能够简单地抽象出来的操作对象，操作数和对应操作结果来作为语法来书写，并以此来表达每一种状态转移过程中的中间步骤，或者是表达一种约束关系。

比如，已知作业状态从等待资源转移到取消状态是需要经过人工干预中的终止操作，而终止操作的关键步骤是在关系型数据库中将作业状态从等待资源修改为终止，那么诊断规则能被书写为update DB_JOB_STATUS SUCCESS；当诊断到该作业状态为等待资源时，就能够根据业务指标数据的操作信息，对比相同的update DB_JOB_STATUS对象时，操作结果是否是SUCCESS，如果是FAILED，那么就在诊断报告中表示出这个故障点。再者，已知调度***中每个模块的心跳上报时间不能超过10分钟不更新，那么诊断规则能被书写为less_than TIME 10,表示比当前时间还要少10分钟；当诊断所有的服务心跳上报时间时，就能够根据服务指标数据的指标内容获取到指标内容中的心跳时间，这时候依据诊断规则的操作计算，对比心跳时间与当前时间查看是否大于约束值10分钟，就能诊断出满不满足要求，从而得出是否有异常。

其中，诊断规则树的构建就是在还原整个调度***的流转过程，将抽象出的诊断规则嵌入到状态流转图中就能够获得一个诊断规则树。这个诊断规则树的树状结构，起树状结构的节点关系可以将其存储在关系型数据库。因此，本申请在关系型数据库中构建了一张表diagnose_rules，并包含如下字段：rule_id(规则id)、rule_detail(规则内容明细)、rule_suti_condition(规则适用条件)、parent_rule_id(节点父节点规则id)、level(树的层级，0表示根节点)、err_tips(异常信息提示)、info_tips(正常信息)、rule_type(规则类别，1表示作业流诊断规则，2表示作业诊断规则，3表示服务诊断规则)。规则内容明细即书写的规则本身，规则使用条件即服务指标名称的匹配表达式，或者是作业流/作业的状态。需要额外说明的一点是，考虑到服务指标信息本质上没有状态流转的关系，所以服务诊断规则的level都是平级，默认为-1。

作业流和作业诊断分析的流程基本是一致的，唯一的区别在于数据库中存储的诊断规则树是不同，以及状态流转也不同。

参照图5，图5为本申请实施例中作业流或作业诊断分析流程示意图。

在一些实施例中，上述作业流或作业诊断分析流程包括：

S501、确定所述诊断请求中是否存在实例id、开始时间和结束时间，所述实例id、开始时间和结束时间是作业流实例或作业实例的。

在一些实施例中，验证诊断类型和诊断请求中是否有实例id和开始时间和结束时间，给出时间范围是为了根据范围来获取不同数据区的数据，比如作业实例业务指标数据在ElasticSearch中可能会存储在多个时间日期的index，所以需要确定范围。

S502、若所述诊断请求中存在实例id、开始时间和结束时间，则遍历所述诊断规则树的各个节点，并在遍历到的各个节点遍历所述目标指标数据。

在一些实施例中，若所述诊断请求中存在实例id、开始时间和结束时间，则从第二数据库中获取诊断规则，根据获的取诊断规则，组装成诊断规则树；若所述诊断请求中不存在实例id、开始时间和结束时间，则返回请求失败，提示报文内容错误。

在一些实施例中，从第一数据库中按照实例状态、实例id、开始时间和结束时间来获取指标数据并转换成列表，可以对List按照zxid排序，由于zxid越大，表示指标越新，然后再根据操作对象，操作数和操作结果来进行去重。

S503、如果所述目标指标数据中存在指标的实例状态满足当前遍历到的节点的诊断规则，则将当前遍历到的节点添加至诊断结果列表。

在一些实施例中，遍历所有作业流/作业实例状态值，这里遍历顺序由流转顺序来确定。

按照树的广度优先搜索算法，遍历诊断规则树的部分节点，这里需要先初始化一个partQueue，其中包含诊断规则树中当前循环的实例状态的根节点。然后以广度优先搜索算法，每一个节点都遍历该实例的所有指标数据，如果有指标的实例状态与当前节点的规则适用条件一致，而且指标的操作与当前节点的规则明细一致，那么则将该节点加入到诊断结果列表中。

如果指标中具备errMsg或者errCausedReason，那么需要在指标输出时将级别转换成ERROR，否则级别默认是INFO，展示的都是指标内容，即调度操作记录。

S504、根据所述诊断结果列表，生成所述诊断报告。

对应每一种实例状态，进行广度优先搜索最后汇总得到诊断结果列表，还需要遍历诊断结果列表，对于作业监控的指标数据，需要只保留第一次监控结果和最后一次监控结果，以美化显示。

将所有指标结果按照“指标上报时间，信息级别，指标内容”按序写入到文件中，然后返回请求成功，并附上文件地址给调度***。

经过以上步骤，最后形成的作业流/作业诊断报告格式如下：

2021-0615 18:58:11.367INFO拉取作业依赖核查事件消息成功；

2021-0615 18:58:11.368INFO作业前置依赖已就绪，更新作业示例状态为ready；

2021-0615 18:58:11.369INFO作业没有挂起，准备推送到作业优先级队列；

2021-0615 18:58:11.369INFO作业实例转换成优先级对象，将优先级对象放到Redis优先级队列成功；

2021-0615 18:58:12.007INFO获取租户锁成功；

……

在一些实施例中，相比于作业流/作业诊断分析，调度服务诊断分析的诊断规则没有树状层级关系，参照图6，图6为本申请实施例中服务指标诊断分析流程示意图。

在一些实施例中，上述作业流或作业诊断分析流程包括：

S601、确定所述诊断请求中是否存在调度模块名称。

在一些实施例中，在接收到诊断请求时，先验证诊断类型和诊断请求中是否带有特定的模块名称，若是，那么服务诊断分析就只分析该模块特定的指标数据，否则分析所有服务指标数据。

S602、当所述诊断请求中存在调度模块名称时，遍历所述诊断规则列表中的各个诊断规则，并在遍历到的各个诊断规则时，遍历所述目标指标数据。

在一些实施例中，可以从第二数据库获取诊断规则，并转换成诊断规则列表。同时，从数据库中获取所有服务诊断规则，并转换为列表。

遍历所有服务诊断规则，对于每一个规则，遍历所有服务指标数据，如果规则使用条件的表达式匹配当前的指标名称，而且根据诊断规则可得出该服务指标数据满足规则约束关系，那么就将指标记录到诊断结果列表中，并将规则的info_tips添加到指标内容，否则将指标记录到结果List中，并将输出级别从默认INFO改成ERROR，并同时加规则的err_tips添加到指标内容中。

S603、如果所述目标指标数据中当前遍历到的服务指标满足当前遍历到的诊断规则，则将当前遍历到的服务指标添加至预设诊断结果列表。

S604、根据所述诊断结果列表，生成所述诊断报告。

在一些实施例中，在遍历结束后，将诊断结果列表中所有指标数据写入到文件中，然后返回请求成功，并附上文件地址。

经过以上步骤，当诊断请求为调度执行机时，最终形成的关于调度执行机的诊断部分报告如下：

2021-0615 18:57:12.156INFO执行模块心跳上报正常executor_heartbeat_time2021-06-15 18:57:08；

2021-0615 18:58:16.303INFO执行模块心跳上报正常executor_heartbeat_time2021-06-15 18:58:10；

2021-0615 18:58:12.231INFO执行模块运行实例平均耗时小于30ms executor_job_run_time 2021-06-15 18:58:10；

……

在一些实施例中，在微服务架构下，可以让调度***和指标诊断模块都部署于Kubernetes的容器环境中，并加入了Nginx服务来做流量的负载均衡和转发。由于调度***和指标诊断模块通过http解耦，即包括指标上报和诊断请求都会经过Nginx，对于调度***来说，访问的都是同一个服务域名，但不知道具体访问的是哪一个指标诊断模块。每一个指标诊断模块是彼此独立且逻辑一致，访问的都是同一个influxDB或者ElasticSearch后端数据库。当流量大时，流量带宽会超过预先设置的阈值，此时就会触发Kubernetes预先配置好的AutoScale机制，自动地对指标诊断模块进行水平扩容。而当流量小时，该机制就会对模块进行水平缩容。

本申请中，只需要用户按照数据库表的字段格式，以json的格式组装数据，并自行确认好诊断规则的内容。第一次请求接口时，关系型数据库中没有数据，那么会直接解析用户发送报文中的规则数据来作为初始化数据。后续请求接口时，会遍历用户发送报文中的规则数据，如果不存在数据表中，则会***数据表，如果存在，则会以用户发送报文信息为准更新库表。

本申请提供的调度***的指标聚合方法，具备以下优势：

在常见的聚合指标之外，抽象并扩展了单一作业流或者作业对应调度各阶段的业务指标，并通过定义和构建调度业务规则树来形成对指标数据的清洗，剪枝和加工，最后形成对应作业流或作业的诊断报告。

通过定义构建服务指标规则树，等价于对聚合指标数据的展示模版，根据模版来对现有的多种指标数据进行清洗和加工，最后形成对应调度服务的整体诊断报告。

支持微服务架构下以流量多少灵活的扩容服务节点，与调度***通过http方式进行解耦，降低对调度性能的影响。

支持调度***通过修改配置文件的方式灵活地开启和关闭是否上报指标和支持诊断分析。

基于上述实施例中所描述的内容，本申请实施例中还提供一种调度***的故障诊断装置，参照图7，图7为本申请实施例中提供的一种调度***的故障诊断装置的程序模块示意图，该调度***的故障诊断装置包括：

指标聚合模块701，用于接收调度***发送的指标数据，并对接收到的所述指标数据进行聚合处理后，将聚合处理后的指标数据上传至第一数据库。

诊断分析模块702，用于在接收到用户发送的诊断请求时，根据所述诊断请求对应的诊断类型，从第二数据库中获取目标诊断规则，所述诊断请求对应的诊断类型包括作业流诊断、作业诊断以及调度服务诊断中的任意一种；

根据所述诊断类型从所述第一数据库中获取诊断所需的目标指标数据，并根据所述目标诊断规则，对所述目标指标数据进行处理，以得到诊断报告；

将所述诊断报告的文件地址发送至所述调度***。

需要说明的是，本申请实施例中的指标聚合模块701与诊断分析模块702具体执行的内容可以参阅上述实施例中的相关内容，此处不做赘述。

进一步的，基于上述实施例中所描述的内容，本申请实施例中还提供了一种电子设备，该电子设备包括至少一个处理器和存储器；其中，存储器存储计算机执行指令；上述至少一个处理器执行存储器存储的计算机执行指令，以实现如上述实施例中所描述的调度***的故障诊断的各个步骤，本实施例此处不再赘述。

为了更好的理解本申请实施例，参照图8，图8为本申请实施例提供的一种电子设备的硬件结构示意图。

如图8所示，本实施例的电子设备80包括：处理器801以及存储器802；其中：

存储器802，用于存储计算机执行指令；

处理器801，用于执行存储器存储的计算机执行指令，以实现上述实施例中所描述的调度***的故障诊断的各个步骤，本实施例此处不再赘述。

可选地，存储器802既可以是独立的，也可以跟处理器801集成在一起。

当存储器802独立设置时，该设备还包括总线803，用于连接所述存储器802和处理器801。

进一步的，基于上述实施例中所描述的内容，本申请实施例中还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，以实现如上述实施例中所描述的调度***的故障诊断的各个步骤，本实施例此处不再赘述。

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

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

另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。上述模块集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。

应理解，上述处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application Specific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称：ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (12)

1.一种调度***的故障诊断方法，其特征在于，所述方法包括：

接收调度***发送的指标数据，并对接收到的所述指标数据进行聚合处理后，将聚合处理后的指标数据上传至第一数据库；

在接收到用户发送的诊断请求时，根据所述诊断请求对应的诊断类型，从第二数据库中获取目标诊断规则，所述诊断请求对应的诊断类型包括作业流诊断、作业诊断以及调度服务诊断中的任意一种；

根据所述诊断类型从所述第一数据库中获取诊断所需的目标指标数据，并根据所述目标诊断规则，对所述目标指标数据进行处理，以得到诊断报告；

将所述诊断报告的文件地址发送至所述调度***。

2.根据权利要求1所述的方法，其特征在于，所述根据所述诊断类型从所述第一数据库中获取诊断所需的目标指标数据，包括：

当所述诊断请求对应的诊断类型为所述作业流诊断或所述作业诊断时，根据所述诊断请求中的作业流运行起始时间，从所述第一数据库中获取指定时间范围内上传的指标数据为所述目标指标数据；

当所述诊断请求对应的诊断类型为所述调度服务诊断时，从所述第一数据库获取当前最新上传的指标数据为所述目标指标数据。

3.根据权利要求2所述的方法，其特征在于，所述根据所述目标诊断规则，对所述目标指标数据进行处理，以得到诊断报告，包括：

当所述诊断请求对应的诊断类型为所述作业流诊断或所述作业诊断时，确定所述调度***的状态流转过程，根据所述状态流转过程确定出所述调度***的状态流转图，所述状态流转图为树状结构；

将所述目标诊断规则分别添加至所述状态流转图中的各个节点，生成诊断规则树；

根据所述诊断规则树，对所述目标指标数据进行处理，以得到诊断报告。

4.根据权利要求3所述的方法，其特征在于，所述根据所述诊断规则树，对所述目标指标数据进行处理，以得到诊断报告，包括：

确定所述诊断请求中是否存在实例id、开始时间和结束时间，所述实例id、开始时间和结束时间是作业流实例或作业实例的；

若所述诊断请求中存在实例id、开始时间和结束时间，则遍历所述诊断规则树的各个节点，并在遍历到的各个节点遍历所述目标指标数据；

如果所述目标指标数据中存在指标的实例状态满足当前遍历到的节点的诊断规则，则将当前遍历到的节点添加至诊断结果列表；

根据所述诊断结果列表，生成所述诊断报告。

5.根据权利要求2所述的方法，其特征在于，所述根据所述目标诊断规则，对所述目标指标数据进行处理，以得到诊断报告，包括：

当所述诊断请求对应的诊断类型为所述调度服务诊断时，根据所述目标诊断规则生成诊断规则列表；

根据所述诊断规则列表，对所述目标指标数据进行处理，以得到诊断报告。

6.根据权利要求5所述的方法，其特征在于，所述根据所述诊断规则列表，对所述目标指标数据进行处理，以得到诊断报告，包括：

确定所述诊断请求中是否存在调度模块名称；

当所述诊断请求中存在调度模块名称时，遍历所述诊断规则列表中的各个诊断规则，并在遍历到的各个诊断规则时，遍历所述目标指标数据；

如果所述目标指标数据中当前遍历到的服务指标满足当前遍历到的诊断规则，则将当前遍历到的服务指标添加至预设诊断结果列表；

根据所述诊断结果列表，生成所述诊断报告。

7.根据权利要求1所述的方法，其特征在于，所述接收调度***发送的指标数据，包括：

接收所述调度***发送的报文，所述报文中包括以下信息中的至少一种：指标名称、指标发送时间、指标类型、指标操作数、指标操作对象、指标操作结果、实例id、实例状态、全局唯一id、指标内容、操作步骤错误原因、错误具体信息、调度模块名称、模块网络IP；

根据所述报文解析出所述指标数据。

8.根据权利要求1所述的方法，其特征在于，所述指标数据包括调度业务指标数据和调度服务指标数据；

所述调度业务指标数据包括所述调度***中的作业流和作业实例从创建到销毁的全流程的埋点记录指标数据；

所述调度服务指标数据包括所述调度***中的调度服务的性能指标数据，所述调度***中的调度服务指标数据的类型包括标量型、计数型和计时型。

9.根据权利要求1所述的方法，其特征在于，还包括：

根据接收到的诊断规则报文，在所述第二数据库中新增诊断规则，或修改所述第二数据库中存储的诊断规则。

10.一种调度***的故障诊断装置，其特征在于，包括：

指标聚合模块，用于接收调度***发送的指标数据，并对接收到的所述指标数据进行聚合处理后，将聚合处理后的指标数据上传至第一数据库；

诊断分析模块，用于在接收到用户发送的诊断请求时，根据所述诊断请求对应的诊断类型，从第二数据库中获取目标诊断规则，所述诊断请求对应的诊断类型包括作业流诊断、作业诊断以及调度服务诊断中的任意一种；

所述诊断分析模块，还用于根据所述诊断类型从所述第一数据库中获取诊断所需的目标指标数据，并根据所述目标诊断规则，对所述目标指标数据进行处理，以得到诊断报告；

所述诊断分析模块，还用于将所述诊断报告的文件地址发送至所述调度***。

11.一种电子设备，其特征在于，包括：至少一个处理器和存储器；

所述存储器存储计算机执行指令；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如权利要求1至9任一项所述的调度***的故障诊断方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如权利要求1至9任一项所述的调度***的故障诊断方法。

Images