CN107077394A

CN107077394A - 请求监视

Info

Publication number: CN107077394A
Application number: CN201580056869.0A
Authority: CN
Inventors: D·J·瑟格尔; M·J·罗威; M·W·考克斯
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2014-11-17
Filing date: 2015-10-20
Publication date: 2017-08-18
Anticipated expiration: 2035-10-20
Also published as: GB2532285A; CN107077394B; US20160140020A1; JP6594977B2; GB201709373D0; JP2017535867A; US10496520B2; GB2549416A; DE112015004557T5; WO2016079618A1; GB201420367D0; DE112015004557B4

Abstract

一种监视对代码集的请求的方法，该方法包括以下步骤：接收对代码集的请求；为请求创建踪迹，该踪迹定义请求通过代码集的路径；访问多个存储的踪迹模式，每个存储的踪迹模式定义请求通过代码集的可接受的路径；将创建的踪迹与存储的踪迹模式进行比较；以及如果创建的踪迹与存储的踪迹模式都不匹配则存储该创建的踪迹。

Description

请求监视

技术领域

本发明涉及用于监视对代码集的请求的方法和系统。

背景技术

在许多计算环境中，很大数量的指令可能在短时间内由计算机处理。例如，正在为大型企业(诸如银行)运营网站的服务器将每秒处理很大数量的请求和事务，常常达到每秒数千个。这种计算系统必须运行非常复杂的软件，以便维持可接受的安全性和责任(liability)水平。在这种复杂的计算环境中，错误检测和监视是至关重要的。在这种环境中许多不同的技术被使用，这些技术中的一种技术被称为踪迹(trace)。

在软件工程中，跟踪是专用类型的日志记录，以便记录关于程序的执行的信息。这种信息可以由程序员为了调试目的而使用，此外，依赖于踪迹日志中包含的信息的类型和细节，这种信息可以由有经验的系统管理员或技术支持人员以及软件监视工具使用以诊断软件的常见问题。更多信息请参见例如en.wikipedia.org/wiki/Tracing_(software)。

在大数据环境中，在向服务器进行许多请求的情况下，启用踪迹来捕获问题常常是不切实际的。踪迹可以创建数千兆字节的数据，因为这么多事务或请求在并发地运行。然而，3级支持(在三层技术支持模式中负责处理最困难或最前沿的问题的最高级支持)常常需要使用踪迹来弄清为什么发生问题。这种环境可以是并发地处理数千个请求的IBM MQMessagesight设备或者每秒处理上千个事务的IBM CICS事务服务器。(IBM和CICS是国际商业机器公司在许多辖区的注册商标)。

发明内容

根据本发明的第一方面，提供了一种监视对代码集的请求的方法，该方法包括以下步骤：接收对代码集的请求；为请求创建踪迹，该踪迹定义请求通过代码集的路径；访问多个存储的踪迹模式，每个存储的踪迹模式定义请求通过代码集的可接受路径；将创建的踪迹与存储的踪迹模式进行比较；以及如果创建的踪迹与存储的踪迹模式都不匹配，则存储该创建的踪迹。

根据本发明的第二方面，提供了一种用于监视对代码集的请求的系统，该系统包括处理器，该处理器被布置为：接收对代码集的请求；为请求创建踪迹，该踪迹定义请求通过代码集的路径；访问多个存储的踪迹模式，每个存储的踪迹模式定义请求通过代码集的可接受路径；将创建的踪迹与存储的踪迹模式进行比较；以及如果创建的踪迹与存储的踪迹模式都不匹配，则存储该创建的踪迹。

根据本发明的第三方面，提供了一种用于监视对代码集的请求的计算机可读存储介质上的计算机程序产品，该计算机程序产品包括用于如下操作的指令：接收对代码集的请求；为请求创建踪迹，该踪迹定义请求通过代码集的路径；访问多个存储的踪迹模式，每个存储的踪迹模式定义请求通过代码集的可接受路径；将创建的踪迹与存储的踪迹模式进行比较；以及如果创建的踪迹与存储的踪迹模式都不匹配，则存储该创建的踪迹。

由于本发明，可以提供一种方法，通过该方法有用的踪迹数据被捕获，但是与不加选择地使用踪迹相比，捕获的数据量大大降低。该想法是捕获示出请求通过代码集的路径的踪迹模式。这些模式被用于指示哪些路径对于系统是正常的，因此允许在执行期间识别异常路径。这些模式将优选地详细说明哪些代码模块和功能被调取(invoke)，可选地说明入口和出口参数的内容，但是没有进一步的细节。在一个实施例中，当为系统启用踪迹时，踪迹被捕获到存储器，并且不时地(诸如在请求完成或缓冲器被填满时)将踪迹与模式进行比较。对于每个请求/线程，如果请求与正常模式匹配，则踪迹被销毁并且不使用盘或存储器上的任何空间。如果模式不寻常，则踪迹被保留并且可以向支持提供。请求可以在环境中定义，例如，在CICS事务服务器中定义，请求将是事务的生命时间中的活动，而在Web服务器中，请求将是从HTTP请求进入直到已提供HTTP响应的活动。

在替代实施例中，正常模式可以被使用以忽略对正在执行正常路径的请求的踪迹调用。如果该请求然后将偏离该路径，则踪迹调用将导致踪迹数据被记录。这将减少踪迹的存储使用，并且使得分析踪迹输出的人员更容易识别未按预期执行的一个或两个请求。在上文描述的第一实施例中，踪迹首先被捕获到盘，然后被删除。在该替代实施例中，踪迹不被捕获到盘，而是如果它不寻常，才被写到盘。

另一个可选的扩展是使用与通过模块的初始流匹配的部分模式，其中与该部分模式匹配的任何请求将被跟踪并且与好模式进行比较，而与该踪迹不匹配的任何请求将被销毁。以这种方式，可以规定要跟踪的具体代码路径并且排除所有其它路径，因此不需要提供用于每条可能的代码路径的模式。这可以在每秒运行许多请求的环境中被使用，以取得具体的坏路径的踪迹。例如，客户可以提供错误以及示出在错误发生之前哪些模块被输入和退出的栈踪迹。3级代表可以产生这条路径的踪迹模式，将它提供给客户系统并且开启本段中描述的这种模式。然后，客户系统将不跟踪每个请求/事务，而是仅跟踪生成错误的请求。因此，即使在具有每秒上千个请求的系统中，也可以捕获对于通过代码的单个具体的坏路径的踪迹。如果在这种系统上启用正常的踪迹，则踪迹日志将快速填满，并且将难以在不记录若干千兆字节或更多的踪迹并且对其进行后处理的情况下查出坏请求的踪迹。

另一个可选的扩展是能够监视系统，并且指示遇到的“坏”模式的数量或者对发现的每种模式的数量计数，以向系统的用户提供一些有用的度量。如果出现了很多坏模式，则这可能指示系统中的一些问题。这样的坏模式可以由安全攻击、其它被使用的系统停机或不可靠而生成。优点是作为启用踪迹的替代，可以向系统管理员提供部分模式，以用于使得踪迹分析能够增加负荷(load up)。他们加载部分模式，并且他们的系统仅在指定的模块或功能运行时才捕获踪迹。可替代地，向用户提供好模式的集合，然后当启用踪迹时，仅捕获和保存看起来坏的请求的踪迹。

附图说明

现在将仅通过示例的方式参考以下附图来描述本发明的优选实施例，在附图中：

图1是计算系统的示意图，

图2是代码集的示意图，

图3是服务器和数据库的示意图，

图4是监视对代码集的请求的方法的流程图，以及

图5是使用部分踪迹模式监视请求的方法的流程图。

具体实施方式

图1示出了使用台式计算机系统12监视复杂代码集的性能的网络管理员10。计算机系统12包括显示设备14、处理器16和用户输入设备(常规的键盘)18。处理器16被连接到显示设备14和用户输入设备18。处理器16运行操作系统，用户10可以经由操作系统的图形用户界面与该操作系统交互，其中该图形用户界面由显示设备14显示。示出了CD-ROM 20，CD-ROM 20可以被用于存储由处理器16执行的计算机程序产品的副本。

还示出了附加的用户接口设备22，附加的用户接口设备22是常规的鼠标22。用户10利用键盘18和鼠标22与由处理器16运行的操作系统和应用交互。被监视的代码集还可以由计算系统12执行，或者更有可能由远离计算系统12放置的一个或多个连接的服务器执行。代码集可以是诸如由金融机构(诸如银行)使用的企业计算机系统，以提供允许银行的客户访问他们的账户并且在线执行交易的网站。

代码集每秒处理数千个请求，并且通过对代码集接收到的请求中的一些但不是全部使用踪迹功能来提供监视。代码集被配置为使得仅一定量的踪迹数据被捕获，以便向网络管理员10提供足够的反馈，而不需要非常大的存储开销来存储如果对代码集的每个单个请求都启用踪迹的话将生成的所有踪迹数据。跟踪是当请求在接收之后被处理时，记录关于代码集执行的信息的专用类型的日志记录。

为了减少被保留的踪迹数据的量，有必要使用踪迹模式来区分“好”踪迹和“坏”踪迹。好踪迹可以被认为是请求通过代码集的正常路径，而坏踪迹是请求通过代码集的非预期路径，坏踪迹将倾向于更加指示处理中的错误。为了做出这样的区分，首先有必要生成可接受的踪迹模式。图2示出了由代码集26接收到的请求24的概念，代码集26生成响应28，同时也为具体的请求24生成踪迹30。

为了生成模式，首先捕获用于请求24的踪迹30。然后，使用工具32将该踪迹30转换成模式34。然后，这个模式作为正常的请求模式被加载到系统中。对于被判断为好请求模式的每个请求模式，重复这个过程。模式34是模块或类中的方法调用的序列。例如，在小服务程序(servlet)环境中，踪迹模式可以如下所示(其中>符号指的是进入命名模块，而<符号指的是从命名模块退出)：

>MyServlet.init()

<MyServlet.init()

>MyServlet.get()

>MySupportCode.doLogic()

<MySupportCode.doLogic()

>MySupportCode.doMoreLogic()

<MySupportCode.doMoreLogic()

<MyServlet.get()

模式34可以更复杂并且可以包括被发送进去的参数或者返回的参数，可选地包括参数的具体类型。这样的一个用途是如果存在采用Exception超类的异常处理方法，则该模式可以指定应当利用诸如UserErrorException之类的Exception的具体子类来进入该方法。因此，仅在这个预期的异常不发生的情况下的错误将被分析和跟踪。在代码集26的测试操作期间生成的、被指定为正常踪迹的踪迹30被用于生成容许模式34，容许模式34然后被存储，以准备好在代码集26处于正常操作时使用。

当正常操作时，系统将启用踪迹以写入磁盘。系统将需要识别请求并且按请求划分踪迹。分离可以或者在请求进行踪迹调用时进行或者由系统在处理踪迹输出的第二阶段中进行。该第二阶段可以由按请求将踪迹拆分成分开的文件的系统任务实现，例如，在一些应用服务器中，踪迹条目具有线程ID，因此踪迹输出可以通过线程ID被拆分成分开的文件。类似地，对于其它类型的事务服务器，每个事务具有任务号，并且该标识符可以被用于拆分踪迹输出。

使用存储的模式提供了通过其捕获有用的踪迹数据的方法，但是与不加选择地使用踪迹相比，捕获的数据量大大降低。存储的踪迹模式被用于指示对系统来说哪些路径是正常的，因此允许在执行期间识别异常路径。如上文所描述的，这样的模式将优选地详细说明哪些代码模块和功能被调取，可选地说明入口和出口参数的内容，但是没有进一步的细节。图3示出了能够访问数据库38的服务器36，数据库38存储定义请求通过代码集的可接受路径的踪迹模式。

在一个实施例中，当为由服务器36运行的系统启用踪迹时，踪迹被捕获到存储器并且不时地(诸如当请求完成或缓冲器被填满时)将踪迹与数据库38中的存储的模式进行比较。如果请求与正常模式匹配，则踪迹被删除并且因此不使用盘或存储器上的任何空间。如果模式不寻常并且不与任何存储的踪迹模式匹配，则原始踪迹被保留并且可以向支持提供。以这种方式，系统将仅存储不匹配被认为是“好”的踪迹模式的踪迹。

图4总结了监视对代码集的请求的方法。该方法包括以下步骤：首先是步骤S4.1，步骤S4.1包括接收对代码集的请求；第二是步骤S4.2，步骤S4.2包括为请求创建踪迹，该踪迹定义请求通过代码集的路径；第三是步骤S4.3，步骤S4.3包括访问多个存储的踪迹模式，每个存储的踪迹模式定义请求通过代码集的可接受路径；第四是步骤S4.4，步骤S4.4包括将创建的踪迹与存储的踪迹模式进行比较；最后是步骤S4.5，步骤S4.5包括如果创建的踪迹与存储的踪迹模式都不匹配，则存储该创建的踪迹。

在替代实施例中，存储的模式可以被用于忽略对正在执行正常路径的请求的踪迹调用。如果该请求然后会偏离该路径，则踪迹调用将导致踪迹数据被记录。这减少了踪迹数据的存储要求，并且使得分析踪迹输出的人员更容易识别未按预期执行的一个或两个请求。在上文描述的第一实施例中，踪迹数据首先被捕获到盘，然后被删除。在该替代实施例中，踪迹数据不被捕获到盘，而是如果它不寻常才被写到磁盘。

在当请求与正常路径匹配时忽略踪迹调用的该替代实施例中，在理想情况下，模式将被保持在存储器中。出于性能原因，这可以通过将这些模式合并成图来实现并且图中的请求位置被跟踪。当请求进行踪迹调用时，如果该调用与用于请求的下一个有效节点匹配，则图中该请求的位置被更新并且不跟踪任何内容。如果该调用与下一个有效节点不匹配，则该模式中该请求的最后一个好位置将连同当前踪迹调用中的值一起被写入到踪迹输出，并且图中该请求的位置将被更新为“无匹配”位置，这将导致对于该请求的所有后续踪迹调用都被写入。

可以使用部分模式匹配作为决定是否保持踪迹数据的预判(precursor)，在部分模式匹配中仅仅跟踪与部分模式匹配的那些请求，使用第二阶段后台任务监视踪迹或者使用存储器中的图，类似于上文描述的先前实施例。当请求完成时，后台任务将使用与上面的工具相同的逻辑将踪迹转换成模式。然后将这个模式与部分模式进行比较，这可以指示该踪迹要被分析。如果是这样，则将模式与已知的好模式进行比较。如果找到匹配，则从盘中删除踪迹。如果没有找到匹配，则踪迹被保留在盘上，并且分析器可以写日志条目，以指示检测到坏模式。存储器中的图将跟踪当前请求，并且或者它们将与模式匹配并且写入踪迹条目，或者它们在图中的位置将被更新为“无踪迹”节点。

例如，部分踪迹模式可以是：

>MyServlet.get()

因此不分析对其它小服务程序的调用。但是分析使用GET的对MyServlet的调用。坏模式将是：

>MyServlet.init()

>MyServlet.get()

>MySupportCode.doLogic()

>MySupportCode.handleError()

>ServletContainer.handleRuntimeException()

<ServletContainer.handleRuntimeException()

在这里，代码在get中失败，然后抛出小服务程序容器必须处理的未处理的异常。图5示出了这个过程中的基本原理。在步骤S5.1，进行检查，以查看踪迹是否与部分模式匹配。如果踪迹不匹配，则该踪迹被丢弃。如果踪迹匹配，则在步骤S5.2进行检查，以查看踪迹是否与存储的模式匹配。如果踪迹匹配，则该踪迹被丢弃，并且仅当不存在与存储的(完全)模式的匹配时才在步骤S5.3存储踪迹。本质上这个过程通过集中于代码集的(由部分模式定义的)一个特定区域来操作，并且仅存储与已被定义为“好”的踪迹模式不匹配的那些踪迹。

关于如何将来自模式的踪迹点与运行的踪迹匹配，下面是来自IBM WebSphere应用服务器的两个示例踪迹语句(WebSphere是国际商业机器公司在许多辖区的注册商标)：

[06/01/14 15:17:22:101GMT]00000084util>com.ibm.sr.sdo.helper.impl.BSRSDOHelperImpl addPropertyENTRYcom.ibm.serviceregistry.governance.sdo.impl.SubscriptionImpl@1f28465a(classificationURIs:[],bsrURI:d413bbd4-62e8-48db.ba6f.f1d294f16fed,name:Subscription to"Account creation service？(1.0)？",namespace:,version:,description:,owner:admin,lastModified:1369235510163,creationTimestamp:1369235510163,lastModifiedBy:admin)(subscribedTransitions:null,subscribedOperations:[update],targetClassifications:null,emailAddress:null,locale:en,targetBsrURI:9afa319a-bf21-4102.a24d.1fbfb71f4d67,targetName:null,targetNamespace:null,targetVersion:null)_expiryStartTime 1369235510139

[06/01/14 15:17:22:101GMT]00000084util<com.ibm.sr.sdo.helper.impl.BSRSDOHelperImpl addProperty RETURN

忽略各种参数，入口语句是：

[06/01/14 15:17:22:101GMT]00000084util>com.ibm.sr.sdo.helper.impl.BSRSDOHelperImpl addProperty ENTRY

从匹配的视角，时间戳可以被忽略，仅相对于其它踪迹点的次序是重要的。线程ID0000084同样可以被忽略，但是可以在从单个任务收集踪迹时使用，因此同一线程ID上的所有踪迹点是针对单个任务的。成分“util”可以被忽略。被调取的类名是“com.ibm.sr.sdo.helper.impl.BSRSDOHelperImpl”，这形成踪迹模式的一部分并且将需要与(不论是否以图的形式的)模式中的类名匹配。方法名是“addProperty”，这形成模式的一部分并且将需要匹配。最后，类型(入口或出口)被指示为“ENTRY”(入口)，这形成踪迹模式的一部分并且将需要匹配。

以这种方式，一旦代码集接收到请求，就可以基于进入的模块和功能从原始踪迹数据中剥离多余的信息并且将其转换成模式。通过利用踪迹模式过滤踪迹数据，仅仅不寻常和非预期的踪迹数据将被捕获，这将减少处理踪迹数据所需的存储量，但还将使网络管理员的任务更容易，因为将存在更少的数据。存储的踪迹数据在过滤之后将仅包括与所存储的踪迹模式不匹配的那些踪迹，并且按照定义将是非预期的踪迹，这些非预期的踪迹更可能与代码集内的错误或不寻常操作相关，因此可以在关于代码集需要提供支持的情况下被研究。

踪迹过滤还可以被用于获取系统度量。系统可以被监视，以指示遇到的“坏”模式(即，与存储的踪迹模式不匹配的模式)的数量，或者对发现的每种模式的数量计数，以向系统的用户提供一些有用的度量。如果很多坏模式开始出现，这可能指示系统中的一些问题。这样的坏模式可能由安全攻击、其它被使用的系统停机或不可靠而生成。一个优点是作为启用踪迹的替代，可以向系统管理员提供部分模式，以用于使得踪迹分析能够增加负荷。管理员加载部分模式，并且他们的系统将仅在指定的模块或功能运行时才捕获踪迹。可替代地，向用户提供好模式的集合，然后当启用踪迹时，仅捕获和保存看起来坏的请求的踪迹。

本发明可以是系统、方法和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于使处理器实现本发明的各个方面的计算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本发明操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本发明的各个方面。

这里参照根据本发明实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本发明的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本发明的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

Claims

1.一种监视对代码集的请求的方法，所述方法包括以下步骤：

接收对所述代码集的请求，

为所述请求创建踪迹，所述踪迹定义所述请求通过所述代码集的路径，

访问多个存储的踪迹模式，每个存储的踪迹模式定义请求通过所述代码集的可接受的路径，

将创建的踪迹与所述存储的踪迹模式进行比较，以及

如果所述创建的踪迹与所述存储的踪迹模式都不匹配，则存储所述创建的踪迹。

2.如权利要求1所述的方法，还包括：为对所述代码集的每个请求创建踪迹，存储所有创建的踪迹，访问所述多个存储的踪迹模式，将创建的踪迹与所述存储的踪迹模式进行比较以及对于每个创建的踪迹如果它与所述存储的踪迹模式中的一个存储的踪迹模式匹配则删除它。

3.如权利要求1或2所述的方法，还包括：访问存储的部分踪迹模式，以及仅当创建的踪迹与所述存储的部分踪迹模式匹配并且与所述存储的踪迹模式都不匹配时才存储所述创建的踪迹。

4.如权利要求1、2或3所述的方法，还包括维护关于与所述存储的踪迹模式都不匹配的创建的踪迹的数量的数值数据，以及提供从所述数值数据导出的一个或多个输出。

5.如前述权利要求中任一项所述的方法，还包括维护关于与所述存储的踪迹模式中的一个存储的踪迹模式匹配的创建的踪迹的数量的数值数据，以及提供从所述数值数据导出的一个或多个输出。

6.一种用于监视对代码集的请求的系统，所述系统包括处理器，所述处理器被布置为：

接收对所述代码集的请求，

将创建的踪迹与所述存储的踪迹模式进行比较，以及

7.如权利要求6所述的系统，其中所述处理器还被布置为：为对所述代码集的每个请求创建踪迹，存储所有创建的踪迹，访问所述多个存储的踪迹模式，将所述创建的踪迹与所述存储的踪迹模式进行比较以及对于每个创建的踪迹如果它与所述存储的踪迹模式中的一个存储的踪迹模式匹配则删除它。

8.如权利要求6或7所述的系统，其中所述处理器还被布置为访问存储的部分踪迹模式以及仅当所述创建的踪迹与所述存储的部分踪迹模式匹配并且与所述存储的踪迹模式都不匹配时才存储所述创建的踪迹。

9.如权利要求6、7或8所述的系统，其中所述处理器还被布置为维护关于与所述存储的踪迹模式都不匹配的创建的踪迹的数量的数值数据，以及提供从所述数值数据导出的一个或多个输出。

10.如权利要求6至9中任一项所述的系统，其中所述处理器还被布置为维护关于与所述存储的踪迹模式中的一个存储的踪迹模式匹配的创建的踪迹的数量的数值数据，以及提供从所述数值数据导出的一个或多个输出。

11.一种用于监视对代码集的请求的计算机可读存储介质上的计算机程序产品，所述计算机程序产品包括用于以下操作的指令：

接收对所述代码集的请求，

将创建的踪迹与所述存储的踪迹模式进行比较，以及

12.如权利要求11所述的计算机程序产品，还包括用于以下操作的指令：为对所述代码集的每个请求创建踪迹，存储所有创建的踪迹，访问所述多个存储的踪迹模式，将创建的踪迹与所述存储的踪迹模式进行比较以及对于每个创建的踪迹如果它与所述存储的踪迹模式中的一个存储的踪迹模式匹配则删除它。

13.如权利要求11或12所述的计算机程序产品，还包括用于以下操作的指令：访问存储的部分踪迹模式以及仅当所述创建的踪迹与所述存储的部分踪迹模式匹配并且与所述存储的踪迹模式都不匹配时才存储所述创建的踪迹。

14.如权利要求11、12或13所述的计算机程序产品，还包括用于以下操作的指令：维护关于与所述存储的踪迹模式都不匹配的创建的踪迹的数量的数值数据，以及提供从所述数值数据导出的一个或多个输出。

15.如权利要求11至14中任一项所述的计算机程序产品，还包括用于以下操作的指令：维护关于与所述存储的踪迹模式中的一个存储的踪迹模式匹配的创建的踪迹的数量的数值数据，以及提供从所述数值数据导出的一个或多个输出。