CN103246551A

CN103246551A - 用于管理后台定时任务的设备和方法

Info

Publication number: CN103246551A
Application number: CN2012100314476A
Authority: CN
Inventors: 占志成
Original assignee: BEIJING NUOMI WANG TECHNOLOGY DEVELOPMENT Co Ltd
Current assignee: BEIJING NUOMI WANG TECHNOLOGY DEVELOPMENT Co Ltd
Priority date: 2012-02-07
Filing date: 2012-02-07
Publication date: 2013-08-14

Abstract

本发明的实施方式涉及用于管理后台定时任务的设备和方法。特别地，公开了一种用于管理运行于计算系统中的后台定时任务的设备，包括：至少一个接口模块，每个接口模块配置用于可操作地与相应后台定时任务耦合和通信；状态收集模块，配置用于通过所述至少一个接口模块收集相应后台定时任务的运行状态参数；以及任务监控模块，配置用于基于所述运行状态参数来监控相应后台定时任务。还公开了相应的方法。根据本发明的实施方式，可以更为便捷有效地监控计算系统中运行的后台定时任务。

Description

用于管理后台定时任务的设备和方法

技术领域

本发明的实施方式总体上涉及信息技术领域，更具体地，涉及用于管理后台定时任务的设备和方法。

背景技术

在很多计算系统中都存在运行于后台的定时任务，对于大型计算系统而言尤其如此。注意，在此使用的术语“任务”是指可以驻留和运行于计算系统(例如，计算机)中的应用、程序、过程、处理、进程或线程等。顾名思义，后台定时任务具有两个基本特性。第一，此类任务运行于计算系统的后台，通常不具有、也不需要与用户发生交互的用户界面。实际上，后台定时任务的运行通常不需要用户显式地输入任何命令或指示，这与诸如文字编辑、Web浏览器等前台任务具有显著区别。后台定时任务的第二个主要特性是：此类任务是定时触发的，通常用于根据预先设定的周期来执行诸如数据抽取、缓存请求、异步请求等操作。换言之，在执行周期中，此类任务不断地在活跃与不活跃周期之间交替。

由于后台定时任务的上述两个特点，如何有效地管理和监控后台定时任务始终是本领域的一个重要问题。由于不具有界面，用户无法通过直观的方式对此类任务加以监管。而且，这类任务的启动是周期性的，在其不活跃周期中，很难判定该任务是否处于正常状态，即，是否能够正确地在恰当的时间启动进入活跃周期。

在现有技术中，后台定时任务的管理和监控通常是由任务本身来完成的。例如，此类后台定时任务可以不断地检测自身或其某些部分是否发生了异常。如果检测到此类异常，则可以通过计算系统的上层软件(例如，操作系统OS)向用户发出告警。然而，当任务或者所在的计算系统发生严重错误时，这种自检测很有可能失效。而且，大型计算系统的后台往往运行着成百上千此类任务。如果由每个任务各自独立地监控，由于处理策略和告警方式的差异，很可能导致管理方面的不利甚至混乱。

因此，本领域需要一种在网站中更为有效地管理后台定时任务的技术方案。

发明内容

鉴于以上问题，本发明提出一种用于管理后台定时任务的新方案。

在本发明的一方面，提供一种用于管理运行于计算系统中的后台定时任务的设备。该设备包括：至少一个接口模块，每个接口模块配置用于可操作地与相应后台定时任务耦合和通信；状态收集模块，配置用于通过所述至少一个接口模块收集相应后台定时任务的运行状态参数；以及任务监控模块，配置用于基于所述运行状态参数来监控相应后台定时任务。

在本发明的另一方面，提供一种用于管理运行于计算系统中的后台定时任务的方法。该方法包括：利用与后台定时任务可操作地耦合和通信的接口，收集所述后台定时任务的运行状态参数；以及基于所述运行状态参数来监控所述后台定时任务，其中所述收集和所述监控独立于所述后台定时任务而被执行。

通过下文描述将会理解，根据本发明的实施方式，提供了一种用于管理和监控后台定时任务的统一接口和架构。计算系统中运行的所有后台定时任务的运行状态可以通过这样的接口被一致地收集和处理。具体地，可以独立于任何后台定时任务而监控这些任务是否处于正常运行状态。一旦发现后台定时任务发生异常，便可以通过统一的方式进行处理和/或告警。而且，可以按照一致的方式对后台定时任务进行备份、日志记录等各种操作，并且可以为系统管理员提供用户界面以了解后台定时任务的运行状态。以此方式，可以更为有效和准确地管理和监控后台定时任务。

附图说明

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

图1示出了根据本发明一个示例性实施方式的用于管理运行于计算系统中的后台定时任务的设备100的框图；

图2示出了根据本发明另一示例性实施方式的用于管理运行于计算系统中的后台定时任务的设备200的框图；

图3示出了根据本发明一个示例性实施方式的用于管理运行于计算系统中的后台定时任务的方法300的流程图；以及

图4示出了适合用来实践本发明实施方式的计算系统400的框图。

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

具体实施方式

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

本发明的总体思路是，提供一种用于管理和监控后台定时任务的独立接口和架构。计算系统中运行的所有后台定时任务的运行状态可以通过这样的接口被一致地收集和处理。可以独立于任何后台定时任务而监控这些任务是否处于正常运行状态。一旦发现后台定时任务发生异常，便可以通过统一的方式进行处理和/或告警。而且，可以按照一致的方式对后台定时任务进行备份、日志记录等各种操作，并且可以为系统管理员提供用户界面以了解后台定时任务的运行状态。以此方式，可以更为有效和准确地管理和监控后台定时任务。

现在参考图1，其示出了根据本发明一个示例性实施方式的用于管理运行于计算系统中的后台定时任务的设备100的框图。

如图所示，根据本发明的实施方式，设备100包括接口模块102。注意，尽管图1中仅仅示出了一个接口模块102，但是这仅仅是出于清晰目的。设备100实际上可以包括任意数目的接口模块102。每个接口模块102配置为可操作地与目标计算系统中运行的一个或多个后台定时任务耦合和通信。

在此方面，每个接口模块102可以访问后台定时任务的数据和状态，和/或调用后台定时任务的功能。例如，根据某些实施方式，第三方在开发后台定时任务时，可以按照与设备100的接口模块102相兼容的规范为后台定时任务编制接口和功能调用，从而允许设备100与后台定时任务之间完成数据和信息的交换。

根据本发明的实施方式，每个接口模块可以耦合一个或多个后台定时任务。每个后台定时任务均具有与相应的接口模块向对应的接口(例如，程序功能调用接口)。以此方式，不同类型和性质的后台定时任务被统一地耦合至设备100，并且其状态参数是设备100可访问的。

继续参考图1，设备100还包括状态收集模块104，其耦合至接口模块102，配置用于通过接口模块102来收集相应后台定时任务的运行状态参数。

例如，根据本发明的实施方式，对于任何给定的后台定时任务，状态收集模块104可以通过接口模块102获取该后台定时任务的执行次数、平均执行时间、最长执行时间和/或最短执行时间。此外，状态收集模块104还可以配置用于收集后台定时任务所抛出的异常。而且，状态收集模块104还可以配置用于收集与后台定时任务的执行有关的系统环境参数，例如系统内存使用情况、处理资源使用情况、网络情况，等等。

根据本发明的实施方式，状态收集模块104可以根据需要或用户的定制来通过接口模块102访问所监控的后台定时任务。状态收集模块104可以持续地工作，也可以按照预定周期而定期工作(即，以心跳模式工作)。

如图所示，设备100还包括任务监控模块106，其耦合至状态收集模块104，配置用于根据状态收集模块104所收集到的后台定时任务的运行状态参数来监控定时任务。

根据本发明的实施方式，任务监控模块106可以定期地执行，即，以心跳模式对后台定时任务进行监控。备选地或附加地，任务监控模块106也可以持续地执行或者响应于用户命令而被执行。

特别地，对于任何给定的后台定时任务，该任务的开发方可以提供有关该任务的规范或说明，其中可以规定在该任务正常执行情况下的状态参数。这种规范或说明可以按照任何适当的方式存储在系统中的任何存储设备(未示出)中。此时，任务监控模块106可以通过将收集到的任务状态参数与规范或说明中规定的正常状态参数进行比较，来确定后台定时任务是否处于正常运行状态。

例如，任务规范可以规定：后台定时任务的功能是每隔1小时执行一次数据抽取，并且抽取应在10秒内完成。此时，如果状态收集模块104通过接口模块102采集到的运行参数是：该任务的启动间隔为1小时，最长执行时间为9秒，则可以任务监控模块106可以判定该后台定时任务处于正常运行状态。反之，如果状态收集模块104采集到的参数是该任务的最长执行时间为12秒，则任务监控模块106可以判定该任务至少部分地未正常运行。进一步，如果状态收集模块104所采集到的状态参数指示该任务的最短执行时间超过了1分钟，则任务监控模块106可以判定已经处于不正常的运行状态。

备选地或附加地，可以事先将后台定时任务划分为多个类别，并且为每个类别设定正常的状态参数。这种特定于类别的正常状态参数可以是根据经验或统计获得的，也可以是用户指定的。相应地，任务监控模块106可以首先判断待监控的后台定时任务的类别，而后通过将状态收集模块104获取的状态参数与该列表的正常运行状态参数进行对比，来监控所述后台定时任务。

当监控模块106确定某个或某些后台定时任务处于异常状态时，其可以采取任何适当的措施。例如，终止该任务、重新启动该任务、维护该任务、启动向用户的告警，等等。本发明的范围在此方面不受限制。

通过利用上文描述的设备100，不再像现有技术中那样由每个后台定时任务各自监控自己的运行状态。反之，允许利用统一的接口来收集后台定时任务的运行状态参数，并且这些参数来监控后台定时任务是否处于正常运行状态。这有效地消除了后台定时任务的特性所带来的监控和管理方面的不便。

下面参考图2，其示出了根据本发明另一示例性实施方式的用于管理运行于计算系统中的后台定时任务的设备200的框图。注意，设备200可以视为上文描述的设备100的一个特定实施方式。

如图所示，设备200包括至少一个接口模块202、状态收集模块204和任务监控模块206，其分别对应于上文参考图1描述的接口模块102、状态收集模块104和任务监控模块106，故在此不再赘述。

设备200还可以包括状态存储模块208，其配置用于将状态收集模块204所收集的后台定时任务的运行状态参数的至少一部分存储在日志中。例如，根据某些实施方式，状态存储模块208可以将所有收集到的状态运行参数存储在日志中。备选地，可以仅当任务监控模块206确定某个后台定时任务处于异常状态时，才由状态存储模块208记录有关的状态运行参数。

在此所说的“日志”可以利用任何适当的数据结构来实现，例如可以是纯文本、数据库、可扩展标记语言(XML)之类的结构化文本，等等。本发明的范围在此方面不受限制。

此外，状态存储模块208还可以存储根据任务监控模块206所确定的任务异常的类型、描述、影响、解决措施、解决时间、异常持续时间等各种其他参数。实际上，与后台定时任务的监控有关的任何参数或信息均可由状态存储模块206存储在日志中。

继续参考图2，设备200还可以包括用户界面模块210，其配置用于利用用户界面(UI)来呈现后台定时任务的运行状态以及与用户进行交互。作为示例，用户界面模块210可以例如与操作系统相结合生成图形用户界面(GUI)，用以呈现系统上目前运行的后台定时任务或其子集的信息。例如，可以在GUI上任务标识(ID)、任务状态以及相关的信息。

用户界面模块210允许用户通过交互的方式查看和管理后台定时任务。作为示例，用户可以选择特定的后台定时任务。作为响应，设备200可以向用户呈现与该任务相关的运行参数、日志、子任务、资源使用情况或其他任何有关信息。通过用户界面模块210的操作，克服了现有技术中无法以直观、可操作的方式来查看和管理后台定时任务的缺陷。

在某些实施方式中，设备200还可以包括备份模块212，其配置用于响应于后台定时任务和/或所述设备200本身的至少一个发生异常而执行备份。具体而言，备份模块212可以在任务监控模块206监控到任何给定后台定时任务发生异常时，对与该任务有关的数据和信息进行备份。备选地或附加地，当设备200本身的运行发生了异常时，备份模块212可以对设备200目前处理的所有后台定时任务进行备份。在此，设备200本身的异常可以由设备200进行自检，也可由独立于设备200的设备或过程加以检测。

另外，根据本发明的实施方式，备份操作可以将数据和信息备份到后台定时任务所在的相同计算系统中，也可以离台备份到不同的系统或设备中。此外，根据本发明的实施方式，当一个发生异常的后台定时任务经过处理被恢复之后，可以删除与该任务有关的备份以节省存储资源。

继续参考图2，根据本发明的实施方式，设备200还可以包括告警模块214，配置用于响应于任务监控模块206确定至少一个后台定时任务发生异常而发送告警消息。例如，告警消息可以利用电子邮件、桌面消息、短消息服务(SMS)消息、多媒体服务(MMS)消息等各种手段。

特别地，根据本发明的实施方式，在上文结合图1和图2描述的设备100和200中，设备所包含的一个或多个模块与该设备中的其他模块可以驻留于不同的物理机器上。换言之，设备100和200可以是跨多个物理机器的分布式设备。

以设备200为例，在某些实施方式中，接口模块202、状态收集模块204和任务监控模块206可以位于第一物理机器上(例如，称为任务调度容器)；状态存储模块208、用户界面模块210、备份模块212可以位于第二物理机器上(例如，称为监控服务器)；而告警模块214可以位于第三物理机器上(例如，称为告警服务器)。这仅仅是示例性的，模块和功能的其他划分也是可能的。

此外，上文参考图1和图2描述的设备100和200可以利用各种方式实现。例如，在某些实施方式中，设备100和/或200可以利用软件和/或固件来实现。相应地，设备中的各个模块是软件功能模块。

备选地或附加地，设备100和/或200可以部分地或者完全地基于硬件来实现。例如，设备100和/或200可以实现为集成电路(IC)芯片或专用集成电路(ASIC)芯片。设备100和/或200也可以实现为片上系统(SOC)。现在已知或者将来开发的其他方式也是可行的，本发明的范围在此方面不受限制。

现在参考图3，其示出了根据本发明一个示例性实施方式的用于管理运行于计算系统中的后台定时任务的方法300的流程图。应当理解，图3中所示的方法300的步骤仅仅是出于说明之目的。例如，方法300可以包括附加的和/或备选的步骤。特别地，所示步骤的顺序仅仅是出于说明目的，这些步骤完全可以按照不同的顺序执行，甚至并行执行。

方法300开始之后，在步骤S302，利用与后台定时任务可操作地耦合和通信的接口，收集所述后台定时任务的运行状态参数。根据某些实施方式，收集所述后台定时任务的运行状态参数包括收集所述后台定时任务的以下一个或多个运行状态参数：执行次数、平均执行时间、最长执行时间、最短执行时间。

接下来，在步骤S304，基于所述运行状态参数来监控所述后台定时任务。根据某些实施方式，步骤S304处的监控可以被定期执行。

特别地，所述收集的步骤S302和所述监控的步骤S102独立于所述后台定时任务而被执行。

可选地，根据某些实施方式，方法300可以进行到步骤S306，在此将收集的所述运行状态参数的至少一部分存储在日志中。

可选地，根据某些实施方式，方法300可以进行到步骤S308，在此利用用户界面来呈现所述后台定时任务的运行状态以及与用户进行交互。

可选地，根据某些实施方式，方法300可以进行到步骤S310，在此响应于所述后台定时任务和/或监控本身(例如，收集步骤S302和/或监控步骤S304)而执行备份。

可选地，根据某些实施方式，方法300可以进行到步骤S312，在此响应于监控到所述后台定时任务发生异常而发送告警消息。

应当理解，方法300中的各个步骤分别对应于上文描述的设备100和200中的各个模块。由此，上文描述的特征同样适用于相应的方法步骤，在此不再赘述。

下面参考图4，其示出了适于用来实践本发明实施方式的计算系统400的示意性框图。例如，待监控的后台定时任务可以驻留和运行于计算系统400之上。

如图4所示，计算系统可以包括：CPU(中央处理单元)401、RAM(随机存取存储器)402、ROM(只读存储器)403、系统总线404、硬盘控制器405、键盘控制器406、串行接口控制器407、并行接口控制器408、显示控制器409、硬盘410、键盘411、串行外部设备412、并行外部设备413和显示器414。在这些设备中，与系统总线404耦合的有CPU 401、RAM 402、ROM 403、硬盘控制器405、键盘控制器406、串行控制器407、并行控制器408和显示控制器409。硬盘410与硬盘控制器405耦合，键盘411与键盘控制器406耦合，串行外部设备412与串行接口控制器407耦合，并行外部设备413与并行接口控制器408耦合，以及显示器414与显示控制器409耦合。应当理解，图4所述的结构框图仅仅为了示例的目的而示出的，而不是对本发明范围的限制。在某些情况下，可以根据具体情况而增加或者减少某些设备。

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

上文已经结合若干具体实施方式阐释了本发明的精神和原理。根据本发明的实施方式，提供了一种用于管理和监控后台定时任务的统一接口和架构。计算系统中运行的所有后台定时任务的运行状态可以通过这样的接口被一致地收集和处理。具体地，可以独立于任何后台定时任务而监控这些任务是否处于正常运行状态。一旦发现后台定时任务发生异常，便可以通过统一的方式进行处理和/或告警。而且，可以按照一致的方式对后台定时任务进行备份、日志记录等各种操作，并且可以为系统管理员提供用户界面以了解后台定时任务的运行状态。以此方式，可以更为有效和准确地管理和监控后台定时任务。

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

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

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

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

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

Claims

1.一种用于管理运行于计算系统中的后台定时任务的设备，包括：

至少一个接口模块，每个接口模块配置用于可操作地与相应后台定时任务耦合和通信；

状态收集模块，配置用于通过所述至少一个接口模块收集相应后台定时任务的运行状态参数；以及

任务监控模块，配置用于基于所述运行状态参数来监控相应后台定时任务。

2.根据权利要求1所述的设备，其中所述状态收集模块配置用于收集相应后台定时任务的以下一个或多个运行状态参数：执行次数、平均执行时间、最长执行时间、最短执行时间。

3.根据权利要求1所述的设备，其中所述任务监控模块配置用于定期执行所述监控。

4.根据权利要求1所述的设备，还包括：

状态存储模块，配置用于至少将所述状态收集模块收集的所述运行状态参数的至少部分存储在日志中。

5.根据权利要求1所述的设备，还包括：

用户界面模块，配置用于利用用户界面来呈现后台定时任务的运行状态以及与用户进行交互。

6.根据权利要求1所述的设备，还包括：

备份模块，配置用于响应于以下至少一个而执行备份：至少一个后台定时任务被监控到发生异常，以及所述设备本身发生异常。

7.根据权利要求1所述的设备，还包括：

告警模块，配置用于响应于监控到后台定时任务发生异常而发送告警消息。

8.根据权利要求1-7任一项所述的设备，其中所述设备中的一个或多个模块与所述设备中的其他模块驻留于不同的物理机器上。

9.一种用于管理运行于计算系统中的后台定时任务的方法，包括：

利用与后台定时任务可操作地耦合和通信的接口，收集所述后台定时任务的运行状态参数；以及

基于所述运行状态参数来监控所述后台定时任务，

其中所述收集和所述监控独立于所述后台定时任务而被执行。

10.根据权利要求9所述的方法，其中收集所述后台定时任务的运行状态参数包括收集所述后台定时任务的以下一个或多个运行状态参数：执行次数、平均执行时间、最长执行时间、最短执行时间。

11.根据权利要求9所述的方法，其中所述监控被定期执行。

12.根据权利要求9所述的方法，还包括：

至少将收集到的所述运行状态参数的至少部分存储在日志中。

13.根据权利要求9所述的方法，还包括：

利用用户界面来呈现所述后台定时任务的运行状态以及与用户进行交互。

14.根据权利要求9所述的方法，还包括：

响应于以下至少一个而执行备份：所述后台定时任务被监测到发生异常，以及所述收集和所述监控发生异常。

15.根据权利要求9所述的方法，还包括：

响应于监控到所述后台定时任务发生异常而发送告警消息。