通过上下文分区的经分类的事件监视的制作方法

通过上下文分区的经分类的事件监视的制作方法
【专利摘要】事件监视系统包括两个阶段，事件分类阶段和事件处理阶段。事件分类阶段接收由至少一个应用提供的事件并包括多个事件分类系统。事件处理阶段包括至少一个事件处理系统，其处理被事件分类阶段转发的事件。事件处理系统能够处理落在对应于相应事件处理系统的一个或多个上下文分区的特定集合内的事件。当事件分类系统接收事件时，事件分类系统标识该事件落在哪个上下文分区内。事件分类系统接着标识对应于该事件的所标识的上下文分区的事件处理系统，并接着将该事件转发到所标识的事件处理系统。事件处理系统接着应用一个或多个监视规则的集合。
【专利说明】通过上下文分区的经分类的事件监视
[0001 ] WS
[0002] 操作监视系统通常针对在操作期间生成的事件流来应用监视规则。事件流被用于 评估或表征操作，诸如操作是否正常地进行或一个或多个问题是否发生。用于测量这样的 监视系统的效率的关键度量之一是平均缓解时间(MTTM)的不足。MTTM指测得的从问题首次 出现的时刻到问题被缓解时的平均时间。MTTM依赖于称为检测时间（TTD)的度量，其是从当 问题首次出现直到问题被检测到的时间。最终，用于缓解问题的一系列动作直到问题自身 被标识之前不能被发起。
[0003] 因此，已经在这样的监视系统中开发了低等待时间问题检测方案。一种提供低等 待时间的方式是通过将本地事件处理卸载到代理机器上，而同时将跨组件、聚集和其他较 高等级的处理留给中央管理服务器。当本地代理能覆盖针对给定应用的监视需求时，这种 方案对被部署在单个机器上的应用运行良好。
[0004] 简要概述
[0005] 本文中描述的至少一些实施例涉及事件监视系统，该事件监视系统包括两个阶 段，事件分类阶段和事件处理阶段。事件分类阶段接收由至少一个应用提供的事件并包括 多个事件分类系统。事件处理阶段包括至少一个事件处理系统，其处理被事件分类阶段转 发的事件。事件处理系统能够处理落在对应于相应事件处理系统的一个或多个上下文分区 的特定集合内的事件。
[0006] 当事件分类系统接收事件时，事件分类系统标识该事件落在哪个上下文分区内。 上下文分区指一个或多个特征的集合，其中拥有该特征集合的所有事件将在相同的一个或 多个监视规则的集合下被监视。事件分类系统接着标识对应于事件的所标识的上下文分区 的事件处理系统。事件接着被转发到所标识的事件处理系统。事件处理系统接着应用该一 个或多个监视规则的集合。
[0007] 由于对应于特定上下文分区的所有事件在单个事件处理系统上被处理，事件处理 可高效地发生，从而允许事件流也被高效地处理，即使事件流由分布式应用生成，并向不同 的事件分类系统提供不同的流。
[0008] 该概述不旨在标识所要求保护的主题的关键特征或基本特征，也不旨在被用来帮 助确定所要求保护的主题的范围。
[0009] 附图简述
[0010] 为了描述能够获得上述和其它优点和特征的方式，各实施例的更具体的描述将通 过参考各附图来呈现。可以理解，这些附图只描绘了示例实施例，并且因此不被认为是对其 范围的限制，将通过使用附图并利用附加特征和细节来描述和解释各实施例，在附图中：
[0011] 图1抽象地例示出其中可采用本文描述的一些实施例的计算系统；
[0012] 图2示意性地例示出在其中应用向事件监视系统提供事件的事件监视环境；
[0013] 图3示意性地例示出事件监视系统，该事件监视系统表示图2的事件监视系统的示 例，并包括具有多个事件分类系统的事件分类阶段和具有多个事件处理阶段的事件处理阶 段；
[0014] 图4例示出用于对传入事件进行分类的事件分类系统(诸如那些在图3中显示的） 的方法的流程图；
[0015] 图5例示出用于处理传入事件的事件处理系统（诸如那些在图3中显示的）的方法 的流程图；
[0016] 图6例示出用于将监视规则应用到接收自事件分类阶段的事件的方法的流程图。
[0017] 详细描述
[0018] 本文中描述的至少一些实施例涉及事件监视系统，该事件监视系统包括两个阶 段，事件分类阶段和事件处理阶段。事件分类阶段接收由至少一个应用提供的事件并包括 多个事件分类系统。事件处理阶段包括至少一个事件处理系统，其处理被事件分类阶段转 发的事件。事件处理系统能够处理落在对应于相应事件处理系统的一个或多个上下文分区 的特定集合内的事件。
[0019] 当事件分类系统接收事件时，事件分类系统标识该事件落在哪个上下文分区内。 上下文分区指一个或多个特征的集合，其中拥有该特征集合的所有事件将在相同的一个或 多个监视规则的集合下被监视。事件分类系统接着标识对应于事件的所标识的上下文分区 的事件处理系统。事件接着被转发到所标识的事件处理系统。事件处理系统接着应用该一 个或多个监视规则的集合。
[0020] 由于对应于特定上下文分区的所有事件在单个事件处理系统上被处理，事件处理 可高效地发生，从而允许事件流也被高效地处理，即使事件流由分布式应用生成，并向不同 的事件分类系统提供不同的流。
[0021] 将参考图1来描述对计算系统的一些介绍性讨论。接着，将参考后续附图来描述事 件监视系统及其操作的实施例。
[0022] 计算系统现在越来越多地采取多种多样的形式。例如，计算系统可以是手持式设 备、电器、膝上型计算机、台式计算机、大型机、分布式计算系统或甚至常规上不被认为是计 算系统的设备。在本说明书以及权利要求书中，术语"计算系统"被广义地定义为包括任何 设备或系统(或其组合），该设备或系统包含至少一个物理有形的处理器以及其上能具有可 由处理器执行的计算机可执行指令的物理有形的存储器。存储器可以采取任何形式，并可 以取决于计算系统的性质和形式。计算系统可以分布在网络环境中，并可包括多个组分计 算系统。
[0023]如图1所示，在其最基本的配置中，计算系统100通常包括至少一个处理单元102和 存储器104。存储器104可以是物理系统存储器，该物理系统存储器可以是易失性、非易失 性、或两者的某种组合。术语"存储器"也可在此用来指示诸如物理存储介质这样的非易失 性大容量存储器。如果计算系统是分布式的，则处理、存储器和/或存储能力也可以是分布 式的。如本文中所使用的，术语"可执行模块"或"可执行组件"可以指可以在计算系统上执 行的软件对象、例程或方法。此处所描述的不同组件、模块、引擎以及服务可以实现为在计 算系统上执行的对象或进程(例如，作为分开的线程）。
[0024]在随后的描述中，参考由一个或多个计算系统执行的动作描述了各实施例。如果 这样的动作是以软件实现的，则执行动作的相关联计算系统的一个或多个处理器响应于已 经执行了计算机可执行指令来引导计算系统的操作。例如，这样的计算机可执行指令可以 在形成计算机程序产品的一个或多个计算机可读介质上实现。这样的操作的示例涉及对数 据的操纵。计算机可执行指令（以及被操纵的数据)可以存储在计算系统100的存储器104 中。计算系统100还可包含允许计算系统100例如通过网络110与其他消息处理器通信的通 信信道108。
[0025]此处所描述的各实施例可包括或利用专用或通用计算机，该专用或通用计算机包 括诸如例如一个或多个处理器和系统存储器等计算机硬件，如以下更详细讨论的。本文中 描述的各实施例还包括用于承载或存储计算机可执行指令和/或数据结构的物理和其他计 算机可读介质。这样的计算机可读介质可以是可由通用或专用计算机系统访问的任何可用 介质。存储计算机可执行指令的计算机可读介质是物理存储介质。承载计算机可执行指令 的计算机可读介质是传输介质。由此，作为示例而非限制，本发明的各实施例可包括至少两 种显著不同的计算机可读介质:计算机存储介质和传输介质。
[0026] 计算机存储介质包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储、磁盘存储或其他 磁存储设备、或可用于存储计算机可执行指令或数据结构形式的所需程序代码装置且可由 通用或专用计算机访问的任何其他有形介质。
[0027] "网络"被定义为使得电子数据能够在计算机系统和/或模块和/或其它电子设备 之间传输的一个或多个数据链路。当信息通过网络或另一个通信连接(硬连线、无线、或者 硬连线或无线的组合)传输或提供给计算机时，该计算机将该连接适当地视为传输介质。传 输介质可以包括可用于携带计算机可执行指令或数据结构形式的期望程序代码装置并可 被通用或专用计算机访问的网络和/或数据链路。上述的组合应当也被包括在计算机可读 介质的范围内。
[0028] 此外，在到达各种计算机系统组件之后，计算机可执行指令或数据结构形式的程 序代码资料可从传输介质自动传输到计算机存储介质（或反之亦然）。例如，通过网络或数 据链路接收到的计算机可执行指令或数据结构可以在网络接口模块(例如，"NIO内的RAM 中被缓冲，然后最终被传输至计算机系统RAM和/或计算机系统处的较不易失性的计算机存 储介质。因而，应当理解，计算机存储介质可被包括在还利用（或甚至主要利用)传输介质的 计算机系统组件中。
[0029] 计算机可执行指令例如包括，当在处理器处执行时使通用计算机、专用计算机、或 专用处理设备执行某一功能或某组功能的指令和数据。计算机可执行指令可以是例如二进 制代码、诸如汇编语言之类的中间格式指令、或甚至源代码。尽管用结构特征和/或方法动 作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述特 征或动作。相反，上述特征和动作是作为实现权利要求的示例形式而公开的。
[0030] 本领域的技术人员将理解，本发明可以在具有许多类型的计算机系统配置的网络 计算环境中实践，这些计算机系统配置包括个人计算机、台式计算机、膝上型计算机、消息 处理器、手持式设备、多处理器系统、基于微处理器的或可编程消费电子设备、网络PC、小型 计算机、大型计算机、移动电话、PDA、寻呼机、路由器、交换机等等。本发明也可在其中通过 网络链接(或者通过硬连线数据链路、无线数据链路，或者通过硬连线和无线数据链路的组 合)的本地和远程计算机系统两者都执行任务的分布式系统环境中实施。在分布式系统环 境中，程序模块可以位于本地和远程存储器存储设备二者中。
[0031] 图2示出了事件监视环境200。事件监视环境200包括应用210和事件监视系统220。 应用210可包括一个或多个应用，但在图2中，被示为包括应用211和212。省略号213符号上 表示应用210可具有比这些示出的应用211和211更多的应用，并且可能也可仅包括单个应 用。
[0032]事件监视系统220接收来自应用210的事件。例如，事件监视系统220通过205接收 来自应用210的事件201，虽然省略号206表示本文中描述的原理被用于监视来自应用210的 大量事件。
[0033]应用210中的一个或多个各自可位于单个计算系统(诸如图1的计算系统100)上。 应用210中的一个或多个可替换的是分布式应用，其中运行在不同计算系统上的组件可能 是位于远程的，并且可能可位于全球的不同部分。实际上，本文中描述的至少一些实施例的 特定优点是事件监视系统200可高效且快速地处理来自多个应用的事件，即使在这些应用 中的一个或多个或甚至全部是分布式的情况下。作为一示例，应用211被示出为包括两个组 件211A和211B(虽然分布式应用可具有多得多的组件）。两个组件211A和211B可被操作在不 同的计算系统上。
[0034]图3示出表示图2的事件监视系统200的示例的事件监视系统300。仅出于示例的目 的，事件监视系统300被示为通过图2的205来接收事件201。出于这个示例的目的，假设事件 201由应用210的组件211A生成，并且事件202和203由应用211的其他组件211B生成。进一步 假设事件204和205由应用212生成。
[0035]事件监视系统300包括两个阶段，包括事件分类阶段310和事件处理阶段320。事件 分类阶段310包括多个事件分类系统311到313,虽然省略号314表示事件分类阶段310可包 括任意数量的事件分类系统。事件处理阶段320包括多个事件处理系统321到324,虽然省略 号325表示事件处理阶段320可包括任意数量的事件处理系统。每个事件分类系统311到314 以及每个事件处理系统321到325可如以上针对图1的计算系统100所描述的来结构化。事件 分类阶段310和事件处理阶段320各自可以是分布式的。
[0036]事件分类阶段310接收来自各个应用(诸如图2的应用210)的事件(诸如事件201到 205)。例如，事件分类系统311到313中的每一个接收被事件分类阶段310接收到的总事件流 的子集。对于被给定事件分类系统311到313接收到的事件而言，事件分类系统311到313确 定与每个事件相关联的上下文分区，并接着将该事件转发到多个事件处理系统中专用于处 理该上下文分区的事件的任何一个。
[0037] "上下文分区"被定义为事件的一个或多个特征的集合，其中共享该共同的一个或 多个特征的集合的事件中的至少一些以相关的方式被共同地监视，以导致监视状态。由于 这个原因，如果共同上下文分区的事件在相同的机器上被监视，则事件可被更高效地监视。 一个或多个特征的集合的示例包括以下中的任意一个或多个:顾客标识符、应用标识符、托 管服务名称、角色标识符、命名空间、网络站点标识符、时间标识符等。这就是说，可被用于 定义分区的参数的身份是非常灵活的。例如，如以下详细描述的，分区分段标识符可被用于 实现回送以允许大得多的分区在多个阶段中被高效地处理。
[0038] 仅作为一个示例，事件处理系统321被示出为专用于处理两个上下文分区331A和 331B，事件处理系统322被示出为专用于处理单个上下文分区332,事件处理系统323被示出 为专用于处理两个上下文分区333A和333B，并且事件处理系统324被示出为专用于处理两 个上下文分区334A和334B。
[0039]这意味着，不管事件分类系统311到313中的哪个实际接收具有特定上下文分区的 事件，该事件将被转发到监视特定上下文分区的事件的正确的事件处理系统321到324。由 此，共同上下文分区的事件在相同的事件处理系统上被监视，从而被更高效地监视，即使针 对被分布式应用生成的事件。
[0040]当监视特定分区时被应用的监视规则在针对该分区的对应的事件处理系统上。这 种将监视规则定位到与监视规则要被应用到其的分区相同的事件处理系统允许对监视规 则的更快速的应用。
[0041 ] 这样的监视规则可包括标准监视规则和自定义监视规则。例如，标准监视规则可 被包含在与自定义监视规则相比不同的对象类中。标准监视规则对象可能包括更一般的输 入参数，诸如也许要被执行的监视的类型（例如，安全性）。另一方面，自定义监视规则可用 定义自定义监视的更具体的配置来填充。
[0042]监视规则还可被应用到流传输事件，致使状态被维护在与其流传输事件要被监视 的分区相关联的事件处理系统处。这样的状态可被维护在对应的事件处理系统的"处理器 可寻址数据容器(vessel)"中。在本申请中，"处理器可寻址的数据容器"被定义为数据可被 放置在其中并且可使用处理器来寻址的非易失性和/或易失性位置。处理器可寻址数据容 器的一个示例是计算机存储器，其可被处理器直接地寻址，并且其通常是易失性的，但在现 代系统中，其也可跨其有效地址位置的范围部分地或甚至完全地非易失性。
[0043]这个示例在被事件处理系统中的每一个处理的上下文分区的数量方面保持相对 简单。然而，被单个事件处理系统管理的上下文分区的数量可从如单个上下文分区那么少 到可枚举的上下文分区那样变化。可限制被单个事件处理系统处理的上下文分区的数量的 因素包括针对特定上下文分区的预期的传入事件的速率以及可被代码使用的处理器可寻 址数据容器的数量，该代码保持对被用于在上下文分区上执行监视规则的状态的跟踪。 [0044]越高的事件速率将产生对事件处理系统的处理资源的越高的需求。此外，对跟踪 状态的越大的需要将产生对事件处理系统的存储器资源的越高的需求。将所有状态保持在 存储器中是有利的，使得处理可更快速地发生，并由此对给定上下文分区的传入事件流应 用监视规则所需要的时间被减少。这通过将相同计算系统和相同处理器可寻址数据容器上 的共同上下文分区的所有事件合并来实现。
[0045] 图4示出用于对传入事件进行分类的事件分类系统(诸如事件分类系统311到313 中的任一）的方法400的流程图。图5示出用于处理传入事件的事件处理系统(诸如事件处理 系统321到324中的任一）的方法500的流程图。在更加详细地描述图4和5后，将参考图4和5 描述在事件监视系统300的上下文中的对事件201到205的示例处理。
[0046] 再次，图4示出用于对传入事件进行分类的事件分类系统的方法400的流程图。方 法400在特定事件分类系统接收事件(动作401)之际被启动。例如，参考图3的示例，事件分 类系统311接收事件201，事件分类系统312接收事件202和事件203,并且事件分类系统313 接收事件204和事件205。
[0047] 接收到该事件的事件分类系统接着标识该事件落入哪个上下文分区内（动作 402)，标识对应于该事件的所标识的上下文分区的事件处理系统(动作403)，并将该事件转 发到所标识的事件处理系统(动作404)。任选地，事件分类系统还修改该事件(动作405)，使 得事件处理系统可自己使用该事件来标识该事件属于哪个上下文分区。
[0048]例如，在图3中，响应于接收事件201(动作401)，事件处理系统311将上下文分区 332标识为对应于事件201(动作402)，将事件处理系统322标识为对应于上下文分区332(动 作403)，并如被箭头301表示的将该事件转发到事件处理系统322(动作404)。当分类事件 201时，事件分类系统311可能修改(动作405)事件201来添加上下文分区332的标识，使得事 件处理系统322可快速地标识该事件属于上下文分区332。替换地或附加地，也许事件不被 修改来标识相关联的事件的上下文分区，但是事件分类系统以某个其他方式(诸如在分开 的通信中）将信息(诸如分区标识符)提供到相关联的事件处理系统322。
[0049]进一步，响应于接收事件202(动作401)，事件处理系统312将上下文分区332标识 为对应于事件202(动作402)，将事件处理系统332标识为对应于上下文分区332(动作403)， 并如被箭头302表示的将该事件转发到事件处理系统322(动作404)。当分类事件202时，事 件分类系统312可能修改(动作405)事件202(和/或将分区标识符传送到对应的事件处理系 统）来添加上下文分区332的标识，使得事件处理系统322可快速地标识该事件属于上下文 分区332。
[0050] 继续该示例，响应于接收事件203(动作401)，事件处理系统312将上下文分区334A 标识为对应于事件203(动作402)，将事件处理系统324标识为对应于上下文分区334A(动作 403)，并如被箭头303表示的将该事件转发到事件处理系统324(动作404)。当分类事件203 时，事件分类系统312可能修改(动作405)事件203来添加上下文分区334A的标识(和/或将 分区标识符传送到对应的事件处理系统），使得事件处理系统324可快速地标识该事件属于 上下文分区334A。
[00511继续，响应于接收事件204(动作401)，事件处理系统313将上下文分区331B标识为 对应于事件204(动作402)，将事件处理系统321标识为对应于上下文分区331B(动作403)， 并如被箭头304表示的将该事件转发到事件处理系统321 (动作404)。当分类事件204时，事 件分类系统313可能修改(动作405)事件204来添加上下文分区331B的标识(和/或将分区标 识符传送到对应的事件处理系统），使得事件处理系统321可快速地标识该事件属于上下文 分区331B。
[0052]结束该示例，响应于接收事件205(动作401)，事件处理系统313将上下文分区334A 标识为对应于事件205(动作402)，将事件处理系统324标识为对应于上下文分区334A(动作 403)，并如被箭头305表示的将该事件转发到事件处理系统324(动作404)。当分类事件205 时，事件分类系统313可能修改(动作405)事件205来添加上下文分区334A的标识，（和/或将 分区标识符传送到对应的事件处理系统），使得事件处理系统324可快速地标识该事件属于 上下文分区334A。
[0053]事件分类阶段310还可以是分布式的，可能甚至贯穿全球。这可能可以解释为何在 这个示例中，由分布式应用211的组件211A生成的事件201被事件分类系统311接收，而由相 同的分布式应用211的组件211B生成的事件202和203被事件分类系统312接收。在这种情况 下，事件分类系统311从网络路由角度来说可能更接近(此后被简单地称为"网络接近"）第 一组件211A，而事件分类系统312可能更加网络接近第二组件211B。
[0054]图5示出用于处理传入事件的事件处理系统的方法500的流程图。例如，参考图5， 事件处理系统321将响应于接收(如被箭头304表示的）来自事件分类系统313的事件204来 执行方法500。类似地，事件处理系统322将响应于接收(如被箭头301表示的)来自事件分类 系统311的事件201来执行方法500，并还将响应于接收(如被箭头302表示的）来自事件分类 系统312的事件202来执行方法500。此外，事件处理系统324将响应于接收(如被箭头303表 示的）来自事件分类系统312的事件203来执行方法500，并还将响应于接收(如被箭头305表 示的）来自事件分类系统313的事件205来执行方法500。
[0055]方法500被事件处理系统在接收到来自事件分类阶段的事件之际启动(动作501)。 事件处理系统接着标识该事件属于的上下文分区（动作502)。例如，如果由于动作405的任 选执行上下文分区在该事件自身中被标识，则该事件的上下文分区可通过简单地读取上下 文分区标识符来被标识。要被应用到该分区的监视规则根据事件的上下文分区被访问并被 应用到该事件(动作503)。图6示出用于将监视规则应用到接收自事件分类阶段的事件的方 法600的流程图，并表示图5的动作503的示例。
[0056]根据方法600,输入事件可能被用于生成可对其采取动作的输出事件。首先，输入 事件被任选地记录(动作601)。事件处理系统接着验证一个或多个条件是否已经被满足(决 策框602)，在该一个或多个条件下，输出事件的生成被预测。如果条件没有被满足(决策框 602中的"否"），则对输入事件的处理结束(动作605)。
[0057]如果条件被满足（决策框602中的"是"），则输入事件被用于生成输出事件（动作 603)。输出事件可具有与输入事件不同的事件类型。事件类型的示例包括例如，1)性能度量 样本，其描述由应用提供的性能度量，2)在监视系统300中打开和关闭提醒的提醒改变事 件，3)指示特定服务是否可用的可用性状态事件以及4)其他事件，诸如自定义事件。
[0058]注意，关于条件是否被满足的决策(决策框602)可能基于与分区相关联的状态。例 如，假设监视规则是:如果在最近3小时的滚动窗口中接收到的所有事件都指示处理器使用 超过某个容量百分比，则生成警报事件。在这种情况下，也许存在在最近3小时内接收到的 数万个事件。现在假设，最新的事件导致3小时滚动平均值增加到阈值之上。关于条件是否 被满足的决策(决策框602)将接着实际涉及比对最新的事件进行分析多的多，但还将涉及 对其中关于先前9999个事件的信息被表示的分区状态的分析。
[0059]接着对输出事件采取动作(动作604)。动作604的内容示出可对输出事件采取的三 个潜在示例动作611、612和613。作为一个示例，事件处理系统可能将输出事件保存到(动作 611)诸如所标识的存储。替换地或附加地，事件处理系统可能将输出事件传送到系统外部 (动作612)。替换地或附加地，事件处理系统可能回送事件(动作613)，其现在将参考图3来 更详细地描述。
[0060]输出事件的回送本质上允许输出事件作为被分派给相同或不同分区的输入事件 以供进一步处理。在回送过程中，生成输出事件的事件处理系统可执行方法400并由此充当 事件分类系统并将输出事件作为对分类过程的接收到的输入来处置。
[0061 ]例如，一旦事件处理系统321将输入事件204处理为上下文分区331B的事件，来自 这样的处理的输出事件被回送(如被箭头343表示的）到相同的上下文分区331B以供进一步 处理为输入事件，并由此输出事件再次经受方法500。
[0062]回送箭头341和342示出回送的不同形式，其中来自一个分区的输出事件被提供为 到另一分区的输入事件。例如，事件处理系统322将事件201和202中的一个或两者处理为上 下文分区332的一部分以生成被回送(如被箭头341表示的）的输出事件。输出事件接着被处 理为具有新的上下文分区333B的输入事件。类似地，事件处理系统324将事件203和205中的 一个或两者处理为上下文分区334A的一部分以生成被回送(如被箭头342表示的）的输出事 件。输出事件接着被处理为具有上下文分区333B的输入事件。
[0063]在回送箭头341和342中的每一个的情况下，回送被用于允许事件处理阶段320对 事件链执行任务。此外，由于回送箭头341和342从不同的上下文分区到相同的上下文分区， 事件处理阶段320可用于分层地处理。
[0064] 当在没有分层处理的情况下上下文分区可一般比较大时，这可以是尤其有用的。 例如，也许到该上下文分区的输入流以非常高的速率到来，和/或对该上下文分区的状态的 跟踪可需要大量的存储器。在一些情况下，这样的大的上下文分区可仅仅太大以至于不能 被单个上下文分区处理。在这样的情况下，任务可被划分到若干较小的上下文分区（通过进 一步通过分区分段标识符来定义分区），每个较小的上下文分区进行相同的工作并产生中 间结果。例如，分区332和334A可表示这样的分区的示例。来自每个分区的输出事件可表示 中间结果，从而允许中间结果事件接着被上下文分区333B处理。对于相当大的分区，该分区 可能甚至被划分成数百个或数千个分段。这样的回送可能在单个工作流中被实现甚至两次 或更多次以允许处理的三个或更多阶段。
[0065] 实时地，针对任一特定上下文分区接收的事件可实际上被认为是输入事件流。对 输入事件流的处理产生输出事件流，即使可能具有更少的输出事件（由于跟随决策框602中 的"否"路径，对某些输入事件的处理将不导致输出事件的生成）。输出事件的数量可能甚至 是一个或多个或甚至比输入事件的数量少许多数量级。
[0066] 现在将描述监视规则的实现的示例。尽管如此，本文中描述的最广泛的原理完全 不被限定到被用于实现监视规则的代码，也不被限制到甚至软件本身是否被用于应用监视 规则。因此，这些代码示例应仅被视为说明性的。
[0067]在一个实施例中，可从用IObservable接口的特性建模的特殊选择器中访问监视 规则中的经类型化的事件的输入事件流。该.Net接口被StreamInsight和Rx两者用作针对 时间查询的传入和外发数据流的模型。这样的时间查询可从称为IPartitionData的特定接 口中访问。例如，考虑以下代码示例： public class EiasicExainpie : IRule { public I〇bservable<Empty> Initialize(IPartitionData data) var query = from pf in data.PerfMetricSampIes
[0068] where pf.Value > 90 select new MonitorState { Name = "Value is too high". MonitorId = pflMetrield, State = States.Error I); return Empty.CreateObservable(query);
[0069] } }
[0070] 这个规则用C#类来编写并使用在Rx句法中针对被称为"IPartitionData data (IPartitionData数据)"和"data · PerfMetricSamples"的选择器来定义的时间查询。这个 选择器提供某个分区内类型Performance Metric Sample(性能度量样本)的事件流。由此， 在这个情况下，输入事件流由来自针对接收自事件分类阶段的那个分区的每个输入事件的 各部分组成。规则实现被主控在用interface(接口）INamespaceRule来标记的类的方法 Initialize (初始化)的内部，该方法被用于初始化规则实例。
[0071 ] 具有I Par t i t i onData接口的数据访问对象包括分区i d和命名空间i d特性以及被 该接口的以下声明所表示： public interface iPartitionData ? IObservable<PerfMetricSample> PerfMetricSainples ； get; } string NainespaceId { get; } string PartitionId { get; | }
[0072] ...
[0073] 类型IObservable〈Empty>的所得到的流被用于保持对查询实例的引用以监听查 询状态一以防它异步地抛出异常或停止。所得到的事件本身可被忽略。这就是为何称为 "Empty (空)"的存根结构被使用，而非实值被使用。
[0074]接口的名称暗示这个规则将被应用到某个特定命名空间的每个分区的流。这允许 创建规则，这应当对整体事件流中的每个数据项起作用一就好像来自这个示例中的检测场 景，也许好像"在性能数据存储系统内部聚集和存储针对这个特定顾客的所有提交的性能 度量"的规则。
[0075]用于规则实现的一个选择也可以是StreamInsight(流洞察）查询。可以根据以下 在Rx和StreamInsight上下文之间切换。当时间本身是自然地流动并不被控制并且事件的 次序不被定义时，Rx是用于处理在时间上观察到的事件序列的良好匹配。这仅允许本地时 间跨度内的模糊时间事件相关逻辑（除非专用调度器（Scheduler)被使用）。另一方面， StreamInsight技术允许表达基于严格时间的查询，如一个事件时间在绝对精度上等于另 一事件时间，而非在某个ε内一如同对于Rx是普遍的。
[0076] 自然时间流动实际上是用于许多监视场景的情况。实际上，以下示例将用Rx来表 达，因为它们不需要广泛地驱动最精确的时间相关并且在某个ε内的本地时间跨度操纵是 充足的。然而，具有在StreamInsight句法中实现的查询的基本示例显示另一时间引擎如何 可在这个监视规则模型中被自然地使用。
[0077] 为了定义针对给定事件类型的流的某个动作一以下内置操作符可被使用： SaveAlert(保存提醒）、SavePerfSample(保存性能样本）、Send(发送）、Loopback(回送）。 SaveAlert可被应用到提醒改变提醒的流或者操作符可被提供选择器来将给定的事件流转 换成提醒改变事件。这个操作符将监视器状态的流保存到提醒存储，其进而打开或关闭提 醒。SavePerfSample具有与SaveAlert相同的逻辑，但是将数据发送到性能数据存储系统并 可被应用到性能计数器事件或可用性状态提醒的流(或被提供对应的选择器KSend可将数 据推送到系统外部(来通知例如合作方监视系统KLoopback如以上解释的共享针对相同或 另一分区的次级查询的所得到的事件(例如，第一查询聚集跨源的计数器并且第二查询定 义针对所聚集的计数器的检测）。
[0078] 所以，为了在监视系统中注册针对以上查询的提醒，可如以下添加针对 Mon i tor Stat e (监视器状态)事件的流的SaveAl ert操作符： public class AlertingRule : IRule {
[0079] public IObservable<Einpty> Initialize(IPartitionData data) { var query = (from pf in dala.PerflVletricSainples where pf·Value > 90 select new MonitorState { Name = "Value is too high", MonltorId- pf.Metricld.
[0080] Stale = Stales. Error }),SaveA!eri(); return Empty.CreateObservable(query); }
[0081 ]另一形式允许对具有少一个操作符并具有操作符ToEmpty的相同语义的定义，其 包装查询，链接在一起为如下： public class AIertingRule : IRule { public IObservable<Empty> InitiaIize(!PartitionDala data) { return data .PerilVl etr i c S am pies
[0082] .Whereipf ===> pf'.Value > 90) ,SaveAlert(pf => new MonitorState { Name = ftValue is loo highM, MetricId :=== pf.Metridd, State = Slates. Error }) ToEmptyO;
[0083] } }
[0084] 这个查询将为系统生成针对定义了这个查询的合作方提交的任一具有高于90的 值的计数器的提醒。从监视的观点来看，这不是非常有用，因为其被应用于被给定顾客提交 的任一计数器。为了使得这个查询更加具体，需要添加流过滤操作符，如在以下示例中：
[0085] public class JohnSmitliAlerlingRuIe : IRuIe public IObservable<EiTipty> Tnitialize(IPartitionData data) { var query ^ (from pf in data.PerflVietricSaniples where pf.Value > 90 where pf.Metricld =- 1CPlJf && pf.Sourceld == tiService #I/Machine #18" select new MordtorState { Name = fiCPL is too high for Machine #18f\ MomtorId = pf.SoitrQeld + nP + pf.Metridd, State = States.Error ：).SaveAlert(); return Empty,Create0bs6rvable(query); } >
[0086] 这是有意义的多的规则，其在某些真实世界场景中极其有用。这个方法的巨大优 点之一是所生成的提醒将用极端低的等待时间被注册在系统中。由这个查询定义的所有计 算将在存储器中被实时地完成。所以，仅有的延迟将是在服务之间递送请求，其最多可在数 秒的程度上来完成。
[0087] 在先前查询处的近看将揭示查询现在针对非常具体的源是极为专用于场景的。所 以，当合作方想要针对相同或另一源设置类似监控规则时，可能就定义完全相同的规则，但 具有被硬编码在查询中的另一值。这看上去不像管理监视规则的有效方式。除此之外，最近 的规则将在由合作方提交的所有流中的每个数据项上执行，其可能变成难题和缩放问题。 范围可被每个分区用于主控配置对象和查询状态所消耗的存储器的量来限制。
[0088] 为了解决同时定义和维护几乎相同的规则和缩放问题的难题一可能定义专用于 某个上下文分区的规则（由以下示例中的命名空间id和分区id定义）以及规则配置类型。例 如，合作方可针对配置对象定义以下类： public class OneCounterRuieConfig ? public double CounterTresliold { get; set; }
[0089] public string Metricid { get; set; | public string SourceId { get； set; } public string MonitorStateName { get; set; }
[0090] 查询可使用另一通用接口 IRule〈TConfig>来被重新编写以定义以下规则：
[0091] public class RuleWithConfiguration : IRxile<QneConiiterRuieConfig> ? public IO b s e r ν a b I e < ? λπ pty > lnitialize(! PartitionData dara. OneCountetRuieGonfig ru IeConfig) return data .PeriMetrieSamptes
[0092] AVhereipf => pf.Value > mleConfiE.CounterTreshold) AVhere(pf => pf.MetricIcl == r u I e C ο i ? fi R .Metricld &&. pi.Source Id = ruleConri a.Sourceld) .SaYeAlert(pf => new MonitorState { Name = r u I eC o n fi M ο n i to rS tate N am e, Metricld = p￡MetricIdr Soureeid ^ pf.Sourceld }): .ToEmptyO； } }
[0093] 系统300可能提供用于合作方的REST API以管理每规则类型和分区的配置对象。 由于配置对象针对特定分区被提交一针对这样的规则实例的数据的范围是被推送到给定 分区中的流数据项。
[0094] 系统300可为针对特定分区提交的每个配置对象主控规则的实例。在没有匹配的 配置被提供而是规则用配置被定义的情况下一也许不将这个规则的实例主控在服务中。
[0095] 不具有配置的常用规则的生命期从IRule中继承。这样的规则针对给定命名空间 (由此该名称）中的每个分区被自动地实例化并且它们不等待配置被提供。也存在IRule〈 TConfig〉的通用版本。这个类型的规则不被实例化，直到提供针对整个命名空间的配置的 单个实例。
[0096] 对于可以是分区专用的（应用专用的、顾客专用的、角色(Role)专用的等）监视规 则一规则可实现IRu I e〈TC〇nf i g>接口并将被配置对象实例化。
[0097] 最后查询是针对场所内一个机器应用的监视规则的示例。然而，在云中，应用逻辑 跨多个机器分布。这意味着，监视规则应当准备好跨多个机器来计算状态以检测给定情况。 并且，这用低的等待时间和低的花费来实现。
[0098] 这在具有被表示为时间查询的存储器内计算的帮助下可以是容易的。当对跨源计 数器的实时聚集被首先要求(对配置类的定义被跳过)时，最后查询可进一步针对场景来扩 展：
[0099] public class IJeteGtionAerossSourees : IRule<AggregatedCounterRuleConfIg> { public lObservableCmpty〉 Initialize! I ParlitionDaia data, AggregatedCounterRuleConfig ruleConfig) { return data .Pe r fM etr i c S am pies .Where(pf => pf. Metric Id == r u i eC onfi g. M e ιι? c I d && pf.Context = raleConfig.Tenantld) /BuiTer(TimeS0an.FromSeeonds(ruleConfiRX\)uinerRes0lutio nlnSeconds)) AVhereibuffer buffer.Count > 0) .Select(buffer new PefflMetricSample ? Value ~ huffei\AveraRe(pf p￡ Value), Mctricld_Ξ ruleConi^,Aum~e^ai.ed\4e<ricl d, Sourceld = nSvstcm 300" }) .Whcre(pf ~> pfWaluc > ruleConfig.CountcrTrcshold) .8Η\^Α1?Γ?(ρ?'=> new MonitorState Ndine = ruleConfig. MoniiorStateName1 MonitorId = pf,MetriGld5
[0100] Tenantld == ruleConfig.Tenantld, State = States.Error }) .ToEmptyO; } }
[0101] 这个查询几乎与先前的版本相同。它具有三个被加下划线的附加标准Rx操作符。 这个查询的语义如下：一对于给定时间段的所有传入经过滤的性能计数器进行缓冲并接着 产生在不同的源上聚集的计数器的流，其可被用于提醒。
[0102] 值得指出的是，正在进行的被突出显示的子查询可跨不同的监视规则来使用并可 被隐藏在C#子例程后：
[0103] public class DctcctionAcrossSources : IRulc<AggrcgatedCountcrRulcConfig> { public IDbservable<Empty> i n it i al ize( [PartitioiiData data, AggregatedCounlerRuleCuni'ig ruleConi'ig) ? return data .PcriMctricSainplcs ,Where(pf => pf.Metrkld == raleCGnfig.MetricId && pfSourceld = ruleConflg.Sourceld) ,SelectAveraRg( ruleConfiR. Afe^reEatedMetricId, TimeSpan.FroirtSecondsiruleConfie.CountcrResolution InSeconds)) ,Where(pf => pf.Value > ruleConiig^CounterTreshold) .SaveAlert(pf => new MonitorState {
[0104] Name = ruleConfig,MonitorStateName, Morutorld ^ pf. Mctncldr Tenantld = ruleConfig. TenantId, SoiirceId ^ pi'-Sourceld }) .ToEmptyOi } }
[0105]被加下划线的操作符SelectAverage是自定义的扩展，顾客可立即重用该自定义 的扩展。
[0106] 也就是说，以上仅仅是规则可如何在特定事件处理系统内部被实现的具体示例。 因此，本文中描述的更一般的原理提供用于处理由分布式应用提供的事件的有效系统。
[0107] 本发明可具体化为其它具体形式而不背离其精神或本质特征。所描述的实施例在 所有方面都应被认为仅是说明性而非限制性的。从而，本发明的范围由所附权利要求书而 非前述描述指示。落入权利要求书的等效方案的含义和范围内的所有改变应被权利要求书 的范围所涵盖。
【主权项】
1. 一种用于使事件处理系统处理输入事件的方法，包括： 接收输入事件的动作，所述输入事件具有随其标识的上下文分区，所述输入事件已经 经由事件分类阶段从分布式应用被路由，所述事件分类阶段被配置成将具有所述上下文分 区的事件引导到所述事件处理系统；以及 通过执行以下来将监视规则应用到所述事件的动作： 基于如被应用到所述输入事件的所述监视规则来生成事件的动作；以及 确定所述事件是否具有一个或多个特征的动作； 如果所述事件具有所述一个或多个特征，则使用所述输入事件来生成输出事件的动 作；以及 对所述输出事件执行以下动作中的至少一个的动作： 保存所述输出事件的动作； 将所述输出事件回送到输出上下文分区使得所述输出事件作为到对应于所述输出上 下文分区的事件处理系统的输入事件来处置的动作；以及 将所述输出事件传送到所述系统外部的动作。2. 如权利要求1所述的方法，其特征在于，所述事件分类阶段也是分布式的，使得由分 布式特定应用的第一部分生成的第一多个事件在所述多个事件分类系统的第一事件分类 系统处被接收，并且使得由所述特定分布式应用的第二部分生成的第二多个事件在所述多 个事件分类系统的第二事件分类系统处被接收。3. 如权利要求1所述的方法，其特征在于，所述事件处理阶段是分布式的。4. 如权利要求3所述的方法，其特征在于，所述至少一个事件处理阶段包括至少第一事 件处理系统和第二事件处理系统，其中所述第一事件处理系统处理落在一个或多个上下文 分区的第一集合内的事件，并且所述第二事件处理系统处理落在一个或多个上下文分区的 第二集合内的事件。5. 如权利要求4所述的方法，其特征在于，所述第一事件处理系统具有能被在所述第一 事件处理系统上执行的代码使用的第一处理器可寻址数据容器，并且所述第二事件处理系 统具有能被在所述第二事件处理系统上执行的代码使用的第二处理器可寻址数据容器。6. 如权利要求1所述的方法，其特征在于，事件的上下文分区使用至少一个顾客标识符 来被标识。7. 如权利要求1所述的方法，其特征在于，事件的上下文分区使用至少一个应用标识符 来被标识。8. 如权利要求1所述的方法，其特征在于，将监视规则应用到接收自所述事件分类阶段 的事件的动作包括： 访问输入事件的动作； 确定所述事件是否具有一个或多个特征的动作； 如果所述事件具有所述一个或多个特征，则使用所述输入事件来生成输出事件的动 作；以及 对所述输出事件采取动作的动作。9. 一种事件监视系统，包括： 事件分类阶段，所述事件分类阶段包括多个事件分类系统并接收由至少一个应用提供 的多个事件； 包括处理事件的至少一个事件处理系统的事件处理阶段，其中所述至少一个事件处理 系统中的每一个能够处理落在对应于相应事件处理系统的一个或多个上下文分区的特定 集合内的事件， 其中所述多个事件分类系统中的每一个被配置成响应于接收所述多个事件中的至少 一些中的每一个来执行以下： 标识所述事件落在哪个上下文分区内的动作； 标识对应于所述事件的经标识的上下文分区的事件处理系统的动作；以及 将所述事件转发到经标识的事件处理系统的动作； 其中所述事件处理系统中的至少一个中的每一个被配置成执行以下： 将监视规则应用到接收自所述事件分类阶段的事件的动作。10.如权利要求9所述的系统，其特征在于，所述至少一个应用中的特定应用是分布式 应用。
【文档编号】G06F11/30GK105849703SQ201480035463
【公开日】2016年8月10日
【申请日】2014年6月18日
【发明人】A·克利莫弗, V·弗里诺夫, A·扎科诺夫
【申请人】微软技术许可有限责任公司