CN1784656A - 监控数据处理系统中的操作数据 - Google Patents

Abstract

提供了用于监控与数据处理单元网络中的数据处理操作序列有关的操作数据的方法、设备和计算机程序。响应于数据聚集的指定边界，把操作数据有选择地聚集到所期望的时间段、所期望的处理节点集合和/或所期望的进程执行集合的离散数据分区中。一组事件侦听器响应于处理序列中的事件来启用数据聚集器的操作，并且所述数据聚集器响应于来自事件侦听器的通知、给操作数据分配一组不同的离散逻辑数据贮存器。所述数据收集响应于诸如收集间期期满的系统事件来结束对第一分区的数据收集并且开始对第二分区的数据收集。

Description

监控数据处理系统中的操作数据

技术领域

本发明涉及操作数据的监控，诸如对性能或者使用率统计的监控。

背景技术

近年来，在系统集成和公司间联网的发展的同时，增大了对监控操作数据的智能方法的需求。例如，当多个不同企业或者企业中的部门依赖于特定服务供应商时，所述服务供应商需要依照不同用户的使用率来对他们进行收费，或者需要在不同用户之间分配资源。这样做要求监控一个或多个使用率计量尺度，诸如CPU周期或者所使用的其它资源，或者处理的数据项或者字节的数目。其次，对高性能数据处理系统一贯需求的不断增加也要求有效的性能监控和分析。

已经提议了多种监控和调试方案，这些方案涉及向待监控的每个网络节点添加测试设备，或者向网络添加专用的报告节点。然而，这些方案通常不适用于生产环境，这是因为监控任务的附加处理影响了系统的综合性能和/或使操作流程失真。在很多情况下，用于实现操作数据监控的决定要求采用已经允许监控的已修改应用程序代码。此外，许多可利用的解决方案未能允许对单个应用程序执行范围内的单独的数据处理部件进行性能监控。

第6,467,052号美国专利描述了一种允许开发人员分析编程/调试环境中的分布式数据处理系统的性能的方法和设备。US 6,467,052的方法依赖于待监控的计算机的测试设备。为了避免在正常的生产使用期间的性能问题，US 6,467,052的事件监控器和定期监控器只有当开发人员分析系统的性能与功能时才有效。

本领域存在对用于有效监控操作数据的改进的方法和设备的需求，其中所述方法和设备是非侵入式的并且适用于生产环境。

发明内容

本发明的各个方面是提供用于监控与数据处理设备或者网络中多个数据处理单元执行的数据处理操作有关的操作数据的方法、设备和计算机程序。所述数据处理单元可以是在单个计算机上运行的单个计算机程序内的多个程序代码模块，或者可以是跨越计算机网络分布的多个协作数据处理单元。依照本发明的第一方面，定义了逻辑边界以便确定操作数据的界限，其中所述操作数据被收集到对应于逻辑不同的存储区域的特定数据分区中。所定义的边界由独立于被监控数据处理单元的数据收集机制运用，以便确定把哪些数据保存至不同的数据分区中，由此控制对所期望的操作数据进行有选择地收集。所述逻辑边界可以根据要求了操作数据的一组特定数据处理单元和/或特定时间段来加以定义。

依照所定义的逻辑边界来控制数据收集的能力能够把用户需要的正确操作数据自动保存到特定数据分区。这样做避免了过滤多余存储数据以提取相关数据进行后续分析的复杂操作。例如，用户也许希望在特定时间段通过一组特定数据处理单元来监控诸如已处理数据项的数目、CPU使用率或者等待时间之类的操作数据，并且这可以通过定义适当的物理和时间边界来实现。将用于向数据分区分配数据的机制与数据处理单元相分离，可以减少对被监控处理单元进行监控的影响。

在现有的解决方案中，如果把操作数据存储在单个连续存储区域中，那么在实际监控步骤之后必需执行对存储数据的有效分析，以便识别哪些数据与用户需求有关。

此外，有选择地把数据聚集到与用户需求相关的分区中可以减少需要保存的数据量。例如，如果保存在贮存器(container)内的所有数据都涉及数据处理操作序列(线程)的单个执行，那么每一数据项不需要与线程标识符一起被保存——仅仅所述贮存器包括线程标识符。如果与处理节点网络的特定节点有关的所有数据都被保存在单个贮存器或者贮存器的特定段中，那么对于贮存器或者贮存器段而言，包括节点标识符而不是要求节点标识符的每一数据记录是足够的。

优选的是，所述数据收集机制包括：数据聚集器(gatherer)，用于把所选的一组数据处理单元的操作数据聚集到用于该组数据处理单元执行的每一处理线程的离散数据贮存器(container)中；以及与所述聚集器异步运行的收集器(collector)，用于累积来自对应于所定义的逻辑边界的数据贮存器的数据。

依照本发明的一个实施例，数据聚集器把对应于数据处理操作序列的一组数据处理单元的已计量操作数据保存到第一离散逻辑数据贮存器中。与多个数据处理单元相关联的一个或多个事件侦听器响应于数据处理操作序列中的事件、向数据聚集器发送通知。所述数据聚集器通过更新贮存器中的数据记录来响应这些通知中的某些通知，并且通过切换至对第二贮存器的数据聚集来响应其它通知。

优选的是，所述数据收集机制还响应于系统事件通知，以便把数据收集从第一逻辑限制的数据分区切换至第二数据分区。在单个逻辑边界内可能有多个逻辑数据贮存器。所述系统事件通知可以是数据收集时间段期满的通知。当完成对一个数据分区的数据聚集时，对应于已完成的数据分区的数据贮存器被收集在一起，并且累积它们的数据以便后续分析和/或报告。

被触发以便在与用户定义的逻辑边界相关联的数据分区之间切换并且在逻辑数据贮存器之间切换的事件，把操作数据有效地分配到与用户需求相关的独立分区中。这可以包括与不同数据处理单元或者数据处理单元组有关的独立的操作数据，或者与不同时间段有关的独立数据，以及与计算流程内不同处理阶段有关的独立操作数据。

在优选的实施例中，使用数据聚集器来处理已计量的操作数据并且使用与被监控数据处理单元相关联的事件侦听器来触发数据聚集器的功能，这样做能够提供非侵入式的监控(即，监控对数据处理操作序列的性能影响最小)。

优选的是，把所述事件侦听器与数据处理单元之间的通用连接点相关联，而不是提供数据处理单元的操作数据处理部件。这样做简化了把事件侦听器用于各种不同类型的数据处理单元，而无需对每个处理单元进行重新编码，并且因此避免事件侦听器过于复杂。在事件侦听器复杂性方面的克服由于使其本身能够作为小型程序代码部件来实现，故而弥补了事件侦听器与计量功能和保存操作数据机制的上述差距。这样做具有如下好处，即：所述事件侦听器不会对被监控数据处理单元的性能产生显著影响——采用依赖于被监控系统的测试设备的多种监控方案的主要问题。依照本发明的优选实施例，操作数据监控和后续数据分析几乎不依赖于被监控的数据处理操作序列。

依照本发明的优选实施例，通过事件侦听器的通知(优选的是，数据聚集器的函数调用功能)来自动触发贮存器的开始和结束，这样做能够有效地为每个数据处理单元确定数据收集的界限。优选的是，提供收集器部件来与数据聚集器异步运行，并且累积来自于所定义的逻辑边界内的逻辑贮存器组的数据。优选的是，在数据聚集器和收集器之间利用逻辑贮存器的中间排队来串行化从不同贮存器累积数据的这种异步操作，用来避免在收集器处理期间、数据聚集器不同情况之间的互锁。

所收集的数据可以包括用于性能分析的统计数据(可用来协调被监控的数据处理序列)、用于记帐目的的使用率数据和/或当可能出现潜在问题时进行预防动作的操作特性的瞬态图。

优选的是，所述离散逻辑贮存器专用于数据处理操作序列内的单个处理线程，因此所定义的逻辑边界可以包含所选数据处理单元组内以及指定时间段内的多个独立的线程。

依照本发明的方法可以依照计算机程序代码来实现，所述程序代码用于控制其上运行程序代码的数据处理设备的操作。所述程序代码可以通过经由网络转送电子数据来获得，或者可以作为包括记录在记录介质上的程序代码的程序产品来获得。

附图说明

下面将通过举例并参照附图来描述本发明的实施例，其中：

图1是依照本发明实施例的互联数据处理单元网络的示意图，其中处理单元的连接点包括事件侦听器；

图2是依照本发明实施例的数据监控方案的体系结构概观；

图3是操作消息流程数据的逻辑贮存器的分级数据模型；

图4(A和B)示出了当用于监控操作数据时、本发明实施例的方法步骤的序列；

图5示出了依照本发明实施例的协议从事件侦听器到数据聚集器的多个函数调用；

图6A示出了包含网络内所有处理单元的第一网络边界(“包络”)，单个贮存器接收所述包络的操作数据；

图6B示出了与单个贮存器相关联的用于确定网络子集边界的第二包络；

图6C示出了覆盖多个网络、具有每个网络的独立贮存器的包络；

图6D示出了均包含网络节点子集的多个包络；

图7A和7B示出了示例性消息流程的特定处理阶段；并且

图8示出了重叠与图7A和7B的示例相关的包络的简化示例。

具体实施方式

图1示出了通过在处理单元之间转送计算流程的机制连接的协作处理单元20的网络10。该组处理单元的第一节点从队列30获取输入数据项以便启动处理序列。不同于此第一“输入节点”(其也许不具有输入连接点)，该组数据处理单元的每一数据处理单元20均包括一个或多个输入连接点50、一个或多个操作处理节点40以及一个或多个输出连接点60。所述输入和输出连接点50、60是通用部件，用于在每个操作处理节点40之间提供简单接口。数据处理单元20内的每个操作处理节点以及输入和输出连接点最好是程序代码部件，使得该组数据处理单元可以相连以便在计算机程序计算流程内形成一个或多个处理路径。

该组数据处理单元可以在通用数据处理设备内实现，所述通用数据处理设备诸如台式计算机或者联网的计算机系统组，或者由存储在计算机中的一个或多个计算机程序有选择地激活或者配置的其它装置。另外，本说明书公开了其上记录有计算机程序的记录介质。所述介质可以是任何传输或者记录介质。此处公开的程序代码部件不意指局限于任何特定的程序设计语言或者操作系统环境。

可以采用很多不同的操作处理节点来执行各种不同的操作。在第一操作处理节点40处理之后，把数据项传递至当前节点的输出连接点60，并且转送到序列中后续数据处理单元的输入连接点50。所述处理单元可以是在单个数据处理系统上运行的单个计算机程序的相互连接的处理节点。由操作处理节点执行的操作可以包括过滤、格式转换、变换、诸如添加或更新数据字段、集结多个输入、计算功能等。作为选择，所述网络中的处理单元可以包括应用程序专用程序代码(“商业逻辑”)，和/或可以跨越计算机网络来分布。

所述输入连接点50均具有相关联的存储区域以便接收来自相连的数据处理单元的数据，并且输出连接点60均具有相关联的存储区域来接收由当前处理单元处理的结果，以便转送到计算序列中的下一处理单元。所述输出连接点60还包括作为程序代码指令实现的函数，用于对底层数据转送机制进行调用，以便把数据从当前处理单元的输出连接点的存储器移动到相连的处理单元的输入连接点。输入连接点50包括用于触发它们相关联的操作处理节点的操作的功能。

上述处理单元结构能够使数据处理单元中的每一操作处理节点相互无关，并且基本上不依赖于连接器的功能。这种无关性简化了新处理流程的创建并且简化了向网络添加新的数据处理单元的过程。无论操作处理节点本身之间的差异如何，操作处理节点都可以依照所期望的顺序经由连接点被连接在一起。

下面将参照诸如上文所述的处理单元网络来描述本发明的实施例，但是本发明的特定方面不局限于这种网络体系结构。依照此实施例的解决方案能够遍及网络监控计算流程的进程，识别与特定处理单元相关联的性能问题，并且监控特定处理单元或者网络特定部分的使用率。

当在附图中对具有相同参考标记的特征和/或步骤进行参考时，那些特征和步骤具有相同的功能或操作。

体系结构概述

用于监控处理单元网络的操作数据的方案包括如下部件和机制，如图1和2所示：

位于输入和输出连接点50、60的一组事件侦听器部件55、65(参见图1)，用于响应处理流程中的事件来启用数据聚集器80(参见图2)的功能；

数据聚集器80，用于创建逻辑贮存器90以便存储操作数据，用于响应所述事件侦听器的通知、把数据分配至特定贮存器并且把数据保存至特定贮存器，并且通过把已完成贮存器保存至先进先出队列110来由收集器120检索以便响应某些事件通知。

收集器120，用于累积保存在相关贮存器的数据，以便进行后续的性能分析或者生成统计或者记帐数据；以及

一组输出部件130，包括报告编写器以及记帐模块。

下面参照图2、4和5来详细说明上述部件的功能和它们之间的关系。

通过使用全局系统值来允许和禁止数据聚集，用户可以使用命令行条目来改变该全局系统值。在上下文中，用户可以是负责统计或者性能监控的人员，或者可以是负责配置系统以便进行所期望的数据监控的配置管理员。用户还具有选择权以便通过用于设置其它系统值的命令行条目来指定增加的聚集粒度——诸如指定是否将要聚集节点特定的量度(metric)，或者指定200要求进行监控的特殊网络区域或者段。多个不同的数据聚集器实例80、80′可以同时运行以便聚集不同网络节点组的数据。

所述聚集器80管理把操作数据分配到逻辑不同的存储区域90(此处称为‘贮存器’)内的累积器95中的过程。贮存器是由所述聚集器依照预先分配的存储器区域来创建的，其中所述聚集器把数据保存在所述存储器区域中。图3中示出了贮存器90中的累积器95的结构。累积器95是一个存储区域段，连同相关联的更新机制(或者‘计量器’)100一起用于增加存储在累积器中的数据，并且用于记录来自事件侦听器55、65的通知。累积器可用来对处理节点的调用进行计数，或者用来对聚集周期内已处理数据项的数目进行计数。附加的累积器对事务提交的数目和逆序操作的数目、或者与可利用线程的最大数目相比较而言有效线程的数目进行计数。所述累积器响应来自于事件侦听器部件的函数调用来增量。不是所有的累积器都包括计数机制——把其他累积器与不同类型的计量器相关联，以便记录消息大小(最大值、最小值和平均值)。诸如简单计数器的某些计量器100可以在聚集器80内实现，但是还可以使用附加的外部计量器100。

除由数据聚集器管理的累积器以外，典型的数据处理系统还提供了系统时钟105，所述数据聚集器可以参照该时钟来测量经过的时间、等待时间和CPU使用时间。另外，时间段期满的通知可以告知数据收集周期的结束——如稍后将要描述的那样。当可以在系统上利用时，所述数据聚集器还可以使用现有CPU使用率计量器，或者在其集成的计量器组内并入CPU使用率计量器。

事件侦听器部件55、65响应于在被监控的计算流程内发生的多个预定事件来向数据聚集器80发送210、220通知。如图5所示(参见步骤(3)到(9))，这种事件之一是把数据从第一数据处理单元转送至第二数据处理单元。响应于这种‘切换’(或者转送)事件来对数据聚集器80进行调用可以提示聚集器切断对与第一数据处理单元相关联的累积器的数据聚集，并且同时接通对与目标处理单元相关联的累积器的数据聚集。在切换之后由数据聚集器立即输出到贮存器的任何操作数据将涉及目标数据处理单元，因此，将其记录在相应的累积器中。在处理节点间转送的通知以及其它能够通知的事件隐含地表明计算流程的进程，如此使得在每一事件侦听器通知内只有最少的信息需要被发送。

其它能通知的‘触发’事件包括处理错误和超时，以及事务操作的提交或者逆序操作。在优选的实现方式中，来自于所述事件侦听器的调用是函数(方法)调用，其调用数据聚集器的函数。然而，可替代的实现方式可以使用不同于函数调用的事件通知。

使用处于连接点50、60的事件侦听器55、65以及使用独立于数据处理单元20的累积器100和分析工具120、130来管理数据聚集允许维持处理单元的独立性。

所述数据聚集器把计算流程每次执行的操作数据聚集230到聚集贮存器90中，其是逻辑上不同于其他聚集贮存器的特定数据分区。单个聚集贮存器可以在多个处理单元之间共享，但是对于处理单元20的网络10内的处理线程而言是唯一的。每个贮存器90具有一个标识符，所述标识符将其与协作处理单元网络的特殊执行实例和处理路径相关联。由此，每个贮存器具有用于包含所选数据处理单元组的特定处理线程的操作数据的存储区域。所述数据聚集器80把操作数据输出至逻辑贮存器90以便后续处理。在单个逻辑边界内可以有多个贮存器(对应于处理序列的多个执行)，正如下面将描述的那样。

贮存器通常具有对应于不同累积器的多个离散段，用于独立地存储与不同数据处理单元有关的数据，并且用于独立于识别计算流程的数据存储线程专用数据。尽管为每个计算流程独立地聚集操作数据，用户能够指定他们最终进行性能分析或者统计报告所需的数据类型和粒度。此处描述的实现方式包括两个较宽的数据类别：

1.用于特定计算流程的线程相关数据。例如，其可以包括在由特定计算机程序的特定处理单元执行组的特定计算流程使用的线程库的线程4上，在特定的15分钟收集期间上处理的输入信息的以K字节表示的平均大小。

2.用于特定计算流程的节点相关数据。例如，其可以包括在特定30分钟时间段期间、在特定计算流程(特定计算机程序的特定处理单元执行组内)的单个计算节点中处理期间，由单个消息使用的CPU的最大用量。

提供了一种协议来识别用于聚集用户所选处理单元网络内的处理序列的操作数据的开始和结束点。这些内容在图5中示出。对应于所选数据处理单元组内的第一数据处理单元的输入节点被配置为：当所述输入节点开始等待输入(其可以在线程分配之前)时，向聚集器发送“开始聚集”调用(1)，并且当输入有效数据以便开始执行处理序列时，发送“开始消息”调用(2)。用户指定的处理单元组的最后处理单元的输出连接点被配置为：当所执行的处理序列到达此输出连接点时，发送“结束聚集”调用(或者当控制被切换(10)回到起始节点并且由起始节点发布“结束聚集”(11)时，如图5的示例性实现方式所示出的那样，并且稍后依照消息流程的上下文来描述)。

用于实现开始数据聚集和结束数据聚集的函数调用的所选节点，可以是用户指定的节点组的第一个和最后一个节点——使得起始和结束节点对于数据聚集而言在物理上被确定了逻辑边界。所述逻辑边界还可以按照时间段来限定。通常，用于监控操作数据的逻辑边界包括物理网络边界(由所选处理单元组定义)和与操作或者时间相关的限制符(例如，开始和结束时间)。通过逻辑边界划界的此数据分区此处被称为“包络”。边界的附加参数可以对应于对遍及计算流程的输入数据项的处理的完全执行的预定数目。完全执行的数目可以对应于已处理消息的数目。

所述聚集器响应开始聚集和结束聚集的函数调用以便在逻辑上把被监控的操作数据划分为贮存器。除开始和结束聚集调用以外，一组其他事件可触发的函数调用被提供于每个事件侦听器中，并且它们控制把数据聚集到逻辑不同的贮存器并且聚集在那些贮存器内的累积器中的过程。收集器120响应与时间有关的通知，以便在逻辑上把数据划分为“包络”，所述包络对应于用户感兴趣的逻辑分区。包络的时间边界不依赖所述流程遍及网络的使用期限。所述收集器根据所定义的(例如，用户指定的)聚集周期来控制包络的使用期限，如下所述。

在收集过程的聚集和累积阶段内使用了多个计数器间隔。

1.聚集器中的固定定时器间隔(参考系统时钟监控)——例如大约5秒钟。在该组数据处理单元在该时间段接收到零或者不足数目的输入数据项(例如，消息)的情况下，其用来判定何时移交完成的聚集贮存器。

2.用于控制瞬态图间隔的收集器中的固定20秒定时器间隔(使用系统时钟监控)。

3.主要间隔定时器。其由用户通过命令行条目来配置(通常使用范围从10分钟到10天的值)。其用来控制存档间隔。

所述聚集器不依赖于收集器，反之亦然。聚集器不需要考虑主要间隔周期或者瞬态图周期。它们聚集数据并且把对已完成贮存器的责任转送240(“移交(hand off)”)至传送器。用于判定何时移交的准则如下：

(a)已经通过消息流程完成处理的输入消息的数目

(b)包络的形状已经被改变——并且因此，聚集的数据的混合可能不同。在该情况下，聚集器可以获得继续聚集进一步数据的另一贮存器。

(c)如上文1.所描述的时限已经期满。

利用聚集“版本”编号来给贮存器做出标记。当在包络形状方面已经存在变化时，版本编号被增加。

在需要操作数据聚集的网络环境中，可能存在多种各具有多个处理单元的网络。用于聚集操作数据的情况包括如下内容：

1.‘包络’限制网络内的所有处理单元。图6A中示出了这种例子，其中所述包络(e1)限制网络内的所有处理单元(u1...u5)。随着控制流程通过处理单元，操作数据经由所述聚集器被累积到单个贮存器中。

2.包络限制网络内的处理单元的子集(参见图6B和6D)。处理单元的网络可以包含/包括如图6D中的多个包络。在图6B中，所述包络(e1)限制网络内所述处理单元的子集(u1、u5、u4)。随着控制流程通过由包络限制的处理单元，操作数据经由所述聚集器被累积到单个贮存器中。图6D是多个包络收集离散操作数据的一个网络的例子。

3.包络覆盖多个网络(参见图6C)。所述包络(e1)覆盖多个网络(u1...u3、v1...v2)。随着控制流程通过由包络限制的每个网络的处理单元，操作数据经由聚集器被累积到多个贮存器中。然后当包络闭合时，这些贮存器被合并。

通过基于网络内的处理单元来预定义其形状(如图6A至6D中所示)，可以在已知网络中优化所述贮存器。在动态网络中，贮存器的形状将由控制流程来确定。还能够让两者混合。

依照本实施例的监控方法的进一步处理步骤是：累积250来自对应于包络的贮存器组的数据。此累积步骤250是由收集器部件120执行的。由收集器进行累积是不依赖于把操作数据存储到贮存器中的步骤来执行的，并且由收集器对每个贮存器的处理如下所述那样被串行化。这样做可避免在数据聚集机制的不同实例之间出现潜在的互锁(资源竞争)。

每个贮存器90表示沿网络的计算路径、在处理流程的一个或多个执行实例期间聚集的整组操作数据。聚集器执行实例把操作数据传递至每个创建的贮存器，然后把完成的贮存器传递240至中间异步递送机制(“传送器”110)，该机制是贮存器的逻辑先进先出队列。对于计算流程来说，每个最新完成的贮存器由聚集器80链接至单向传送器队列110的末尾。所述收集器从传送器队列110的首部读取250贮存器，并且更新其累积的贮存器的相关一个(依照早先提及的所获取的数据类型以及用户定义的逻辑边界)。此累积步骤250是由收集器参考每个贮存器内的处理流程标识符信息和用户定义的包络边界来实现的。由此，图2中贮存器至收集器的流程是从右到左的，贮存器被添加到右手端并且从传送器队列的左手端读取。

所述收集器120持续从传送器110读取并且把来自于贮存器90的数据累积到“累积的贮存器”(作为逻辑边界内贮存器的记录合并的收集器管理的贮存器)中，直到如下事件之一发生为止：

1.对于瞬态图数据的报告而言，瞬态图时间间隔已经期满(参见下面瞬态图的说明)。

2.对于存档数据的报告来说，主要间隔(存档周期)已经期满。

3.所述聚集版本(从贮存器90读取——参见上文)已经被增加，这表明包络的形状已经改变。

4.已经发生中介(Broker)停止工作。

5.用户已经请求对特殊数据流的统计应该在此主要间隔被重置。也就是说，直到此点所聚集的并且仍未输出的所有数据应该从收集器中去除。

在上文列出的所有情况1-4中，所述收集器输出260直到此点累积到当前累积的收集器中的数据，并且将此数据传递至多个编写器部件130的适当一个(根据用户需要的处理——诸如统计报告生成、性能问题分析等等)。

在上述情况1中，瞬态图记录被输出并且被初始化，并且新的瞬态图间隔立即开始。同样在情况2中，直到此点累积的存档记录被输出，并且被初始化，并且新的存档间隔开始。在情况3和4中，直到此点累积的存档和瞬态图记录被输出、初始化，并且新的间隔开始。

当已经处理了上述5个事件的任何事件时，所述收集器恢复从传送器读取输入。

所述收集器以满足“历史”存档数据(即，在几个小时或几天期间内获取的数据)和瞬态图(即，在非常短的间隔获取的数据)两者需要的方式来累积数据。所述瞬态图视图是已经收集的最新的数据子集。这通常将在几分钟和/或几秒钟内结束。为了实现此操作，所述收集器支持离散的时间子间隔的数据累积，所述离散的时间子间隔总体上完全覆盖较大的存档收集间隔。所述收集器在这些子间隔内累积数据，并且所述瞬态图数据根据最新完成的子间隔累积来产生。

两个收集器累积的贮存器被维护——一个用于存档记录而另一个用于瞬态图记录。进入聚集贮存器是从传送器读取的，并且同时用于把数据累积到相应的收集器累积的瞬态图贮存器和存档贮存器中。

逻辑边界或者包络对于管理和分析数据十分有用，这是由于它们允许用户依照适于用户要求的输出的任何方式来组合操作数据。例如，管理特定网域的系统管理员可能仅仅希望监控他们特定网域的性能以及其他操作数据，并且仅仅希望每天接收报告一次。这是通过聚集器配置步骤来实现的，其中所述管理员选择网域的节点集并且指定存档统计的报告间隔。

作为选择，用户可能需要单个计算机程序内每个计算路径的操作数据的独立的报告，并且在该情况下，所述包络可能在从数据聚集开始的所定义的时间段上包含相连的计算流程节点集，所述时间段诸如是30分钟。

与当前所选节点集外部的处理节点有关的任何数据都在当前“包络”之外，因此，如果记录的话，那么独立于所选节点集的操作数据来记录。包络可以包含多个逻辑贮存器——诸如如果将要在单个包络中累积计算流程的多个执行，或者如果所选异步处理节点网络中的不同节点具有待累积的独立贮存器。

使用贮存器和包络在逻辑上有意义的块中存储最新生成的操作数据，这样做避免了对所存储操作数据的非常复杂的分析，否则，需要进行该分析来识别所存储的数据中的相关边界。

所述数据聚集器响应于来自事件侦听器部件的调用来工作，以便控制对应于逻辑执行边界(诸如事务边界或者物理系统边界)的“包络”内的收集。所述函数调用包括如下：

开始聚集——此刻，网络中第一处理单元开始等待输入(其可能先于线程分配)

开始消息——此刻，有效输入消息被接收(或者，等效的是，遇到进入包络的第一流程)并且开始经由网络被处理。

通知——处理错误

通知——等待输入期间超时

通知——事务的退回

通知——事务的提交

通知——连接点启用

通知——处理节点启用

切换——从一个处理单元到另一个指定处理单元的聚集

结束聚集——此刻，输入消息的处理(或者由流程执行处理的其他数据项)在逻辑上完成。这是包络的结束。

所述聚集器响应上述调用并且确定何时创建新的贮存器，是否保持贮存器来累积多个传递或者管理异步处理单元，并且是否移交贮存器至收集器机制。所述确定基于对在配置步骤期间定义的某些调用和准则的固定响应的组合。例如，开始聚集以及结束聚集确定包络的界限。所述系统可以被配置为响应于来自事件侦听器的每次切换调用来启动新的贮存器，并且把操作数据传递至新的贮存器，或者单个贮存器可以用于来自节点序列的操作数据。所述系统通常将被配置为仅仅响应于事务退回的通知来增加计数器。所述聚集器用来管理在用户定义的逻辑执行边界或包络内对多个事件的数据聚集。在聚集期间的数据移交可以使用固定的系统参数来实现，这些参数是一般的最终用户无法改变的。然而，用户通常定义主要的间隔周期，其用于控制收集器的报告周期。

对于单线程(同步)处理来说，包络的开始和结束点与贮存器的使用期限可能重合。在此情况下，在收集器中只能有一个贮存器来“累积”——诸如依照稍后描述的实现示例的同步消息流程执行的情况。对于多线程(异步)处理来说，过程相似，除了在切换点(当在处理单元之间的接口处把计算流程从第一转换为第二连接点时)，形成新的贮存器而不是沿用单个贮存器。在聚集包络之内往往保留两个贮存器。在该情况下，当贮存器的线程终止或者停止对该包络处理时，它将被‘转送’至收集器。当创建它时，所述包络标识符被设置在每个贮存器上，以便使收集器可以为给定的包络来累积独立的贮存器。

所述收集器读取聚集贮存器，当所述当前包络包括一个以上贮存器时从多个贮存器累积数据。每个聚集贮存器均为被收集的每个不同类型操作数据包含离散的段。所述离散的段必要时还可用来区分不同的起始处理单元。

如上所述的监控方案的特性在于：数据聚集以及已聚集数据的处理可以作为几乎完全独立于被监控的数据处理流程的机制来实现。这种非侵入式的监控方法避免在多种已知方案中固有的被监控数据处理流程操作失真的问题。

如上所述的方案在自动计算和按需电子商务(EBOD)领域中有着十分有益的应用。在前者中，需要根据处理单元网络或者根据那些网络的离散部分来聚集计量，以便管理网络部件的自愈。在按需电子商务领域中，网络部分的测量粒度对于向那些部分的使用所取费用而言是十分重要的。

消息中介(Broker)应用

本发明的一种实现方式提供了用于从消息系统的消息中介报告操作数据的机制。然而，本发明不局限于这种系统，而是可用于监控操作数据并且生成对不同数据处理系统和计算机程序或部件的性能和统计报告以及记帐数据。在详细描述消息中介实现方式的特性以前，了解消息发送、消息中介和消息流程的某些背景将是有益的。

快速地采用、集成并且扩展新的和现有的数据处理技术的能力对于多种商业的成功来讲已经变得非常必要。在数据处理网络中的多机种和变化已经成为一种规范，所述规范需要用于实现不同系统之间的互操作性的通信方案。经由智能媒件产品进行的应用至应用消息发送提供了解决此问题的方案。

消息发送和消息中介

例如，已经为人们所熟知的是IBM公司的MQSeries和WebSphere MQ消息发送和排队产品系列，其用于支持在分布式多机种环境下、在不同系统上运行的应用程序间的互操作。在由McGraw-Hill于1994年出版的由B.Blakeley、H.Harris & R.Lewis提出的“Messaging and Queuing Using the MQI”中描述了消息排队和可以购买到的消息排队产品，并且在可以从IBM公司获得的“AnIntroduction to Messaging and Queuing”(IBM文件编号GC33-0805-00)和“MQSeries-Message Queue Interface TechnicalReference”(IBM文件编号SC33-0850-01)的出版物中也有所描述。计算机使用消息排队进行通信的网络可以是因特网、内联网或者任何计算机网络。IBM、WebSphere和MQSeries是IBM公司的注册商标。

由IBM的MQSeries和WebSphere MQ产品提供的程序间通信的消息排队支持，能够使每个应用程序向任何其它目标应用程序的输入队列发送消息，并且每个目标应用程序可以异步地从其输入队列获取这些消息以便处理。这是基于事务支持以便提供在应用程序之间可靠递送消息来实现的，其可以跨越分布式多机种计算机网络来扩展。消息递送可以在不要求应用程序间的专用逻辑端到端连接的情况下来实现。

在应用程序之间的可能的互连的映射关系中存在很大的复杂性。此复杂性可以通过在网络体系结构内包括与其它系统连接的通信集线器、而不是让所有系统之间直接连接来得以极大地简化。因此能在通信集线器处提供消息中介能力，以便提供智能的消息路由和应用程序集成。消息中介功能通常包括依照商业规则和对不同应用程序信息需求的认识、使用消息首部中包含的消息‘主题’信息来智能地路由消息的能力，并且包括使用对目标应用程序或者系统的消息格式需求的认识来变换消息格式以便协调系统和应用程序之间差异的能力。

这种中介能力例如由IBM公司的MQSeries集成器和WebSphere MQ集成器产品来提供，使用MQSeries或者WebsphereMQ消息发送产品为应用程序之间交换的消息提供了智能路由和变换服务。

对消息中介应用的管理和开发的支持可以在消息中介体系结构中得以实现，以便提供包括发布/订阅消息递送、消息变换、数据库集成、消息存储入库和消息路由的功能。消息流程是可视程序设计技术，其支持所有这些中介能力，并且极大地简化管理和开发消息中介方案的任务。

消息流程

消息流程是由消息中介的处理逻辑执行的操作序列，其视觉上可以被表示为输入队列和目标队列之间的有向图(消息流程图)。消息流程还可以被可视地编程。所述消息流程图包括消息处理节点，这是处理部件的代表，并且包括节点之间的消息流程连接器。消息处理节点是预定义部件，均对输入消息执行特定类型的处理。由这些节点进行的处理可以覆盖各种活动范围，包括重新格式化消息、变换消息(例如，添加、删除或者更新字段)、路由消息、把消息存档到消息库中或者把数据库信息合并为消息内容。

存在两个基本类型的消息处理节点：端点和通用处理节点。端点表示消息流程中的点，其中消息制作者可以向所述消息流程发送消息(输入节点)或者消息消费者可以从消息流程中接收消息(输出节点)。端点与系统队列相关联，客户端应用通过从这些队列读取或者向其中写入来与端点交互。通用处理节点获取消息作为输入，并且将其变换为0、1或更多输出消息。这种消息处理节点的每一个均具有一组输入连接点(InTerminal)，它通过该组输入连接点接收消息，并且均具有一组(可能为空)输出连接点(OutTerminal)，它经由所述输出连接点传送处理后的消息。消息处理节点具有可以定制的属性。这些属性包括由处理节点使用以便执行其对输入消息的处理的表达式。

消息流程是利用消息中介的可视程序设计特性通过可视程序编译器来创建的。这涉及把消息处理节点设置在绘制表面上，并且把一个节点的输出终端连接至另一个节点的输入终端。这些连接确定通过消息处理节点的消息流程。消息流程可以包含其本身就是消息流程的混合消息处理节点。以这种方式，消息流程可以模型化构建，并且特定的消息处理功能可以被再次使用。

消息流程执行

消息流程是通过执行引擎执行的，所述执行引擎可以读取消息流程的描述，并且为每个消息处理节点启用适当的运行时间代码。这将稍后涉及。每个消息流程均具有线程库，所述线程库可以被配置为具有1到256个线程。当构造消息流程的输入节点时，从其线程库中获取一个线程，并且使用它来侦听输入队列。单个线程承载从流程开始到结束的消息，并且因此当消息通过所述流程时，所述线程可用来识别该消息。

在该输入队列上排队输入消息可启动在已排队消息上执行消息流程。然后，把所述消息传送到连接器的目标节点，所述连接器源自输入节点的输出终端。如果存在一个以上的输出连接器，那么创建并且由后续节点独立处理消息的副本。如果所述节点是输出节点，那么把所述消息递送到相关联的消息队列；否则，所述处理节点将为每个其输出终端创建零或更多输出消息。如上所述，把消息传送至后续节点。

一旦输入消息到达，消息处理节点就将处理输入消息，并且当它已经结束其处理时，不保存与该消息有关的信息。处理节点可以经过输出终端输出一个以上相同类型的消息，并且如果存在一个以上的源自输出终端的连接器，那么可以传送同一消息的多个副本；所有这些消息都彼此独立地被处理。处理节点未必为所有其输出终端产生输出消息——它往往根据特定的输入消息为特定的终端产生一个输出。此外，节点可能为不连接至其他处理节点的输出终端产生消息，在这种情况下，不进一步处理所述消息。

监控消息流程

在2002年8月29日以Aizenbud-Reshef等人的名义出版的题目为“Monitoring messages during execution of a message flow”、公开号为2002/0120918的已指定的共有待决的美国专利申请(代理人参考编号GB920000119)中描述了用于监控消息流程的方案，将该篇申请的内容在此引入，以供参考。公开号为2002/0120918的美国专利申请描述了在消息流程内插入进程报告发生器节点以便监控在测试和调试环境中进程的执行。

本发明的实现方式还可以用于监控消息中介内的消息流程。所述操作数据聚集机制有选择地聚集统计量，诸如经过的时间、CPU使用率和消息流程中处理节点的启用计数。所述实现方式使用了位于消息流程节点之间的连接点的事件侦听器部件来对数据聚集部件进行函数调用。所述调用启用聚集器的功能以便把操作数据保存到逻辑贮存器中待后续处理和报告。用户可以通过命令行条目来指定是否能够对消息流程、中介域内的所有消息流程或者消息中介内的所有消息流程处理进行数据聚集。下列描述涉及监控特定消息流程的操作数据的例子。

预定义数据聚集周期的开始对应于新的聚集包络的开始和第一新的贮存器的构成。这可以在线程分配之前，而此刻，消息流程的第一节点只等待输入。最初的消息的接收触发消息流程执行实例的开始。在此处描述的特殊的实现方式中，消息承载对聚集器代理的涉及。所述代理是轻量内嵌实体，用于询问系统值以便确定从事件侦听器接收的通知是否应该被转送到底层数据聚集器。在消息流程节点的连接终端内提供的事件侦听器代码向代理聚集器发送通知，其参照系统值来确定是把通知转送至与代理相关联的聚集器机制还是忽略所述通知。

当所述处理流程进入消息流程的后续节点时，接收节点的连接输入终端对所述聚集器做出函数调用，其代表传送节点切断数据聚集并且接通接收节点的聚集。聚集切换经由消息流程终端沿双向进行。因为对整个包络收集统计量，其可以包含完整的消息流程执行或者可以累积对应于多个执行的多个贮存器，所以当发生节点切换时，同一贮存器可以继续被使用。然而，当发生节点切换时，贮存器开始把操作数据接收到与新节点有关的贮存器内的独立段中。

事件侦听器等待被监控数据处理序列内的事件，并且如上所述向聚集器发送通知/通告。用于监控消息流程的聚集机制的事件侦听器提供下列函数调用：

通知所述事件侦听器何时开始聚集统计数据，

通知何时发生暂停、退回、提交或者错误，

表明输入消息何时已经成功地撤销排队并且开始被处理，

通知何时完成对输入消息的处理，

通知用于处理消息的线程何时即将变为空闲。

提供了另一‘切换’调用以便用于处理节点之间的连接点(终端)来表明何时停止从先前节点聚集数据并且何时开始对下一节点进行聚集。

在对当前线程进行处理期间，所述聚集器在特定点响应来自于所述事件侦听器的通知、把操作数据保存到逻辑贮存器。所述收集器寄存系统生成事件的通知。其可以是操作系统定时器信号或者特定系统广播。所述事件用来向收集器表明收集数据的收集间隔已经结束，并且新的间隔已经开始。当采样间隔期满时，收集间隔结束通知被发送给收集器。

如果用户通过命令行条目指定主要间隔(用于存档)，那么用系统时钟来控制收集器内报告间隔的期满。在某些操作系统平台上，收集器可以响应系统广播(诸如IBM公司的z/OS操作系统上的事件通知机构(Event Notification Facility，ENF))以便控制存档数据的报告间隔的期满。在一个特殊的实现方式中，用户可以在z/OS操作系统上为主要间隔指定0(零)值，以便通知收集器外部系统广播将被使用。在z/OS操作系统上使用系统广播对于希望使不同产品统计量的报告(例如，为消息递送程序以及基于消息流程的消息中介程序创建贮存器记录)同步的用户而言，是十分有益的。z/OS是国际商业机器(IBM)公司的商标。

每个统计量聚集贮存器包括消息流程(在最简单的情况下，其对应于包络)的标识符以及用于处理通过流程的输入消息的线程的另一标识符。贮存器用来保存并且累积统计数据，诸如经过时间、CPU使用率、启用计数、消息大小，并且被划分为离散的段，诸如消息流程、线程以及单个数据流节点。图3中示出了消息流程数据贮存器的逻辑数据模型。图3示出了包含消息流程相关数据的根数据结构(或者父辈)，以及包含相关线程或者消息流程节点相关数据的子辈结构。所述节点子辈结构可以都具有属于它们自己的子辈，这些子辈包含节点终端相关数据。

收集器累积与包络有关的贮存器组，如上所述，并且向一个或多个输出部件输出累积的数据以便定期报告统计或者记帐数据，或者用于性能分析和报告。所产生的数据的例子是在特定日期、在特定的30分钟周期上，用于在特定消息中介的执行组上的消息流程的每个节点中处理消息的平均耗费时间。

对于收集器(先前描述的)来说能够执行覆盖多个包络的后期处理累积。所述聚集机制还可以被限制为在单个贮存器中累积多个包络(在特殊的持久线程上处理)的统计量。以这种方式，所述聚集机制可以代表收集器机制来执行数据的“预先累积”，并且减少了传送器机制(也如上所述)上的通信量。通过聚集机制在包络处理一开始的时候(这是把线程分配给实际处理流程时的点)做出用于开始新的包络的新贮存器、或者用于使用现有贮存器(用于预先累积)的判定。当创建聚集机制时，是否具备做出此决定的能力以及待使用的原则被确定。在本实现方式中，当配置消息流程处理时——这是确定包络内处理单元的网络拓扑时的点，所述聚集机制被创建。

用户能够选择他们希望获取的数据的粒度级别——诸如指定对相关线程、相关节点和/或节点终端相关数据的需求。以用户指定的间隔从收集器输出累积的数据。数据的格式也通过用户需求(以及平台特性)来确定。一旦由用户指定，收集间隔就受到诸如定时器或广播的系统事件的控制。在大多数情况下，收集间隔的累积数据是历史上的——在几个小时或者几天期间获取的。累积的数据可以由多个不同的应用程序处理以便产生离线报告。然而，还可获得所收集数据的更当前的“瞬态图”视图(或者每隔一定间隔发行，或者响应于用户请求)。获取瞬态图的间隔可以被配置为比收集间隔更加短。这样做例如能够使用户在足够短的间隔获知消息流程中当前线程使用率的级别，以便如果线程使用率接近最大值，采取预防措施。

在指定收集周期和瞬态图时间时，用户可以使用消息中介配置命令来切换操作数据监控的启闭，并且指定把监控应用于特定消息流程、还是中介执行组中的所有流、还是属于消息中介的所有执行组。

当消息流程包含合并应答节点时，可以在单个包络中创建多个贮存器。一个贮存器从始于所述控制输入的输入节点的线程获取数据，第二贮存器获取用于生成管理应答消息的输入节点统计信息的数据，并且另一贮存器获取用于合并节点暂停线程中的工作的数据。消息流程是对同步执行的处理节点的收集，这是正常规则的例外情况。

如先前所述，收集机制在聚集贮存器中累积传递给它的操作数据，同时避免聚集机制的独立实例之间互锁，其中所述聚集贮存器是由一个或多个聚集器实例来生成的。由于聚集点与处理节点之间的连接点同步，所以需要避免在聚集和累积操作数据时所述处理流程失真。

避免聚集和收集点互锁的方案是提供此处称为传送器(conveyor)的中间机制。这是贮存器的逻辑先进先出队列，其表示在处理流期间沿网络路径收集的完整的操作数据组。每个聚集实例向传送器输出完整的聚集贮存器，并且完整的贮存器被链接到传送器队列的末端。

当收集器准备从聚集机制累积更多数据时，从所述传送器中获得贮存器。所述传送器单独地负责贮存器排队并且从其队列中撤销贮存器排队，并且避免收集器与其聚集器之间的潜在的处理互锁。

异步(非锁定)排队在本领域是公知的，并且可以在许多平台上获得，因此不必在此详细描述这种特性。使用非锁定的、异步排队，所述聚集器不需要等待收集器。假定把适当的数据提供给监控部件，只有收集器需要等待。上述聚集机制给处理网络带来了最小的系统开销。

在消息中介实现方式中，统计聚集和收集机制分出单个收集线程，所述单个收集线程累积从消息流程的多个实例中聚集的统计数据。数据聚集涉及消息流程内的单独的处理线程，并且每个线程把数据聚集到所述流程的该实例的唯一贮存器中。当认为聚集贮存器对于处理线程来说是完整的时，将其在传送器上排队。

独立的线程专用于请求来自传送器的下一可利用聚集贮存器的收集器机制。所述传送器撤销聚集贮存器或者一批贮存器的排队，并且将其传递至所述收集器。然后，所述收集器累积适当的数据。

接下来是在用于消息中介中时本发明的具体例子。图7举例说明了消息中介消息流程内的合并节点使用。采用合并节点，在所谓的扇出(Fan-out)阶段生成请求消息。在扇入阶段期间，通过消息流程接收对所述请求的应答并且加以处理。图7A中的流程执行所述扇出处理。图6B中的流程执行扇入处理。在该情况下应注意的是，根据原始请求消息生成了四个请求。所有应答都集中于扇入流程中的单个输入队列。

在图8中，已经简化了处理单元的数目，以便更加清楚。除“构建应答”和“写应答”节点之外，包络“e1”表示整个扇出消息流程以及扇入流。第二包络“e2”仅仅包含来自扇出流和所有扇入流的“合并控制”节点。采用此方法，从包络“e1”聚集操作数据可用于分析请求消息的分布，而包络“e2”将集中在跨越两个消息流程的组合式合并处理。

Claims (32)

1.一种数据处理设备，包括一组用于监控并且存储与多个数据处理单元有关的操作数据的部件，其中该组部件包括响应于所接收的操作数据并且响应于数据收集的指定边界的一个或多个部件，以便把接收到的操作数据分配到对应于指定边界的离散数据分区中。

2.如权利要求1所述的数据处理设备，其中多个数据处理单元包括一组程序代码部件，所述程序代码部件被连接以便在计算机程序计算流程内形成一个或多个处理路径。

3.如权利要求1或者2所述的数据处理设备，其中该组部件包括数据聚集器，其响应对应于用户指定的数据处理单元组的物理边界来控制操作数据的分配，使得分配给特定离散数据分区的操作数据被限制为与用户指定的数据处理单元组有关的操作数据。

4.如权利要求1至3任一项所述的数据处理设备，其中该组部件响应对应于所指定的数据聚集周期的时间边界，以便把分配到特定离散数据分区中的操作数据限制为与所指定的数据聚集周期有关的操作数据。

5.如先前任一项权利要求所述的数据处理设备，其中所述该组部件响应对应于数据收集的指定边界的事件，以便把操作数据的分配从所述离散数据分区中的第一个切换为第二个。

6.如权利要求5所述的数据处理设备，其中所述事件是定时器期满。

7.如权利要求5所述的数据处理设备，其中所述事件是完成了数据处理流程的一个或多个执行的组。

8.如权利要求5所述的数据处理设备，其中所述事件是指定边界的改变。

9.如权利要求5所述的数据处理设备，其中所述事件是系统关闭。

10.如先前任一项权利要求所述的数据处理设备，包括：数据聚集器，用于把所选数据处理单元组的操作数据聚集到用于该组数据处理单元执行的每个处理线程的离散数据贮存器中；以及与所述聚集器异步运行的收集器，用于累积来自对应于所定义的逻辑边界的数据贮存器的数据。

11.如权利要求10所述的数据处理设备，包括基于队列的转送机制，用于接收来自于数据聚集器的数据贮存器，并且从中，所述收集器部件可以撤销贮存器的排队以便进行累积。

12.如权利要求3所述的数据处理设备，包括与多个数据处理单元相关联的一个或多个事件侦听器，用于响应被监控数据处理操作序列内的事件来向数据聚集器发送通知；其中所述数据聚集器响应来自于事件侦听器的通知来控制操作数据向所述离散数据分区中的离散数据贮存器的分配。

13.如权利要求12所述的数据处理设备，其中所述数据聚集器响应来自于事件侦听器的第一类型的通知，以便把操作数据的分配从所述离散数据分区之一内的第一个离散数据贮存器切换到第二个离散数据贮存器。

14.如权利要求13所述的数据处理设备，其中所述第一类型的通知是数据处理操作序列已经进入多个数据处理单元内的后续数据处理单元的通知。

15.如权利要求16所述的数据处理设备，其中所述第一类型的通知是被监控的数据处理操作序列完全执行的通知。

16.如权利要求12所述的数据处理设备，其中所述事件侦听器被配置为响应于与所述数据处理操作序列有关的第一个事件、向数据聚集器发送对特定数据处理操作序列开始数据聚集的通知，并且响应所述数据处理操作序列内的第二事件、发送对所述特定数据处理操作序列结束数据聚集的通知，并且其中所述数据聚集器响应所述开始通知来启动离散数据贮存器，并且所述数据聚集器响应所述结束通知来终止把操作数据分配至被启动的数据贮存器。

17.如权利要求12所述的数据处理设备，其中所述多个数据处理单元中的每个数据处理单元均包括用于接收数据的输入连接点，用于处理数据的操作数据处理部件，以及用于接收已处理数据以便从相应的数据处理单元输出的输出连接点；并且其中与多个数据处理单元相关联的事件侦听器中的每一个均位于连接点处，并且所述事件侦听器响应由相应连接点接收到的数据来向数据聚集器发送通知。

18.一种数据处理设备，包括一组用于监控并且存储与多个数据处理单元有关的操作数据的部件，其中该组部件的一个或多个部件响应于所接收的操作数据并且响应用于数据收集的用户指定边界，以便把接收到的操作数据分配到对应于用户指定边界的离散数据分区中。

19.如先前任一项权利要求所述的数据处理设备，包括用于为收集操作数据指定所期望的边界的用户接口。

20.一种用于监控与多个数据处理单元有关的操作数据的方法，包括如下步骤：

响应于接收到的操作数据，根据数据收集的指定边界把操作数据分配至离散数据分区，并且在所述离散数据分区内存储分配的操作数据。

21.如权利要求20所述的方法，其中多个数据处理单元包括一组程序代码部件，所述程序代码部件被连接以便在计算机程序计算流程内形成一个或多个处理路径。

22.如权利要求20或者21所述的方法，其中分配操作数据的步骤响应对应于用户指定的数据处理单元组的物理边界来控制操作数据的分配，使得分配给特定离散数据分区的操作数据被限制为与用户指定的数据处理单元组有关的操作数据。

23.如权利要求20至22中任一项所述的方法，其中分配操作数据的步骤响应对应于指定的数据聚集周期的时间边界以便控制操作数据的分配，使得分配给特定离散数据分区的操作数据被限制为与指定的数据聚集周期有关的操作数据。

24.如权利要求20至23任一项所述的方法，包括如下步骤：响应对应于数据聚集指定边界的事件，把操作数据的分配从所述离散数据分区中的第一个切换到第二个。

25.如权利要求24所述的方法，其中所述事件是定时器期满。

26.如权利要求24所述的方法，其中所述事件是完成了数据处理流程的一个或多个执行的组。

27.如权利要求24所述的方法，其中所述事件是指定边界的改变。

28.如权利要求24所述的方法，其中所述事件是系统关闭。

29.如权利要求20至28中任一项所述的方法，包括如下步骤：

响应于多个数据处理单元的被监控数据处理操作序列内的事件，使用一个或多个事件侦听器来生成事件通知；并且，

响应于来自所述事件侦听器的通知，控制把操作数据分配到所述离散数据分区中的离散数据贮存器。

30.如权利要求29所述的方法，包括与所述分配步骤异步执行的如下步骤：在离散数据分区内累积离散数据贮存器的操作数据。

31.一种计算机程序，包括用于控制数据处理设备操作的程序代码，在所述数据处理设备上执行所述程序代码以便执行如权利要求20至30任一项所述的方法。

32.一种计算机程序产品，包括记录在记录介质上的程序代码，用于控制数据处理设备的操作，在所述数据处理设备上执行所述程序代码以便执行如权利要求20至30任一项所述的方法。

Images