CN101366018B - 用于从事件流生成报告的方法和计算机系统 - Google Patents

Abstract

对事件流的多维聚集体用于基于关于什么事件可用的元数据来生成报告。聚集体定义工具接收该事件流，并响应于用户输入标识关注事件，并指定用于从事件定义活动的相关模式。一用户界面允许用户定义报告的期望维度结构，以及各个事件中的各数据项与该维度结构之间的映射。

Description

用于从事件流生成报告的方法和计算机系统

许多商业企业都使用计算机系统来监视和处理商业活动和交易。特别地，处理复杂交易和活动的商业实体经常会使用分布式计算机系统。由此，现有的网络、系统、应用程序、和业务本质上都是分布式和事件驱动的。

例如，一在线零售商可以使用业务应用程序来接收在线购买定单，使用库存应用程序来管理商店的库存以及与其供货商通信，并使用其它应用程序或服务来创建在线接口及管理货运。在另一个示例中，web服务器经常会面临沉重的客户机负荷，并且要为在大量不同的统一资源定位符(URL)上注册的许多脚本服务。因为每个客户机请求都可以引发多个监视事件，并且这些请求是彼此异步地且独立地处理的，所以该服务器生成一连续的监视事件流。在该示例中，网络管理员可能会对基于这些监视事件来分析网络性能非常感兴趣。

关注事件可在整个企业的各个地方发生。不幸地是，这种事件驱动系统的用户通常都不能容易地从事件流中提取信息，因为不存在可容易地评估这些事件中所包含的信息或检查关注的整体模式的中央位置。这会导致对事件驱动企业内的重要信息视而不见，而这可以严重地削弱用户对变化的和发展的形势的识别和反应能力。

当前所存在用于监视和集中远程事件的多种技术。例如，操作管理工具提供监视和报警，以及用于管理服务器事件的报告和趋势分析。并且，审核收集服务管理安全事件。在零售世界中，常规的射频识别(RFID)框架已对于跟踪存货等变得非常普遍。但是用户仍然不能快速地、方便地、和直观地定义用于聚集事件信息的报告。

例如，现有的业务活动监视(BAM)用户体验强调业务流程，并且将业务分析家和开发者的角色分离开来。在规范的BAM解决方案中，首先业务分析家会定义一观察模型(即，期望的数据视图)，随后开发者会将该模型映射到该实现中的可用事件。即使这种自顶向下的方法对于BAM作用较好，但是当该系统是由了解可用事件并且希望实质上自底向上(即，从事件到报告)前进的用户配置的时候，它并不能提供直观的解决方案。

概述

本发明的各实施例通过提供改进的事件报告来克服已知报告系统中的一个或多个缺陷，在该改进的事件报告中，用户可以基于有关什么事件可用的元数据来直接定义报告。同样，本发明的各个方面使得用户能够设想他们希望如何将事件流“成形为”数据和多维聚集体，而无需了解SQL和数据仓库。通过集中关注事件，用户可以容易地生成事件流的数据视图，并使用诸如在BAM工具中可用的那些相关处理器。在一方面，本发明可捕捉指定所关注的事件、所期望的相关模式和所期望的维度结构的用户输入，并随后在各个事件中的数据项和维度结构之间映射。有利地是，本发明的各方面均结合现有的BAM运行库来操作，以实质上将任何种类的事件流操纵到各聚集体中。

具有用于从事件流生成报告并定义直观的用户体验的计算机可执行指令的计算机可读介质体现本发明的其它方面。可选地，本发明的各实施例可以包括各种其他方法和装置。

其他特征中的一部分已显而易见，一部分则将在此后指出。

提供本概述以便以简单的方式来介绍以下在详细描述中进一步描述的一些概念。本概述并非旨在标识出所要求保护的主题的关键或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

附图概述

图1是示出实现本发明的一个实施例的示例性计算机系统的组件的框图；

图2是示出用于本发明的一个实施例的示例性事件流源的流程图；

图3是示出根据本发明的一个实施例的多维聚集体的各方面的示例性屏幕截图；

图4是示出根据本发明的一个实施例的多维聚集体的其他方面的示例性屏幕截图；

图5是示出根据本发明的一个实施例的用于选择关注事件的用户界面的各方面的示例性屏幕截图；

图6是示出根据本发明的一个实施例的用于定义活动语义的用户界面的各方面的示例性屏幕截图；

图7是示出根据本发明的一个实施例的用于定义维度结构并从事件模式映射的用户界面的各方面的示例性屏幕截图；

图8是实现本发明的一个实施例的其他方面的示例性计算机系统的框图；

图9是示出根据本发明的一个实施例的用于从事件流生成报告的示例性操作的流程图；

图10是示出含有用于实现本发明的各个方面的计算机可执行指令的示例性计算机可读介质的框图。

在所有附图中，相应的附图标记指示相应的部件。

详细描述

现参考图1，图1示出了其中可以实现用于定义对事件流的多维聚集的本发明的示例性计算环境20。如图所示，计算设备22执行用于处理事件流24以便生成表示该流中的信息的一个或多个报告26的计算机可执行指令。在一个实施例中，在计算设备22上实现的聚集体定义工具28捕捉涉及以下信息的用户输入：事件流24中的哪些事件是所关注的、期望的相关模式是什么、期望的维度结构是什么、以及事件中的数据项和维度结构之间的映射是什么。

为了示出本发明的各个方面，图2呈现了事件流24的一个示例。在该实例中，事件流24包括web服务器32中的诊断事件流。服务器32的管理员或其他用户可以通过定义该事件数据如何“成形”来获得各种报告。出于说明的目的，web服务器32能够执行外部脚本34，并且装备有四个监视事件(一般在A、B、C和D处示出)。当客户机向服务器32打开一套接字时，它可发送一带有脚本34的URL及一些自变量的请求(例如，HTTP GET)。随后，服务器32定位并执行适当的脚本34，这会产生某一输出。图2示出了用于执行脚本34的组件36。服务器32用诸如200(OK)或500(内部服务器错误)等状态码来回复，并在关闭套接字之前将来自脚本或错误信息的输出流传送到客户机。

在一个实施例中，四个诊断事件A、B、C、D可用于监视web服务器32。在A处，事件HTTPRequest_Begin(HTTP请求开始)包含诸如URL和输入请求的字节大小等数据；在B处，事件ScriptExecution_Begin(脚本执行开始)在服务器32生成脚本进程(例如，Perl解释器)时发生；在C处，事件ScriptExecution_End(脚本执行结束)指示所执行的脚本34何时结束(或所得的错误代码)；在D处，事件HTTPRequest_End(HTTP请求结束)在完成该请求时(包括任意错误代码)发生。在该示例中，有可能发生的事件的列表以及这些列表将包含的数据的形状(即，其模式)是提前知道的。根据本发明的各方面，聚集体定义工具28利用事件元数据来处理事件流24。用于图2的示例的事件元数据可以用诸如以下所示的可扩展标记语言(XML)文件来体现，其中项目名称(Item Name)指定了元数据：

<Event Name＝”HTTPRequest_Begin”Id＝”235”>

     <Item Name＝”RequestID”Type＝”Guid”/>

     <Item Name＝”FromIP”Type＝”String”/>

     <Item Name＝”URL”Type＝”String”/>

     <Item Name＝”BytesIn”Type＝”Int32”/>

</Event>

<Event Name＝”StriptExecution_Begin”Id＝”236”>

     <Item Name＝”RequestID”Type＝”Guid”/>

</Event>

<Event Name＝”ScriptExecution_End”Id＝”237”>

     <Item Name＝”RequestID”Type＝”Guid”/>

     <Item Name＝”ReturnCode”Type＝”Int32”/>

</Event>

<Event Name＝”HTTPRequest_End”Id＝”238”>

     <Item Name＝”RequestID”Type＝”Guid”/>

     <Item Name＝ResultCode”Type＝”Int32”/>

     <Item Name＝”BytesOut”Type＝”Int32”/>

</Event>

再参考图2，服务器32可能会面临来自许多客户机的沉重负担，并且要为在不同URL处注册的许多不同的脚本34服务。由于在该示例中，每个请求会引起四个监视事件，并且该请求是彼此异步且独立地处理的，所以服务器32生成一连续的监视事件流。因此，对于正被同时处理的请求的事件将被交错。

脚本34中的至少某一些含有错误并且将失败是不太可能的。当这种错误发生时，web服务器32向客户机返回一错误500(内部服务器错误)，但是出于安全原因，它可能不会传播错误代码。服务器32的管理员可能有兴趣了解哪些脚本34失败了、其失败的频率、以及具有什么错误代码。图3是示出根据本发明的一个实施例的多维聚集体的各方面的示例性屏幕截图，其中假设向用户管理员提供的这种类型的信息是有用的格式(例如，每个URL多条错误理由)。该信息包含在监视事件流(即，事件流24)内。

在web服务器示例中，URL在一个事件中，来自脚本34的错误代码在另一个事件中，而HTTP结果代码(HTTP Result Code)位于还有一个事件中。为了获得如图3所示的示例性报告，包含聚集体定义工具28的系统20可对每个独立的请求将事件相关或“放在一起”。换言之，聚集体定义工具28允许系统20将关注事件累积到一个表示整个活动(即，工作单元)报告内，并随后将各个活动聚集成多维结构。在图3中，该多维聚集体累积按URL并且按{HTTPResult，ReturnCode}分组的全部调用。

web服务器32的管理员所关注的另一个报告可以是关于该服务器的性能(例如，对每个URL执行请求所花费的时间是多少、以及花费了该时间的多少百分比来等待脚本34完成)。图4是示出根据本发明的一个实施例的多维聚集体的其它方面的示例性屏幕截图。在该示例中，系统20呈现了示出每个URL的请求持续时间(即，事件A和D之间的持续时间)以及每个URL的脚本持续时间(即，事件B和C之间的持续时间)的报告。在所示的结构中，该报告具有一个维度(URL)和两个度量(请求持续时间和脚本持续时间)。

如之前的示例一样，所关注的数据被包含在多个事件中。例如，URL在HTTPReguest_Begin中；该请求的平均持续时间可通过对每一请求在HTTPRequest_Begin和HTTPRequest_End之间的时间求平均来计算；并且脚本持续时间通过对ScriptExecution_Begin和ScriptExecution_End之间的时间求平均来计算。web服务器32的管理员再次基于其元数据获知事件。在该实例中，管理员可能已经知道那些报告是所需要的，并且对于应该如何处理数据具有至少一个高级概念。不幸地是，现有技术要求开发者将此信息作为要求，并随后构建数据仓库来生成关注报告。本发明的各个实施例有利地允许管理员以其可被直接执行的结构化方式捕捉要求。

现参考图5、6和7，本发明的各个方面用如下三个步骤来捕捉用户输入：选择关注事件、指定相关(即，活动(Activity)语义)、以及指定事件数据如何转换成聚集体(即，维度结构和映射)。

图5是示出根据本发明的一个实施例的用于选择关注事件的用户界面的各个方面的示例性屏幕截图。图5继续web服务器32的示例。如图所示，该用户界面提供了用于定义观察模型，即换言之，用于选择关注事件的工具。在开始时，该工具的左窗格什么也没有示出。当管理员点击“添加事件”按钮时，该用户界面显示一例如按照元数据示出事件列表的对话框。管理员可以随后选择关注事件(并点击OK)。该对话框(或弹出窗口)消失，并且现在左窗格填充有所选择的事件的模式。在该实例中，系统20可从事件元数据中检索模式。

图5的用户界面还允许管理员定义相关准则，即他或她将什么认为是多个事件属于同一活动(例如，HTTP请求)的指示。例如，管理员可以通过右击每个事件中的字段“RequestID”并从上下文菜单中选择“形成相关键”来选择用于对事件分组的RequestID。另外，管理员指定哪些事件是所定义的活动中的第一(开始(Begin))和最后(结束(End))事件。例如，管理员可通过右击事件根，并从上下文菜单中选择“开始”/“结束”来作出这一选择。应了解，该用户界面描述只是示例性的，并且用户可以用其它方式(例如，拖放或复选框)来指定关注事件和相关准则。

作为这些操作的结果，图5的左窗格内的示图现在如图6所示。图6是示出根据本发明的一个实施例的用于定义活动语义(例如，相关(Correlation)、开始和结束事件)的用户界面的各个方面的示例性屏幕截图。在该示例中，管理员右击来将RequestID标记为相关键(Correlation Key)(即，哪些事件与该RequestID相关)。在HTTPRequest_Begin的根处的图形图标指示这是活动的开始事件(例如，通过将根处的圆圈改变为绿色的三角形)。类似地，在HTTPRequest_End的根处的图形图标指示这是活动的结束事件(例如，通过将根处的圆圈改变为红色的方框)。两个事件中的净荷数据项“RequestID”在图6中都被高亮显示为相关键。

即非开始也非结束的多个事件可属于同一活动，并且只要这些事件中只有一个事件在该活动任意特定实例中发生，则可能会有多个开始/结束事件。并且，在图6的示例中，使用了单个相关键。本领域的技术人员应了解，管理员可以定义具有略微更复杂的UI姿势的更复杂模式(例如，类似于BAM延续)。

指定相关键和开始-结束可告知流处理系统如何将某些事件实例认为是共同附属的、何时启动新的实例、以及何时丢弃数据。可选地，这种活动模式可能已经以注释的形式存在于事件元数据中，如以下的示例所示：

<Event Name＝”HTTPRequest_Begin”Id＝”235”ActivityBeqin＝”True”

CorrelationKey＝”RequestID”>

       <Item Name＝”RequestID”Type＝”Guid”/>

       <Item Name＝”FromIP”Type＝”String”/>

       <Item Name＝”URL”Type＝”String”/>

       <Item Name＝”BytesIn”Type＝”Int32”/>

</Event>

<Event Name＝”ScriptExecution_Begin”Id＝”236”CorrelationKey＝”RequestID”>

       <Item Name＝”RequestID”Type＝”Guid”/>

</Event>

<Event Name＝”ScriptExecution_End”Id＝”237”CorrelationKey＝”RequestID”>

       <Item Name＝”RequestID”Type＝”Guid”/>

       <Item Name＝”ReturnCode”Type＝”Int32”/>

</Event>

<Event Name＝”HTTPRequest_End”Id＝”238”ActivityEnd＝”True”

CorrelationKey＝”RequestID”>

       <Item Name＝”RequestID”Type＝”Guid”/>

       <Item Name＝”ResultCode”Type＝”Int32”/>

       <Item Name＝”BytesOut”Type＝”Int32”/>

</Event>

在该实例中，由于元数据指定活动模式，所以管理员可以跳过之前的手动步骤，而只选择关注事件，从而再次获得如图6所示的结果。

在该示例中，一旦管理员指定了关注事件和活动模式，该管理员就可以定义如何聚集活动。为了这样做，在该示例中，管理员可以将各项从左边的事件模式处拖到图5、6和7的UI的右窗格中。一旦放下了一个项，该项就支持具有诸如“形成度量”或“形成维度”等选项的上下文菜单。通过从这些选项中选择，管理员用右窗格中附带的图标来定义新的树结构。图7是示出根据本发明的一个实施例的用于定义维度结构和从事件模式进行映射的用户界面的示例性屏幕截图，以便支持期望的报告(例如，图3和4)。

对于web服务器的示例更进一步地，管理员可能会注意到诸如图3所示的期望报告使用了对所有请求的计数。这与对事件HTTPRequest_Begin的发生的计数相同。因此，管理员将事件的根拖到右边，随后对其右击并选择“形成度量”。此时，圆形图标变为加号。图3中的报告可区分对不同URL的计数。在该实例中，URL是一个维度，因此管理员可将“URL”拖到右边，并从其上下文菜单中选择“形成维度”。

图3上的计数还首先按照脚本34中的HTTP结果代码(HTTP ResultCode)，随后再按照返回代码(Return Code)来分组。这可以通过定义一具有两个等级的维度来实现。管理员将HTTPResultCode拖到右边并选择“形成维度”，这将其转换成与该URL相类似的维度子树。管理员随后将RetrunCode从StriptExecution_End事件拖到该维度的根上。因此，返回代码变为同一纬度中的另一等级。最后，管理员将该维度重命名为“错误(Error)”。

为了获得图4所示的报告，对从第一到最后事件的持续时间求平均。为了在工具中实现这一步，管理员再次拖动HTTPRequest_Begin的根，但是此时管理员选择“开始持续时间(Start Duration)”。出现具有例如时钟和度量箭头图标的新节点，并且该事件作为此持续时间(Duration)节点下的开始(Start)节点来移动。管理员随后将HTTPRequest_End的根拖到持续时间节点上，并使它表现为对该持续时间的结束事件。最后，管理员点击持续时间节点，并选择“形成度量”。他或她随后选择聚集功能(平均(Average))，并使得一新的度量(Measure)节点表现为该持续时间的父节点。管理员随后将此命名为他或她想要在各报告中看见的名称。管理员可以将另一个持续时间(例如，在ScriptExecution_Begin和ScriptExecution_End之间)定义为度量。

如果现在管理员点击位于用户界面工具的右窗格中的任一项(例如，ReturnCode)，则事件元数据中的相应项会得到高亮显示，从而可以清楚该项来自何处。如此，该工具现在包含关于如何产生例如图3和4中的报告的足够信息。

应了解，本发明的各个方面并不限于UI的特定外观和特定姿势。相反，该用户界面提供了一种允许用户捕捉诸如哪些事件是关注的、活动(相关)语义、期望的维度结构(包括持续时间)、以及时间和维度结构之间的映射等多条信息的工具。而且，上述web服务器34和管理员使用情况只是示例性的。本领域的普通技术人员将容易了解，例如企业用户可以用从诸如RFID等模式化事件源所得的相同的简易性来定义关注报告。一般而言，本发明的各个方面适用于任何用户以及具有已知元数据的任意事件流。

图8是实现本发明的一个实施例的其它方面的示例性计算机系统的框图。为了说明在该工具中所收集的信息足以执行的程度，本发明的一个实施例可以被用来配置一现有的BAM基础结构。在该实施例中，事件流24形式的元数据描述可能会发生的可能(即可用)事件的模式。聚集体定义工具28如上所述地使用元数据。聚集体定义工具28在其输出处产生BAM定义38(例如，XML文件)。该BAM定义38可以是描述关注的活动、度量和维度的标准格式。命令行工具bm.exe 40使用BAM定义38，并产生知晓流的数据仓库42(例如，动态BAM基础结构)。来自工具28的另一输出是截取配置46，它定义了事件和BAM仓库42中的活动之间的相关线索和映射。

在运行时，诸如MOM(操作监视事件)、用于Windows的审核收集服务(安全审核事件)或RFID(业务事件)等基础结构或收集机制48收集事件。相对较小的可插组件(例如，截取器50)对各个事件进行过滤并将其从其原始模式转换为活动改变(Active Change)事件，这类似于BAM API的签名。另一个组件(或同一组件)使用该活动改变事件并调用BAM API。

图9是示出根据本发明的一个实施例的用于从事件流24生成报告的示例性操作的流程图。在操作中，计算机22执行用于执行一种从包含多个事件的事件流24生成报告的方法的计算机可执行指令。在60处开始，聚集体定义工具28接收事件流24，并检错与关注事件相关联的元数据。在62处，基于用户输入，标识事件流24中的一个或多个关注事件。前进到64处，聚集体定义工具基于元数据在66处定义如何将这些关注事件相关。本发明的各个方面允许在66处为报告定义维度结构，并随后在68处将相关的事件映射到该维度结构来生成报告。在70处，发生对事件流的连续处理，并且在72处，一用户界面以报告的形式向用户呈现表示该映射的信息。

图1所示的示例性操作环境包括诸如执行计算机可执行指令的计算机等通用计算设备(例如，计算设备22)。计算设备通常具有至少某种形式的计算机可读介质。包括易失性和非易失性介质、可移动和不可移动介质两者的计算机可读介质可以是能被通用计算设备访问的任意可用介质。作为示例而非限制，计算机可读介质包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任意方法或技术实现的易失性和非易失性、可移动和不可移动介质。

图10是示出包含有用于实现本发明的各个方面的计算机可执行指令的示例性计算机可读介质76的框图。如图所示，本发明的一个实施例包括事件模式组件、聚集体定义工具、和业务活动监视器。

通信介质通常以诸如载波或其他传输机制等已调制数据信号来体现计算机可读指令、数据结构、程序模块或其他数据，并且包括任何信息传送介质。本领域的普通技术人员对已调制数据信号较为熟悉，该已调制数据信号以可在信号中编码信息的方式来设置或改变其一个或多个特征。有线介质(诸如有线网络或直接线连接)和无线介质(诸如声学、RF、红外、和其他无线介质)都是通信介质的示例。上面各项的任意组合也包括在计算机可读介质的范围之内。计算设备包括或可访问可移动和/或不可移动、易失性和/或非易失性存储器形式的计算机存储介质。用户可以通过诸如键盘和定点设备(例如，鼠标、跟踪球、笔或触摸垫)等输入设备或用户界面选择设备向计算设备输入命令或信息。其他输入设备(未示出)可以被连接到计算设备。监视器或其他类型的显示设备(未示出)也被连接到该计算设备。除监视器以外，计算机通常包括诸如打印机和扬声器等其他外围输出设备(未示出)，其可以通过输出外围设备接口(未示出)来连接。

计算机22可以使用到一个或多个远程计算机的逻辑连接在网络环境下工作。远程计算机可以是个人计算机、服务器(例如，服务器32)、路由器、网络PC、对等设备或其他常见的网络节点，并且通常包括以上相对于计算机22所描述的许多或全部元件。这种网络环境在办公室、企业范围计算机网络、内联网、和全球计算机网络(例如，因特网)中是较常见的。

虽然结合示例性计算系统环境进行了描述，但是本发明的各个方面可用许多其他通用或专用计算环境或配置来操作。该计算系统环境并非旨在对本发明各方面的使用范围或功能提出任何限制。此外，不应将该计算系统环境解释为对在该示例性操作环境中所示出的组件中的任意一个或其组合具有任何依赖性或要求。可适于用在本发明的实施例中的公知计算系统、环境、和/或配置的示例包括但不限于，个人计算机、服务器计算机、手持式或膝上型设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费电子产品、移动电话、网络PC、小型计算机、大型计算机、包含有任意上述系统或设备的分布式计算环境等。

本发明的实施例可在诸如程序模块等由一个或多个计算机或其它设备执行的计算机可执行指令的上下文中描述。一般而言，程序模块包括，但不限于，执行特定的任务或实现特定的抽象数据类型的例程、程序、对象、组件、和数据结构。本发明的各个方面还可以在其中任务由通过通信网络链接的各个远程处理设备来执行的分布式计算环境中实施。在分布式计算环境中，程序模块可位于包含有存储器存储设备的本地和远程计算机存储介质两者中。

除非另外指定，否则在此示出和描述的方法的执行或履行的顺序并不是必要的。即，除非另外指定，否则发明人构想了这些方法中的各个元素可以用任何顺序来执行，并且这些方法可包括比在此公开的更多或更少的元素。例如，可以构想在另一个元素之前、与其同时或在其之后执行或履行一特定元素都在本发明的范围之内。

本发明的各个实施例可以用计算机可执行指令来实现。计算机可执行指令可以被组织成一个或多个计算机可执行组件或模块。本发明的各个方面可以用任意数目或组织的这类组件或模块来实现。例如，本发明的各个方面不限于在附图中示出且在此描述的特定计算机可执行指令或者特定组件或模块。本发明的其他实施例可以包括具有比在此所示出和描述的更多或更少的功能的不同计算机可执行指令或组件。

当介绍本发明或其实施例中的要素时，冠词“一”、“一个”、“该”和“所述”都旨在表示存在一个或多个要素。术语“包括”、“包含”和“具有”都旨在是涵盖性的，并表示可以有除所列要素外的其他要素。

鉴于上述内容，可以看到，实现了本发明的多个目的，并且获得了其他有利的结果。

由于可以对上述的构造和方法作出各种改变而不会偏离本发明各实施例的范围，因此上面的描述所包含的以及附图所示出的所有主题都应被解释为是说明性的，而不是限制的意义。

Claims (14)

1.一种从事件流生成报告的计算机化的方法，所述事件流包括多个事件，所述方法包括：

标识所述事件流中的一个或多个关注事件；

检索与所述关注事件相关联的元数据；

基于所检索到的元数据将所述关注事件相关；

定义所述报告的维度结构；以及

将所述相关的关注事件映射到所述维度结构，以生成所述报告。

2.如权利要求1所述的方法，其特征在于，还包括向用户呈现表示所述映射的信息。

3.如权利要求2所述的方法，其特征在于，呈现表示所述映射的信息包括生成一图形报告。

4.如权利要求3所述的方法，其特征在于，所述图形报告包括以下各项中的至少一项：条形图、饼图和表格。

5.如权利要求1所述的方法，其特征在于，标识所述关注事件包括接收定义一个或多个活动的用户输入，所述每个活动都包括所述事件流中的至少一个事件的多个实例。

6.如权利要求5所述的方法，其特征在于，还包括为所定义的活动中的每一个定义一开始事件和一结束事件。

7.如权利要求1所述的方法，其特征在于，标识所述关注事件包括向用户显示一事件模式，所述事件模式显示所述事件流中的事件以及与所述事件相关联的元数据。

8.一种用于从事件流生成报告的计算机系统，所述事件流包括多个事件，所述计算机系统包括：

用于标识所述事件流中的一个或多个关注事件的装置；

用于检索与所述关注事件相关联的元数据的装置；

用于基于所检索到的元数据将所述关注事件相关的装置；

用于定义所述报告的维度结构的装置；以及

用于将所述相关的关注事件映射到所述维度结构，以生成所述报告的装置。

9.如权利要求8所述的计算机系统，其特征在于，还包括用于向用户呈现表示所述映射的信息的装置。

10.如权利要求9所述的计算机系统，其特征在于，用于呈现表示所述映射的信息的装置包括用于生成一图形报告的装置。

11.如权利要求10所述的计算机系统，其特征在于，所述图形报告包括以下各项中的至少一项：条形图、饼图和表格。

12.如权利要求8所述的计算机系统，其特征在于，用于标识所述关注事件的装置包括用于接收定义一个或多个活动的用户输入的装置，所述每个活动都包括所述事件流中的至少一个事件的多个实例。

13.如权利要求12所述的计算机系统，其特征在于，还包括用于为所定义的活动中的每一个定义一开始事件和一结束事件的装置。

14.如权利要求8所述的计算机系统，其特征在于，用于标识所述关注事件的装置包括用于向用户显示一事件模式的装置，所述事件模式显示所述事件流中的事件以及与所述事件相关联的元数据。

Images