定时任务的监测方法、装置、服务器及可读存储介质与流程

1.本发明涉及数据监控技术领域，具体涉及一种定时任务的监测方法、装置、服务器及可读存储介质。


背景技术：

2.系统的定时任务需要进行实时监控，以确定系统的定时任务能够按时、正确执行。现有的定时任务监控通常是通过“定时任务探测引擎”获取系统定时任务的触发批次以及执行状态，然后推送给“指标暴露”组件，以对将定时任务的监控数据进行暴露。然而，当“定时任务探测引擎”本身故障时，由于无法探测定时任务的触发和执行情况，从而无法推送定时任务的更新信息至“指标暴露”组件，进而使得“指标暴露”组件中的数据保持不变，导致服务监控系统prometheus难以拉取最新数据，从而难以及时发现定时任务的执行问题并触发告警。


技术实现要素：

3.有鉴于此，本发明实施例提供了一种定时任务的监测方法、装置、服务器及可读存储介质，以解决现有的监测方法难以及时发现定时任务的执行问题并触发告警的问题。
4.根据第一方面，本发明实施例提供了一种定时任务的监测方法，包括如下步骤：获取定时任务的期望数据以及实际监测数据，，所述期望数据用于反映执行所述定时任务的预期数据，所述实际监测数据用于反映执行所述定时任务的实际数据；判断所述期望数据与所述实际监测数据是否相匹配；在所述期望数据与所述实际监测数据不匹配的情况下，确定定时任务未触发，暴露所述期望数据、实际监测数据对应的指标数据。
5.本发明实施例提供的定时任务的监测方法，通过获取定时任务的期望数据与实际监测数据，将期望数据与实际监测数据进行比较，确定期望数据与实际监测数据是否相匹配。在确定期望数据与实际监测数据不匹配时，判定定时任务并未触发，并对期望数据以及实际监测数据对应的指标数据进行暴露。该方法通过获取定时任务的期望数据与实际监测数据，避免了实际监测数据无法探测而难以监测定时任务的触发和执行问题，实现了对定时任务的触发和执行的实时监测，从而能够及时推送定时任务对应的指标数据，以使监控程序能够拉取到最新的监控数据以及时发现定时任务存在的执行问题。
6.结合第一方面，在第一方面的第一实施方式中，获取定时任务的期望数据，包括：获取定时任务对应的期望触发时间点以及期望运行状态；基于所述期望触发时间点以及所述期望运行状态，确定与所述期望触发时间点以及所述期望运行状态对应的期望数据。
7.本发明实施例提供的定时任务的监测方法，通过获取定时任务对应的期望触发时间点以及期望运行状态，基于期望触发时间点以及期望运行状态，确定与期望触发时间点以及期望运行状态对应的期望数据，以便准确确定定时任务是否定时触发，进而保证了定时任务能够正确执行。
8.结合第一方面第一实施方式，在第一方面的第二实施方式中，所述期望数据包括：
期望触发时间和期望执行成功时间。
9.结合第一方面，在第一方面的第三实施方式中，所述实际监测数据包括：所述定时任务的触发时间和所述定时任务的执行成功时间。
10.结合第一方面或第一方面第一实施方式至第二实施方式或第三实施方式，在第一方面的第四实施方式中，所述定时任务的监测方法还包括：当所述期望数据与所述实际监测数据匹配时，更新所述实际监测数据，暴露所述期望数据及更新后的实际监测数据对应的指标数据。
11.本发明实施例提供的定时任务的监测方法，当期望数据与实际监测数据匹配时，更新实际监测数据，暴露期望数据及更新后的实际监测数据对应的指标数据，以便准确确定定时任务已定时触发，保证了定时任务的实际监测数据能够实时更新并被准确拉取。
12.根据第二方面，本发明实施例提供了一种定时任务的监测装置，包括：定时引擎模块，用于获取定时任务的期望数据，所述期望数据用于反映执行所述定时任务的预期数据；定时任务探测引擎模块，用于获取定时任务的实际监测数据，所述实际监测数据用于反映执行所述定时任务的实际数据；判断模块，用于判断所述期望数据与所述实际监测数据是否相匹配；判定模块，用于在所述期望数据与所述实际监测数据不匹配的情况下，确定定时任务未触发，暴露所述期望数据、实际监测数据对应的指标数据。
13.本发明实施例提供的定时任务的监测装置，通过获取定时任务的期望数据与实际监测数据，将期望数据与实际监测数据进行比较，确定期望数据与实际监测数据是否匹配。当确定期望数据与实际监测数据不匹配时，判定定时任务并未触发，并对期望数据以及实际监测数据对应的指标数据进行暴露。该装置通过获取定时任务的期望数据与实际监测数据，避免了实际监测数据无法探测而难以监测定时任务的触发和执行问题，实现了对定时任务的触发和执行的实时监测，从而能够及时推送定时任务对应的指标数据，以使监控程序能够拉取到最新的监控数据以及时发现定时任务存在的执行问题。
14.结合第二方面，在第二方面的第一实施方式中，所述定时引擎模块，包括：获取子模块，用于获取定时任务对应的期望触发时间点以及期望运行状态；确定子模块，用于基于所述期望触发时间点以及所述期望运行状态，确定与所述期望触发时间点以及所述期望运行状态对应的期望数据。
15.本发明实施例提供的定时任务的监测装置，通过获取定时任务对应的期望触发时间点以及期望运行状态，并确定与期望触发时间点以及期望运行状态对应的期望数据，以便准确确定定时任务是否定时触发，进而保证了定时任务能够正确执行。
16.根据第三方面，本发明实施例提供了一种定时任务的监测系统，包括：触发告警服务模块及如第二方面或第二方面第一实施方式所述的定时任务的监测装置，其中，所述定时任务的监测装置，用于判定定时任务是否触发；所述触发告警服务模块用于定时任务未触发时发出nodata告警。
17.本发明实施例提供的定时任务的监测系统，通过获取定时任务的期望数据与实际监测数据，避免了实际监测数据无法探测而难以监测定时任务的触发和执行问题，实现了对定时任务的触发和执行的实时监测，从而能够及时推送定时任务对应的指标数据，以使监控程序能够拉取到最新的监控数据以及时发现定时任务存在的执行问题。当检测到定时任务未触发时，通过触发告警服务模块发出nodata告警，以便及时发现定时任务的执行问
题。
18.根据第四方面，本发明实施例提供了一种服务器，包括：存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令，从而执行第一方面或第一方面任一实施方式所述的定时任务的监测方法。
19.根据第五方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使计算机执行第一方面或第一方面任一实施方式所述的定时任务的监测方法。
附图说明
20.为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
21.图1是根据本发明实施例的定时任务的监测方法的流程图；
22.图2是根据本发明实施例的定时任务的监测方法的另一流程图；
23.图3是根据本发明实施例的定时任务的监测装置的结构框图；
24.图4是根据本发明实施例的定时任务的监测装置的另一结构框图；
25.图5是根据本发明实施例定时任务的监测系统的结构框图；
26.图6是本发明实施例提供的服务器的硬件结构示意图。
具体实施方式
27.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
28.现有的定时任务监控通常是通过“定时任务探测引擎”获取系统定时任务的触发批次以及执行状态，然后推送给“指标暴露”组件，以对将定时任务的监控数据进行暴露。然而，当“定时任务探测引擎”本身故障时，由于无法探测定时任务的触发和执行情况，从而无法推送定时任务的更新信息至“指标暴露”组件，进而使得“指标暴露”组件中的数据保持不变，导致服务监控系统prometheus难以拉取最新数据，从而难以及时发现定时任务的执行问题并触发告警。
29.基于此，本发明技术方案通过获取定时任务的期望数据与实际监测数据，避免了实际监测数据无法探测而难以监测定时任务的触发和执行问题，实现了对定时任务的触发和执行的实时监测。
30.根据本发明实施例，提供了一种定时任务的监测方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
31.在本实施例中提供了一种定时任务的监测方法，可用于服务器中，如计算机服务器构成的监测系统或监测平台等，图1是根据本发明实施例的定时任务的监测方法的流程图，如图1所示，该流程包括如下步骤：
32.s11，获取定时任务的期望数据以及实际监测数据，其中，期望数据用于反映执行定时任务的预期数据，实际监测数据用于反映执行定时任务的实际数据。
33.定时任务为计算机系统定时执行的任务。例如，每天2：00发送前一日报表。定时任务对应的任务数据存储于时序数据库中，且时序数据库中每条数据均有时间戳。其中，时序数据库是按照时间顺序产生的数据并提供查询功能的数据库，例如prometheus、opentsdb等，本技术对此不作具体限定。
34.期望数据为执行定时任务所产生的预期数据，即相应时间任务正常触发执行的数据。期望数据可以包括执行定时任务产生的日志条目、定时任务对应的数据库数据以及邮件数据中的一种或多种。例如，每天2：00发送前一日报表，则预期报表数据即为定时任务对应的期望数据。期望数据可以自动执行探测程序获取。具体地，期望数据可以是扫描定时任务输出的日志，可以是查询数据库里是否有相应的数据，或通过指定邮箱接收邮件数据。
35.实际监测数据为执行定时任务实际产生的数据。实际监测数据中包括定时任务的触发时间以及定时任务的执行成功时间。例如，每天2：00发送前一日报表，则实际监测数据中包括该发送前一日报表的触发时间以及报表发送完成的时间，同时还包括实际发送的报表数据。
36.s12，判断期望数据与实际监测数据是否相匹配。
37.将期望数据与实际监测数据进行对比，确定期望数据与实际监测数据是否匹配，当期望数据与实际监测数据不匹配时，执行步骤s13，否则，执行其他操作。其他操作可以为存储实际监测数据，也可以为继续获取实际监测数据进行期望数据与实际监测数据的判断，此处不作具体限定。
38.s13，判定定时任务未触发，暴露期望数据、实际监测数据对应的指标数据。
39.当期望数据与实际监测数据不匹配时，表示定时任务并未被触发，并对期望数据以及实际监测数据对应的指标数据进行暴露。其中，指标数据为执行定时任务产生的监控数据。
40.具体地，服务器可以获取定时任务的触发批次以及定时任务的执行状态，然后推送给指标数据暴露程序，并由暴露程序对定时任务的触发批次以及定时任务的执行状态对应的监控数据进行暴露。例如，定时任务每10分钟触发一次，执行定时任务对应的期望监控值为1，表示定时任务的执行状态正常。若执行定时任务对应的实际监控值为0，则表示定时任务的期望数据与实际监测数据不匹配，表示定时任务并未触发，即定时任务的执行状态不正常。此时，将期望数据以及实际监测数据对应的指标数据推送至指标数据暴露程序，由指标数据暴露程序对期望数据以及实际监测数据对应的指标数据进行暴露。
41.本发明实施例提供的定时任务的监测方法，通过获取定时任务的期望数据与实际监测数据，将期望数据与实际监测数据进行比较，确定期望数据与实际监测数据是否匹配。当确定期望数据与实际监测数据不匹配时，判定定时任务并未触发，并对期望数据以及实际监测数据对应的指标数据进行暴露。该方法通过获取定时任务的期望数据与实际监测数据，避免了实际监测数据无法探测而难以监测定时任务的触发和执行问题，实现了对定时
任务的触发和执行的实时监测，从而能够及时推送定时任务对应的指标数据，以使监控程序能够拉取到最新的监控数据以及时发现定时任务存在的执行问题。
42.在本实施例中提供了一种定时任务的监测方法，可用于服务器中，如计算机服务器构成的监测系统或监测平台等，图2是根据本发明实施例的定时任务的监测方法的流程图，如图2所示，该流程包括如下步骤：
43.s21，获取定时任务的期望数据以及实际监测数据。
44.具体地，上述步骤s21可以包括如下步骤：
45.s211，获取定时任务对应的期望触发时间点以及期望运行状态。
46.期望触发时间点为定时任务对应的触发时间。期望运行状态为定时任务触发后的运行信息。例如，定时任务每10分钟触发一次，则期望触发时间点可以为12:00、12:10、12:20、12:30等。对于定时任务的详细说明参见上述实施例对应的相关描述，此处不再赘述。
47.s212，基于期望触发时间点以及期望运行状态，确定与期望触发时间点以及期望运行状态对应的期望数据。
48.对应于定时任务的期望触发时间点，可以得到每个定时任务在期望触发时间点触发后，执行该定时任务所对应的期望运行状态。对于期望数据的详细说明参见上述实施例对应的相关描述，此处不再赘述。例如，定时任务的执行需要1分钟，则在12:00触发该定时任务后，可以得到该定时任务在12:00至12:01之间执行的期望运行状态。
49.s213，获取定时任务的实际监测数据。详细说明参见上述实施例对应的相关描述，此处不再赘述。
50.s22，判断期望数据与实际监测数据是否相匹配。
51.将期望数据与实际监测数据进行对比，确定期望数据与实际监测数据是否匹配，当期望数据与实际监测数据不匹配时，执行步骤s13，否则执行步骤s14。
52.s23，判定定时任务未触发，暴露期望数据、实际监测数据对应的指标数据。详细说明参见上述实施例对应的相关描述，此处不再赘述。
53.s24，更新实际监测数据，暴露期望数据及更新后的实际监测数据对应的指标数据。
54.当期望数据与实际监测数据匹配时，表示定时任务已被触发且该定时任务处于正常执行状态，此时，可以对时序数据库中对应于该定时任务的实际监测数据进行更新，并将更新后的实际监测数据推送至指标数据暴露程序，以使指标数据暴露程序对该定时任务对应的期望数据以及更新后的实际监测数据进行暴露。
55.具体地，若定时任务每10分钟触发一次，监控值为1，表示定时任务的执行状态正常。当定时任务未正常执行时，推送给指标数据暴露程序的监控指标数据的格式如下所示：
56.sched_gfs_task_status{time＝”2020-11-12.12:00”}＝1
57.sched_gfs_task_status{time＝”2020-11-12.12:20”}＝1
58.sched_gfs_task_status{time＝”2020-11-12.12:30”}＝1
59.当定时任务未正常执行时，推送给指标数据暴露程序的监控指标数据的格式如下：
60.sched_gfs_task_status{time＝”2020-11-12.12:10”}＝0
61.此时，可以触发告警，以使技术人员能够及时采取相应的解决措施。
62.本发明实施例提供的定时任务的监测方法，通过获取定时任务的期望数据与实际监测数据，以便准确确定定时任务是否定时触发，进而保证了定时任务能够正确执行。将期望数据与实际监测数据进行比较，当确定期望数据与实际监测数据不匹配时，判定定时任务并未触发，并对期望数据以及实际监测数据对应的指标数据进行暴露，避免了实际监测数据无法探测而难以监测定时任务的触发和执行问题，实现了对定时任务的触发和执行的实时监测，从而能够及时推送定时任务对应的指标数据，以使监控程序能够拉取到最新的监控数据以及时发现定时任务存在的执行问题；当期望数据与实际监测数据匹配时，更新实际监测数据，暴露期望数据及更新后的实际监测数据对应的指标数据，以便准确确定定时任务已定时触发，保证了定时任务的实际监测数据能够实时更新并被准确拉取。
63.在本实施例中还提供了一种定时任务的监测装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
64.本实施例提供一种定时任务的监测装置，如图3所示，包括：
65.定时引擎模块31，用于获取定时任务的期望数据，期望数据用于反映执行定时任务的预期数据。详细说明参见上述实施例对应的相关描述，此处不再赘述。
66.定时任务探测引擎模块32，用于获取定时任务的实际监测数据，实际监测数据用于反映执行定时任务的实际数据。详细说明参见上述实施例对应的相关描述，此处不再赘述。
67.判断模块33，用于判断期望数据与实际监测数据是否相匹配。详细说明参见上述实施例对应的相关描述，此处不再赘述。
68.判定模块34，用于在期望数据与实际监测数据不匹配的情况下，确定定时任务未触发，暴露期望数据、实际监测数据对应的指标数据。详细说明参见上述实施例对应的相关描述，此处不再赘述。
69.本发明实施例提供的定时任务的监测装置，通过获取定时任务的期望数据与实际监测数据，避免了实际监测数据无法探测而难以监测定时任务的触发和执行问题，实现了对定时任务的触发和执行的实时监测，从而能够及时推送定时任务对应的指标数据，以使监控程序能够拉取到最新的监控数据以及时发现定时任务存在的执行问题。
70.本实施例提供一种定时任务的监测装置，如图4所示，包括：
71.定时引擎模块41，用于获取定时任务的期望数据。
72.具体地，定时引擎模块41，包括：
73.第一获取子模块411，用于获取定时任务对应的期望触发时间点。详细说明参见上述实施例对应的相关描述，此处不再赘述。
74.确定子模块412，用于基于期望触发时间点，确定与期望触发时间点对应的期望数据。详细说明参见上述实施例对应的相关描述，此处不再赘述。
75.第二获取子模块413，用于获取定时任务的实际监测数据。详细说明参见上述实施例对应的相关描述，此处不再赘述。
76.定时任务探测引擎模块42，用于获取定时任务的实际监测数据。详细说明参见上述实施例对应的相关描述，此处不再赘述。
77.判断模块43，用于判断期望数据与实际监测数据是否匹配。详细说明参见上述实施例对应的相关描述，此处不再赘述。
78.判定模块44，用于当期望数据与实际监测数据不匹配时，判定定时任务未触发，暴露期望数据、实际监测数据对应的指标数据。详细说明参见上述实施例对应的相关描述，此处不再赘述。
79.本发明实施例提供的定时任务的监测装置，通过获取定时任务对应的期望触发时间点，基于期望触发时间点，确定与期望触发时间点对应的期望数据，以便准确确定定时任务是否定时触发，进而保证了定时任务能够正确执行。
80.本实施例中的定时任务的监测装置是以功能单元的形式来呈现，这里的单元是指asic电路，执行一个或多个软件或固定程序的处理器和存储器，和/或其他可以提供上述功能的器件。
81.上述各个模块的更进一步的功能描述与上述对应实施例相同，在此不再赘述。
82.本发明实施例还提供一种定时任务的监测系统，如图5所示，图5是本发明可选实施例提供的一种定时任务的监测系统的结构框图，该系统包括：触发告警服务模块51和定时任务的监控装置52。其中，触发告警服务模块51用于定时任务未触发时发出nodata告警。具体地，定时任务的监测系统可以设定获取到监控数据为正常执行状态，没有监控数据则认为故障发生，触发告警。
83.本发明实施例提供的定时任务的监测系统，通过获取定时任务的期望数据与实际监测数据，避免了实际监测数据无法探测而难以监测定时任务的触发和执行问题，实现了对定时任务的触发和执行的实时监测，从而能够及时推送定时任务对应的指标数据，以使监控程序能够拉取到最新的监控数据以及时发现定时任务存在的执行问题。当检测到定时任务未触发时，通过触发告警服务模块发出nodata告警，以便及时发现定时任务的执行问题。
84.本发明实施例还提供一种服务器，具有上述图3或图4所示的定时任务的监测装置。
85.请参阅图6，图6是本发明可选实施例提供的一种服务器的结构示意图，如图6所示，该服务器可以包括：至少一个处理器601，例如cpu(central processing unit，中央处理器)，至少一个通信接口603，存储器604，至少一个通信总线602。其中，通信总线602用于实现这些组件之间的连接通信。其中，通信接口603可以包括显示屏(display)、键盘(keyboard)，可选通信接口603还可以包括标准的有线接口、无线接口。存储器604可以是高速ram存储器(random access memory，易挥发性随机存取存储器)，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器604可选的还可以是至少一个位于远离前述处理器601的存储装置。其中处理器601可以结合图3或图4所描述的装置，存储器604中存储应用程序，且处理器601调用存储器604中存储的程序代码，以用于执行上述任一方法步骤。
86.其中，通信总线602可以是外设部件互连标准(peripheral component interconnect，简称pci)总线或扩展工业标准结构(extended industry standard architecture，简称eisa)总线等。通信总线602可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
87.其中，存储器604可以包括易失性存储器(英文：volatile memory)，例如随机存取存储器(英文：random-access memory，缩写：ram)；存储器也可以包括非易失性存储器(英文：non-volatile memory)，例如快闪存储器(英文：flash memory)，硬盘(英文：hard disk drive，缩写：hdd)或固态硬盘(英文：solid-state drive，缩写：ssd)；存储器604还可以包括上述种类的存储器的组合。
88.其中，处理器601可以是中央处理器(英文：central processing unit，缩写：cpu)，网络处理器(英文：network processor，缩写：np)或者cpu和np的组合。
89.其中，处理器601还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(英文：application-specific integrated circuit，缩写：asic)，可编程逻辑器件(英文：programmable logic device，缩写：pld)或其组合。上述pld可以是复杂可编程逻辑器件(英文：complex programmable logic device，缩写：cpld)，现场可编程逻辑门阵列(英文：field-programmable gate array，缩写：fpga)，通用阵列逻辑(英文：generic array logic,缩写：gal)或其任意组合。
90.可选地，存储器604还用于存储程序指令。处理器601可以调用程序指令，实现如本技术图1和2实施例中所示的定时任务的监测方法。
91.本发明实施例还提供了一种非暂态计算机存储介质，所述计算机存储介质存储有计算机可执行指令，该计算机可执行指令可执行上述任意方法实施例中的定时任务的监测方法的处理方法。其中，所述存储介质可为磁碟、光盘、只读存储记忆体(read-only memory，rom)、随机存储记忆体(random access memory，ram)、快闪存储器(flash memory)、硬盘(hard disk drive，缩写：hdd)或固态硬盘(solid-state drive，ssd)等；所述存储介质还可以包括上述种类的存储器的组合。
92.虽然结合附图描述了本发明的实施例，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。