CN105408873B

CN105408873B - 用于诊断数据的基于活动的采样的系统和方法

Info

Publication number: CN105408873B
Application number: CN201480038423.0A
Authority: CN
Inventors: D·J·泰勒; V·P·莫里森; C·拉杜; B·P·埃伦特
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2013-05-02
Filing date: 2014-05-02
Publication date: 2018-02-13
Anticipated expiration: 2034-05-02
Also published as: US20140331092A1; CN105408873A; US9092332B2; WO2014179635A1; EP2992431A1; EP2992431B1

Abstract

基于活动的采样提供了有用且相关地聚焦的诊断数据，所述诊断数据被连接以改善开发者的理解。应用调用日志事件规程，使得记录器检查记录条件并在记录条件被满足时制作日志条目。该记录器具有启用日志的活动的集合，以及具有相应采样频率条件的一个或多个开始事件。一个记录条件是当前活动id是启用日志的。另一个条件声明如果当前活动id不是启用日志的但是日志事件规程标识与采样频率条件一致的开始事件，则该活动被启用日志且制作日志条目。处于启用日志的活动的集合中的父活动对子活动的创建在该日志中被注释，且该子活动被自动启用日志。日志消费器可驻留于该应用内或外。用于Windows服务的事件跟踪可被增强以支持基于活动的采样。

Description

用于诊断数据的基于活动的采样的系统和方法

背景

程序的源代码可在理解程序的行为的方面非常有用。但是商业计算系统中的大多数(即便不是全部)有用计算太复杂而不能在精神上重建。具体而言，面对创建、调试或者提升商业计算系统的甚至极有经验且有能力的软件开发者不仅仅依赖于对源代码的视觉检查或依赖于在思想上或在纸面上模拟软件执行的尝试。相反，开发者执行软件以便观察在执行期间软件做什么或无法做什么。

为了改善其在执行期间对软件的动作的理解，开发者使用诸如调试器、剖析器(profiler)、嵌入的打印语句、以及诊断日志之类的工具，这些工具提供了软件执行时的附加数据。对程序的检查随后可通过检查工具所提供的数据来辅助。然而，这些软件开发工具中的每个工具还提出了技术挑战，例如，如何获得工具数据而不更改被检查程序的无工具行为，以及如何避免将工具数据埋葬在无关数据的洪流中，以及如何按照改善开发者对被检查的程序的理解的方式将不同工具数据段彼此连接。

概述

本文描述的一些实施例涉及如何获得关于软件程序的有用诊断数据而不将该有用数据埋葬在不相关数据的洪流中的技术问题。一些实施例还涉及如何将不同诊断数据段彼此连接来帮助改善开发者对正被诊断的程序的理解(特别是该程序跨多个执行线程时)的技术问题。

从架构角度，一些实施例提供了使用与一个或多个处理器操作地通信的存储器提供诊断数据的基于活动的采样。驻留于存储器中的事件定义集合定义了开发者相信可阐明应用程序的行为的事件。该应用还驻留在所述存储器中并具有被配置成调用至少一个日志事件规程的应用代码。当前活动id指定该应用的活动是否当前被开发者指明或代表开发者指明。当某个活动当前被指明时，当前活动id还指定哪个活动当前被指明。

在一些实施例中，驻留于所述存储器中的记录器具有记录器代码，所述记录器代码被配置成与所述处理器和存储器交互以检查指定记录条件的集合并在至少一个指定记录条件被满足时响应于日志事件规程的调用而向日志发送日志条目。该记录器包括启用日志的活动的集合，且还包括具有相应采样频率条件的一个或多个开始事件的集合。每个开始事件是在事件定义集合中定义的事件(尽管不必然在那里被定义为开始事件)。

在一些实施例中，指定记录条件包括指定当前活动id存在于该启用日志的活动的集合中的第一条件。在一些实施例中，指定记录条件还包括指定以下的第二条件：当前活动id不在该启用日志的活动的集合中，该日志事件规程标识 304开始事件，且该日志事件规程的调用与该开始事件的采样频率条件相一致。

在一些实施例中，开始事件采样频率指定该日志事件规程的调用是对于具有每N次日志事件规程调用一个日志条目的采样频率的开始事件的第N次记录尝试。在这些和/或其它实施例中，开始事件采样频率指定在指定时间段内存在少于M个的开始事件。

一些实施例包括被配置成设置当前活动id的至少一个设置活动id规程调用。该设置活动id规程调用驻留于以下的至少一者中：该应用代码，包括用于支持该应用代码的运行时的框架。具体而言，该应用可以是C++应用，且该框架可包括熟悉的标准C++库。

在一些实施例中，该应用是多线程应用。在一些实施例中，该实施例包括标识该应用的执行期间该应用的当前执行线程的当前线程id。在一些实施例中，至少一个日志条目包含当前线程id(“当前”意思是日志条目创建的当前)。

一些实施例包括具有相应活动id的线程id的集合。记录器代码被配置成通过在线程id集合中查找当前线程id来寻找相应活动id并使用该活动id作为当前活动id来检索当前活动id。

一些实施例包括性能监视器或其它日志消费器，其可在该应用内或应用外。日志消费器的代码被配置成向记录器发送采样配置消息来将至少一个事件指定为开始事件并指定针对该开始事件的采样频率条件。在这些和/或其他实施例中，采样配置可按其它方式指定，诸如通过配置文件、通过用户界面控制的参数、或适于传达采样配置的其它熟悉的进程间通信机制。

一些实施例包括子活动规程调用，其被配置成通知记录器当前活动正创建子活动。在一些实施例中，记录器代码被配置成响应于子活动规程调用而向启用日志的活动的集合添加子活动。在一些实施例中，日志条目建档由一活动(其为在子活动规程调用时的当前活动)创建的子活动。

从规程角度，一些实施例执行了一种用于使用记录器的诊断数据的基于活动的采样的技术过程。一些实施例用代表启用日志的活动的集合的数据以及用代表具有相应采样频率条件的开始事件的集合的数据来配置记录器。在一些实施例中，所述记录器中的数据将线程id与活动id相关联，所述线程id标识计算系统的线程，且所述活动id标识至少部分由所标识的相关联线程执行的活动。一些实施例在记录器中接收由调用线程对日志事件规程调用的指示，所述指示指定一事件。一些实施例确定在启用日志的活动的集合中表示的任何活动是否当前是调用线程的活动。如果启用日志的活动的集合中表示的任何活动当前是调用线程的活动，则该事件被记录在诊断数据日志中。如果启用日志的活动的集合中表示的活动当前均不是调用线程的活动但是该事件为开始事件且日志事件规程的调用满足该开始事件的采样频率条件，则该事件被记录在诊断数据日志中且调用线程的活动被添加到启用日志的活动的集合。

一些实施例提供定义事件的事件定义的集合。具体而言，事件定义被提供至以下的至少一者：应用、记录器、日志消费器。在一些实施例中，事件定义指定针对至少一个事件的细节水平。

一些实施例停止对特定活动的记录，即使日志空间或其它资源可用且该应用程序正在执行活动。一些实施例响应于以下的至少一者来停止记录：看到停止记录事件、在先前看到开始事件已触发了对所述活动的记录之后再次在启用日志的活动上看到开始事件。

一些实施例响应于设置活动id规程调用来设置当前活动id。一些实施例在以下至少一者中如此做：在所述计算系统中的应用、包括支持所述应用的运行时的框架。当前活动id指定该应用的任何活动是否当前被指明为要被记录，且当某个活动当前被指明时，当前活动id还指定哪个活动当前被指明。

一些实施例在子活动是在启用日志的活动的集合中的父活动的子活动时，自动向启用日志的活动的集合添加该子活动。子活动响应于接收以下指示而被添加：在父活动在启用日志的活动的集合中的同时，该子活动是该父活动的子。一些实施例记录处于启用日志的活动的集合中的父活动对任何子活动的创建。

通过进一步图示，考虑其中实施例将在此处被表示为线程1的线程id与此处被表示为活动1的活动id相关联且随后在记录器中接收线程1的日志事件规程调用的指示的情形。假定指示指定在此处被表示为事件1的事件。一些实施例避免记录事件1，因为活动1不在启用日志的活动的集合中。现在假定指示指定在此处被表示为事件2的事件。一些实施例记录事件2，即使活动1不在启用日志的活动的集合中，因为事件2是开始事件，且还将活动1添加到启用日志的活动的集合中，因为事件2是开始事件。现在假定指示指定在此处被表示为事件3的事件。一些实施例避免了记录事件3，即使事件3是开始事件，因为事件3的采样频率是每N个日志事件规程调用一个日志条目，且该日志事件规程的调用不是事件3的第N次记录尝试。

所给出的示例只是说明性的。本发明内容并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。相反地，提供本发明内容是为了以简化的形式介绍将在以下具体实施方式中进一步描述的一些技术概念。本发明由权利要求书限定，在本发明内容与权利要求书有冲突的情况下，应该以权利要求书为准。

附图简述

将参考附图给出更具体的描述。这些附图只示出了选定的方面，且因此不完全确定覆盖或范围。

图1是示出具有至少一个处理器和至少一个存储器的计算机系统并且还示出经配置的存储介质(而不仅仅是信号)实施例的框图，该至少一个处理器和至少一个存储器在用于诊断数据的基于活动的采样的软件和操作环境中可能存在于多个网络节点上的其他项的控制下彼此交互；

图2是示出一示例体系结构中的诊断数据的基于活动的采样的各方面的框图；

图3是示出一些过程的步骤和经配置的存储介质实施例的流程图；

图4是示出另一示例体系结构中的诊断数据的基于活动的采样的各方面的数据流程图；

图5是示出web服务请求中的活动的体系结构图；

图6是示出线程活动、被记录的事件、以及逻辑活动之间的连接的图示；

图7是示出用户定义的事件、线程、以及执行流的活动、以及任务并行库(TPL)库(微软公司的商标)中的活动创建事件之间的一些连接的图示；

图8是示出作为用于通过排除不相关数据获得关于软件活动的有用诊断数据的机制的基于活动的采样的积极影响的图示；以及

图9是示出诊断数据的基于活动的采样的各方面的另一体系结构图。

详细描述

概览

诊断数据的采样可被用来减少日志记录信息的磁盘、处理器和存储器开销。在相关时，诊断信息可提供可操作信息(actionable information)，但是诸如随机或周期性采样之类的熟悉的采样技术导致重要的上下文数据被丢弃。

程序分析的一些熟悉方法向用户的应用和框架添加探测工具 (instrumentation)，将应用的组件的进入点勾住(hooking)，诸如处理来自 web服务的传入和传出HTTP传输的代码(本领域的技术人员将意识到，HTTP 代表超文本传输协议)。当在应用中检测到问题点和/或热路径时，一些方法向应用中的特定位置添加更多探测工具。随后其可使用试探法(heuristics)来将数据集相关起来，或在探测工具点被命中处使用线程的标识符。然而，这些方法通常是不精确的，并且依赖于多轮相同类型活动来收集诊断信息。它们还无法与跳跃线程的代码一起工作，诸如随.NET^TM 4.5框架(微软公司的商标)引入的异步/等待模式。

然而，通过基于活动的采样，定义了代表机器上的执行单元的活动。用父 -子关系将活动彼此相关。一旦采样在父活动上开始，采样将在全部子活动上继续。诊断数据随后可被配置成仅针对被采样活动记录。诊断数据可针对执行流来记录，从而允许高保真度和上下文信息的收集，同时通过仅在指定情况下开始活动采样来减少总开销。基于活动的采样可减少日志记录的开销，同时仍旧提供有用且相关地聚焦的诊断数据。在一些环境中，通过对数据流的后分析来获得聚焦的诊断数据是可能的，但是采样允许在运行时抛出不想要的数据，由此减少了日志记录的开销。

此处描述的某些实施例可以在较宽泛的上下文中查看。例如，诸如活动、事件、日志记录、采样频率以及线程等概念可能与特定实施例有关。然而，并不能从宽泛上下文的可用性中得出此处对抽象概念寻求专有权；它们并不是专有的。相反，本发明聚焦于适当具体的实施例，其技术效果完全或部分地解决特定技术问题。涉及活动、事件、日志记录、采样频率和/或线程的其他介质、系统和方法在本范围之外。因此，在对本发明的正确理解下，也避免了模糊性、抽象性、缺少技术性和附带的证据问题。

本文描述的实施例的技术特征对于本领域技术人员而言将显而易见，并且对于各种关注的读者而言也以各种方式显而易见。第一，一些实施例解决了诸如选择性记录有用诊断数据以及将诸如事件和活动之类的不同诊断数据段互相关的技术问题。第二，一些实施例包括诸如计算硬件等技术组件，这些技术组件以除了通用计算机中的典型交互之外的方式与软件交互。例如，除了诸如存储器分配、存储器读写、指令执行和I/O排序等普通交互之外，本文描述的一些实施例还将开始事件与采样频率、日志活动创建相关联并定义可记录事件。第三，一些实施例提供的技术效果包括应用中的日志事件规程调用以及基于活动的诊断日志。第四，一些实施例包括诸如可记录事件定义、日志事件规程、设置-活动-id规程以及启用日志的活动集合之类的技术适配。第五，一些实施例通过基于诸如采样频率条件和活动父-子关系之类的技术考虑而修改基于活动的采样的诊断记录的技术功能。第六，一些实施例的技术优点包括从日志中排除不相关诊断数据、自动记录子活动(即便在子和父活动在不同线程上执行时)、以及通过更可用诊断记录简化开发。

现在将参考诸如附图中所示出的那些示例性实施例，并使用特定语言来对其进行描述。但是，相关技术领域的且拥有本公开内容的技术人员将想到的对此处所示出的特征的更改和进一步的修改以及对此处的特定实施例所示的抽象原理的其他技术应用，都应该被视为在权利要求的范围内。

在本公开中阐明了各术语的含义，因此应该在仔细关注这些阐明的情况下阅读权利要求书。给出了具体示例，但是相关领域的技术人员将理解其他示例也可落在所使用的术语的含义范围内以及落在一个或多个权利要求的范围内。各术语不一定需要具有与它们在一般使用中(尤其在非技术使用中)或在特定行业使用中、或在特定字典或一组字典的使用中所具有的意义相同的意义。附图标记可以与各种措词一起使用，以帮助示出术语的广度。从给定文本片段中省略附图标记不一定意味着没有通过文本讨论附图的内容。发明人声明并行使他们对他们自己的词典的权利。这里可在具体实施方式中和/或在申请文件的别处显式地或隐式地定义术语。

如此处所使用的，计算机系统摂可包括例如一个或多个服务器、主板、处理节点、个人计算机(便携式或非便携式)、个人数字助理、蜂窝或移动电话、至少具有处理器和存储器的其他移动设备、和/或提供至少部分地由指令来控制的一个或多个处理器的其他设备。指令可以采用存储器中的固件或其他软件和 /或专用电路的形式。具体而言，虽然可发生许多实施例在工作站或膝上型计算机上运行，但是其他实施例也可以在其他计算设备上运行，并且任何一个或多个这样的设备都可以是给定实施例的一部分。

“多线程化”计算机系统是支持多个执行线程的计算机系统。术语“线程”应被理解为包括能够或经历调度(以及可能同步)的任何代码，并且也可以另一名称来为人所知，如“任务”、“进程”或“协同例程”等。线程可以并行地、按顺序、或以并行执行(例如，多处理)和顺序执行(例如，时间分片)的组合来运行。在各种配置中都已设计了多线程化环境。执行线程可以并行地运行，或者线程可以被组织为并行执行，但是实际上轮流按顺序执行。例如，多线程化可以通过在多处理环境中在不同核上运行不同线程、通过对单个处理器核上的不同线程进行时间分片、或者通过时间分片和多处理器线程化的某种组合来实现。线程上下文切换可以例如由内核的线程调度器、由用户空间信号、或由用户空间和内核操作的组合来发起。线程可以轮流对共享数据进行操作，或者例如每一线程都可以对其自己的数据进行操作。

“逻辑处理器”或“处理器”是单个独立硬件线程处理单元，如同时多线程实现中的核。作为另一示例，每核运行两个线程的超线程四核芯片具有8个逻辑处理器。逻辑处理器包括硬件。术语“逻辑”被用来防止给定芯片具有至多一个处理器的错误结论；“逻辑处理器”和“处理器”在此可互换地使用。处理器可以是通用的，或者它们可被定制用于特定用途，例如图形处理、信号处理、浮点算术处理、加密、I/O处理等等。

“多处理器”计算机系统是具有多个逻辑处理器的计算机系统。多处理器环境存在于各种配置中。在一给定配置中，所有处理器可在功能上相同，而在另一配置中，由于具有不同的硬件能力、不同的软件分配或两者，某些处理器可与其他处理器不同。取决于配置，处理器可在单个总线上紧密地彼此耦合，或它们可松散地耦合。在某些配置中，处理器共享一中央存储器，在某些配置中，它们各自具有自己的本地存储器，在某些配置中，存在共享和本地存储器两者。

“内核”包括操作系统、系统管理程序、虚拟机、BIOS代码、以及类似的硬件接口软件。

“代码”指的是处理器指令、数据(包括常量、变量、以及数据结构)、或指令和数据两者。

“程序”在本文中被广泛地使用以包括应用、内核、驱动程序、中断处理程序、库、以及程序员(也被成为开发者)编写的其他代码。

如此处所使用的“包括”允许附加元素(即，包括意味着包含)，除非另外指明。“由...构成”意味着基本上由...构成或完全由...构成。当X中的非Y部分(如果有的话)可以被自由更改、移除和/或添加而不在考虑所述权利要求时更改所要求保护的实施例的功能时，X基本上由Y构成。

“进程”在此有时被用作计算科学领域的术语，并且在该技术意义上涵盖资源使用者，即例如协同例程、线程、任务、中断处理程序、应用进程、内科进程、过程和对象方法。“进程”在此还可被用作本领域的专利法术语，例如，在描述与系统权利要求或制品(经配置的存储介质权利要求)相对的过程权利要求时。类似地，“方法”在此有时被用作计算科学领域内的技术术语(一种“例程”)并且还被用作本领域的专利法术语(“过程”)。技术人员将理解在特定实例中旨在是什么含义，并且还将理解给定所要求保护的过程或方法(在专利法的意义上)有时可使用一个或多个过程或方法(在计算科学意义上)来实现。

“自动地”指的是使用自动化(例如，由用于这里所讨论的特定操作和技术效果的软件配置的通用计算硬件)，与没有自动化相对。具体而言，“自动” 执行的步骤在理论上或在一个人的意识中不是用手执行的，但这些步骤可由人类来启动或由人类来交互式地引导。自动化步骤使用机器执行的以获得在没有由此提供的技术交互的情况下将不会实现的一个或多个技术效果。

技术人员理解技术效果是技术实施例的假定目标。仅仅是在一实施例中涉及计算并且这些计算也可以在没有技术组件(例如，通过纸和笔或甚至作为脑力步骤)的情况下执行的事实不会移除技术效果的存在或更改该实施例的具体且技术的特性。例如，某些熟悉的设备执行平衡计算来维持其平衡；一些示例包括移动机器人以及轮式个人移动设备(Segway公司的商标)。这些设备不是本文描述的实施例的一部分，但是它们示出了这一点：技术组件提供了技术效果，而不仅仅是思维步骤。平衡计算显然不能通过思维步骤或通过纸和笔来足够快速地执行以提供在许多移动机器人或轮式个人移动设备中存在的平衡。具有动态平衡设备的技术效果从而通过技术组件来提供，所述技术组件包括与平衡控制软件交互的处理器和存储器。

“在计算上”同样指的是使用计算设备(至少是处理器加上存储器)，且排除了仅通过人类思考或仅通过单独的人类动作而获得结果。例如，用纸和笔作算术不是如本文所理解的在计算上作算术。计算结果更快、更宽泛、更深、更准确、更一致、更全面和/或以其他方式提供超出单独的人类表现范围的技术效果。“计算步骤”是通过计算执行的步骤。然而，“自动地”和“在计算上”都不一定意味着“立即”。“在计算上”和“自动地”在此可互换地使用。

“抢先式”意味着没有来自用户的直接请求。的确，用户甚至可能直到已经向该用户呈现一实施例中的抢先式步骤的结果才意识到该步骤是可能的。除非另外指明，否则此处描述的任何计算和/或自动化步骤都可以被抢先完成。

贯穿本文，对任选复数“(诸)”的使用意味着一个或多个所指示的特征存在。例如，“(诸)处理器”意味着“一个或多个处理器”或等效于“至少一个处理器”。

贯穿本文，除非另外明确表明，否则对过程中的某一步骤的任何引用都假定该步骤可直接由所关注的一方执行和/或由该方通过介入机制和/或介入实体而间接地执行，且仍然在该步骤的范围内。也就是说，除非直接执行是被明确表明的要求，否则并不要求由关注方对步骤的直接执行。例如，涉及某一利益相关方的关于目的地或其他主体的诸如添加、关联、避免、检查、配置、定义、指定、确定、建档、执行、具有、标识、包括、交互、调用、记录、通知、注释、执行、提供、放入、接收、移除、代表、检索、采样、满足、查看、发送、设置、指定、开始、停止(以及其各种时态变形等)之类的动作的步骤可涉及：诸如由某一其他方执行的转发、复制、上传、下载、编码、解码、压缩、解压、加密、解密、认证、调用等中间动作，但仍然被理解为是由该利益相关方直接执行的。

在参考数据或指令时，要理解这些项配置了计算机可读存储器和/或计算机可读存储介质，从而将其变换为特定物品，而非简单地存在于纸张上、人的头脑中、或仅仅作为例如线路上的传播的信号。除非在权利要求中另外指明，否则权利要求不涵盖信号本身。存储器或其它计算机可读存储介质不是美国专利商标局(USPTO)对In re Nuijten案例的解释下的可授予专利的主题的范围之外的传播信号或载波。

此外，尽管明显相反，但将理解一方面的(a)计算机可读存储介质和计算机可读存储器，和另一方面的(b)也被称为信号介质的传输介质之间的清楚区别。传输介质是传播信号或载波计算机可读介质。相反，计算机可读存储介质和计算机可读存储器不是传播信号或载波计算机可读介质。除非另外声明，否则“计算机可读介质”意味着计算机可读存储介质，而不是传播信号本身。

操作环境

参考图1，用于一个实施例的操作环境100可包括计算机系统102。计算机系统102可以是多处理器计算机系统，或者也可以不是。操作环境可包括给定计算机系统中的一个或多个机器，它们可以群集的、客户机-服务器联网的、和/或对等联网的。个体机器是一计算机系统，且一组协同操作的机器也是计算机系统。给定计算机系统102可以例如用应用被配置用于最终用户、用于管理员、作为服务器、作为分布式处理节点、和/或以其他方式配置。

人类用户104可以经由键入的文本、触摸、语音、移动、计算机视觉、姿势和/或其它形式的I/O，通过使用显示器、键盘和其它外围设备106来与计算机系统102交互。用户界面可支持实施例和一个或多个人类用户之间的交互。用户界面可包括命令行界面、图形用户界面(GUI)、自然用户界面(NUI)、语音命令界面和/或其它界面呈现。用户界面可以在本地台式计算机或例如智能电话上生成，或者它可以从web服务器生成并被发送到客户机。用户界面可被生成为服务的一部分并且它可以与诸如社交网络服务等其它服务集成。给定操作环境包括支持这些不同的用户界面生成选项和使用的设备和基础结构。

例如，自然用户界面(NUI)操作可使用例如语音识别、触摸和指示笔识别、屏幕上和屏幕附近的姿势识别、空中姿势、头部和眼睛跟踪、话音和语音、视觉、触摸、姿势、和/或机器智能的那些方法。NUI技术的一些示例包括触敏显示、话音和语音识别、意图和目的理解、使用深度相机(如立体相机系统、红外相机系统、RGB相机系统、以及这些的组合)的运动姿势检测、使用加速度计/陀螺仪的运动姿势检测、面部识别、3D显示、头部、眼睛和注视跟踪、浸入式增强现实和虚拟现实系统，所有这些都提供更自然的接口，以及用于使用电场传感电极(脑电仪和相关工具)的传感大脑活动的技术。

技术人员将认识到此处在“操作环境”下呈现的上述各方面和其它方面还可形成给定实施例的一部分。本文的标题不旨在提供将特征严格地归类成实施例和非实施例特征类别。

作为另一示例，游戏可以驻留在Microsoft XBOX(微软公司的商标) 服务器上。游戏可从控制台购买或者整体或部分在服务器上、在控制台上、或在两者上执行。多个用户可以使用标准控制器、空中姿势、语音或使用诸如智能电话或平板等附随设备来与该游戏交互。给定操作环境包括支持这些不同的使用场景的设备和基础结构。

系统管理员、开发人员、工程技术人员、以及最终用户各自都是特定类型的用户104。代表一个或多个人操作的自动化代理、脚本、回放软件等也可以是用户104。在某些实施例中，存储设备和/或联网设备可以被认为是外围设备。图1中未示出的其他计算机系统可以按技术方式与计算机系统102进行交互，或者例如通过网络接口设备使用到网络108的一个或多个连接与另一系统实施例进行交互。

计算机系统102包括至少一个逻辑处理器110。计算机系统102与其他合适的系统一样，还包括一个或多个计算机可读存储介质112。介质112可以是不同的物理类型。介质112可以是易失性存储器、非易失性存储器、固定在位的介质、可移动介质、磁介质、光学介质、和/或其他类型的物理可持续存储介质(均不是传播信号)。具体而言，诸如CD、DVD、记忆棒、或其他可移动非易失性存储器介质之类的经配置的介质114在被插入或以其他方式安装时可以在功能上变为计算机系统的一技术部分，从而使其内容可被访问以供交互以及由处理器110使用。可移动的经配置的介质114是计算机可读存储介质112 的示例。计算机可读存储介质112的某些其他示例包括内置RAM、ROM、硬盘、以及其他不能被用户104轻松地移走的存储器存储设备。计算机可读介质和计算机可读存储器均不包括信号本身。

介质114用可由处理器110执行的指令116来配置；“可执行”在此以宽泛的意义被使用以包括机器代码、可解释代码、字节码和/或在例如虚拟机上运行的代码。介质114还被配置有数据118，该数据通过指令116的执行被创建、修改、引用和/或以别的方式用于技术效果。指令116和数据118配置它们所驻留的存储器或其它存储介质114；当该存储器或其它计算机可读存储介质是给定计算机系统的功能部分时，指令116和数据118还配置该计算机系统。在某些实施例中，数据118的一部分代表了诸如产品特征、清单、物理测量值、设定、图像、读数、目标、卷等等之类的现实世界的项。这一数据还通过备份、还原、提交、中止、重新格式化和/或其它技术操作来变换。

尽管一实施例可被描述为被实现为由计算设备(例如通用计算机、蜂窝电话、或游戏控制台)中的一个或多个处理器执行的软件指令，但这一描述并非意味着穷尽所有可能的实施例。技术人员将会理解还可经常整体地或部分地直接用硬件逻辑来实现相同或相似功能，以提供相同或相似的技术效果。作为对软件实现的替换或补充，本文描述的技术功能可以至少部分地由一个或多个硬件逻辑组件来执行。作为示例并且不排除其它实现，一实施例可包括硬件逻辑组件，诸如现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统组件(SOC)、复杂可编程逻辑器件(CPLD)和类似组件。一实施例的组件可基于它们的输入、输出和/或它们的技术效果来被分组成各个交互功能模块。

在所示环境100中，一个或多个应用120具有执行开发者在代码中指定的活动124的代码122。在一些情况下，应用代码122在线程126中组织，且在一些情况下，应用代码122由框架128(诸如运行时中的协调标准库的集合) 支持。诸如编译器、调试器、剖析器、以及性能监视器之类的软件开发工具130 通过产生和/或转换代码122帮助软件开发。代码122、工具130、以及图中和本文中讨论的其他项可各自部分或全部驻留于一个或多个硬件介质112中，由此配置那些介质以实现所有硬件-软件合作操作中固有的“正常”(即，最小公分母)交互的技术效果。

除了处理器110(CPU、ALU、FPU和/或GPU)、存储器/存储介质112、以及显示器132之外，操作环境还可包括其它硬件134，诸如电池、总线、电源、有线和无线网络接口卡和加速度计，这些硬件的各自操作在此被描述为并非已经对技术人员显而易见。CPU是中央处理单元、ALU是算术和逻辑单元、 FPU是浮点处理单元而GPU是图形处理单元。

给定操作环境100可包括向开发者提供一组协调的软件开发工具的集成开发环境(IDE)136，其向开发者提供一组经协调的软件开发工具130，诸如编译器、源代码编辑器、剖析器、调试器等。具体而言，对于一些实施例，合适的操作环境中的一些包括或帮助创建被配置成支持程序开发的 Visual开发环境(微软公司的商标)。一些合适的操作环境包括环境(Oracle America有限公司的商标)，并且一些操作环境包括利用诸如C++ 或C#(“C-Sharp”)等语言的环境，但本文的教导适用于各种各样的程序设计语言、程序设计模型、以及程序，以及本质上适用于软件开发领域之外的使用内联的技术努力。

在图1中以轮廓形式示出了一个或多个项来强调它们不一定是所示操作环境的一部分，但是可以与此处讨论的操作环境中的各项互操作。未采用轮廓形式的项在任何附图或任何实施例中也不一定是必需的。

系统

图2示出了适合与一些实施例一起使用的体系结构的各方面。一些实施例使用与一个或多个处理器110通信的存储器112提供诊断数据的基于活动的采样。驻留在存储器中的事件定义204的集合定义了开发者相信可阐明应用程序的行为的事件202。应用120也驻留在存储器中，并且具有被配置成调用至少一个日志事件规程206的应用代码122。当前活动id 208指定该应用的活动124 当前是否由开发者指明或代表开发者指明。当某个活动124当前被指明时，当前活动id还指定哪个活动当前被指明。

在一些实施例中，驻留在存储器112中的记录器210具有记录器代码212，该代码被配置成与处理器和存储器交互来检查314指定的312记录条件214的集合，并在至少一个指定的记录条件被满足时响应于日志事件规程206的调用而将日志条目218发送320至日志216。记录器210包括启用日志的活动220 的集合，并且还包括一个或多个开始事件222、202的集合，所述开始事件具有相应的采样频率条件224。每个开始事件222是在事件定义204的集合中定义的事件202，尽管其在该集合中未必被定义为开始事件，因为该角色可在记录器本身中配置。

在一些实施例中，所指定的记录条件214包括指定当前活动id 208存在于启用日志的活动220的集合中的第一条件。在一些实施例中，所指定的312记录条件214还包括第二条件，该第二条件指定当前活动id 208不存在于启用日志的活动220的集合中、日志事件规程206标识304开始事件222、以及日志事件规程206的调用与开始事件的采样频率条件224相一致。

在一些实施例中，开始事件采样频率条件224指定日志事件规程206的调用是针对开始事件222的第N次记录尝试，该开始事件具有每N个日志事件规程调用一个日志条目的采样频率226。在这些和/或其它实施例中，开始事件采样频率条件224指定在指定时间段内有少于M个的开始事件。

一些实施例包括至少一个设置活动id规程228调用，其被配置成设置当前活动id208。设置活动id规程调用驻留于以下的至少一者中：应用代码122、包括运行时来支持该应用代码的框架128。具体而言，应用120可以是C++应用，且框架128可包括熟悉的标准C++库。

在一些实施例中，该应用是多线程应用120。在一些实施例中，该实施例包括标识应用执行期间应用120的当前执行线程120的当前线程id 230。在一些实施例中，至少一个日志条目218包含当前线程id 230(“当前”意思是日志条目创建的当前)。在其它实施例中，该应用不是多线程的；基于活动的采样也可在例如分析使用分派循环来交错执行的单线程应用中有用。

一些实施例包括具有相应活动id 208的线程id 230的集合。记录器代码212 被配置成通过在线程id集合中查找328当前线程id来寻找相应活动id并随后使用该活动id作为当前活动id来检索当前活动id。

一些实施例包括性能监视器或另一日志消费器232，其可在该应用内或应用外。日志消费器的代码234被配置成向记录器210发送采样配置236消息238 来将至少一个事件202指定为开始事件222并指定针对该开始事件222的采样频率条件224。在一些实施例中，事件定义204和/或采样配置236还指定该事件的细节水平242。在这些和/或其它实施例中，采样配置236可按除通过消息 238之外的其它方式来指定，诸如通过配置文件、通过用户界面控制的参数、或适于指定316采样配置236(即，开始事件及其采样条件)的其它熟悉的进程间通信机制。

一些实施例包括子活动规程240调用，其被配置成通知334记录器210当前活动124正创建子活动124。在一些实施例中，记录器代码212被配置成响应于子活动规程调用而向启用日志的活动220的集合添加子活动。在一些实施例中，日志条目218建档由另一活动(即，由在子活动规程240调用时的当前活动)创建的子活动。

参考图1和2，一些实施例提供了具有逻辑处理器110和存储器介质112 的计算机系统102，其由电路、固件、和/或软件配置以通过用如本文所述的记录器210和记录条件214扩展功能性来提供诸如针对诸如过滤诊断数据记录机会的技术问题的基于活动的采样日志之类的技术效果。

在某些实施例中，诸如人类用户I/O设备之类的外围设备106(屏幕、键盘、鼠标、图形输入板、话筒、扬声器、运动传感器等等)将可以在操作上与一个或多个处理器110和存储器进行通信。然而，一实施例也可以深嵌入在技术系统中，以便没有人类用户104直接与该实施例进行交互。软件进程可以是用户104。

在某些实施例中，该系统包括通过网络连接的多个计算机。网络接口设备可以使用例如诸如分组交换网络接口卡、无线收发机或电话网络接口之类的组件提供对网络108的接入，并可存在于给定计算机系统中。然而，一实施例也可以通过直接存储器存取、可移动非易失性介质、或其他信息存储-检索和/或传输方法来传递技术数据和/或技术指令，或者，计算机系统中的一实施例可以在不与其他计算机系统进行通信的情况下操作。

某些实施例在“云”计算环境和/或“云”存储环境中操作，其中计算服务不是自有的，而是按需提供的。例如，应用代码122可以在联网云的多个设备 /系统102上，日志216可以被存储在云内的又一些其他设备上，且日志消费器 232可以配置另外一些其他云设备/系统102上的显示器。

过程

图3用流程图300示出了某些过程实施例。在图4到9中还示出了其它过程步骤。各附图中示出或以其他方式公开的技术过程可以在某些实施例中(例如通过记录器210)自动执行，例如在脚本的控制下或以其他方式需要极少或不需要同时的实况用户输入。除非另外指明，否则过程也可以部分自动地且部分手动地执行。在一给定实施例中，可以重复过程的零个或更多个所示出的步骤，有可能利用不同的参数或数据来操作。一实施例中的步骤也可以按照与图 3中展示的自顶向下次序不同的次序来执行。步骤可以串行地、以部分重叠的方式、或完全并行地执行。遍历流程图300以指出在过程中执行的步骤的次序可以在过程的一次执行与该过程的另一次执行之间不同。流程图遍历次序也可以在一个过程实施例与另一过程实施例之间不同。各步骤还可以被省略、组合、重命名、重组、或以其他方式偏离所示出的流程，只要所执行的过程是可操作的，并符合至少一个权利要求。

此处提供了帮助示出该技术的各方面的示例，但是在本文内给出的示例并未描述所有可能的实施例。实施例不仅限于此处所提供的具体实现、排列、显示、特征、方法或情形。给定实施例可包括例如附加的或不同的技术特征、机制、和/或数据结构，并可以以别的方式偏离此处所提供的示例。

一些实施例使用记录器210来执行诊断数据的基于活动的采样的技术过程。一些实施例用代表启用日志的活动220的集合的数据118以及用代表具有相应采样频率条件224的开始事件222的集合的数据404、118来配置332记录器。在一些实施例中，记录器210中的数据406、118将线程id与活动id相关联342，该线程id标识326计算系统的线程，而该活动id标识至少部分由所标识的相关联线程执行的活动。一些实施例在记录器中接收344由调用线程对日志事件规程调用的指示346，该指示指定一事件。一些实施例确定348在启用日志的活动的集合中表示的任何活动是否当前是调用线程的活动。如果启用日志的活动的集合中表示的任何活动当前是调用线程的活动，则该事件被记录 356在诊断数据日志216中。如果启用日志的活动的集合中表示的活动当前均不是调用线程的活动但是该事件为开始事件且日志事件规程的调用满足该开始事件的采样频率条件，则该事件被记录在诊断数据日志中且调用线程的活动被添加336到启用日志的活动的集合。

一些实施例提供350定义事件的事件定义的集合。具体而言，事件定义被提供至以下的至少一者：应用120、记录器210、日志消费器232。在一些实施例中，事件定义指定针对至少一个事件的细节水平。

一些实施例停止352对特定活动的记录，即使日志空间或其它资源可用且该应用程序正在执行358活动。一些实施例响应于以下的至少一者来停止352 记录：看到停止记录事件202、在先前看到开始事件已触发了对该活动的记录之后再次在启用日志的活动上看到开始事件222。

一些实施例响应于设置活动id规程228调用来设置322当前活动id。一些实施例在以下至少一者中如此做：在计算系统102中的应用120、包括支持该应用的运行时的框架128。当前活动id指定该应用的任何活动是否当前被指明 310为要被记录，且当某个活动当前被指明为当前活动id时还指定哪个活动当前被指明。

一些实施例在子活动是在启用日志的活动的集合中的父活动的子活动时，自动向启用日志的活动220的集合添加354、336该子活动。子活动响应于接收以下指示而被添加354：在父活动在启用日志的活动的集合中的同时，该子活动是该父活动的子。一些实施例记录处于启用日志的活动的集合中的父活动对任何子活动的创建。

通过进一步图示，考虑其中实施例将在此处被表示为线程1的线程id与此处被表示为活动1的活动id相关联342且随后在记录器中接收344线程1的日志事件规程调用的指示346的情形。假定指示346指定在此处被表示为事件1 的事件。一些实施例避免记录事件1，因为活动1不在启用日志的活动的集合中。现在假定指示指定在此处被表示为事件2的事件。一些实施例记录事件2，即使活动1不在启用日志的活动的集合中，因为事件2是开始事件，且还将活动1添加336到启用日志的活动的集合中，因为事件2是开始事件。现在假定指示指定在此处被表示为事件3的事件。一些实施例避免了记录事件3，即使事件3是开始事件，因为事件3的采样频率是每N个日志事件规程调用一个日志条目，且该日志事件规程的调用不是事件3的第N次记录尝试。

一些实施例如由以下示例所解说的那样操作，该示例在后文中为了方便而被称为“WebRequestStart(Web请求开始)示例”。为了更大的易辨识性，在本示例中未使用参考标号，但是该示例中大写的项名称指代图中具有类似或相同项名称的项，例如，“LOG-CONSUMER(日志消费器)”指代日志消费器232， “LOG-EVENT(日志事件)”调用指代日志事件规程206调用，如此等等。

配置：日志消费器向开始事件的列表添加<事件＝WebRequestStart，采样频率＝每5个中的1个>。

线程1：SetCurrentThreadActivityId(A1)(设置当前线程活动Id(A1)) ->在内部数据结构“线程1,A1”中的记录.

线程1：LOG-EVENT(Event＝SomeEvent)->事件未被记录(因为A1未被启用)

线程1：LOG-EVENT(Event＝WebRequestStart)->事件被记录且A1被添加到启用日志的活动列表。(A1未被启用，但是WebRequestStart是开始事件)。

线程1：LOG-EVENT(Event(事件)＝SomeEvent(某个事件))->事件被记录(因为A1被使能)

线程1：LOG-EVENT(Event＝ChildActivityCreated(子活动被创建),ChildActivity(子活动)＝A2)->事件被记录，A2被添加到启用日志的活动列表。(因为A1被启用)

线程1：SetCurrentThreadActivity(0)(设置当前线程活动(0))->A1被从LOG-ENABLEDACTIVITIES(启用日志的活动)移除，在内部数据结构“线程 1，0”中记录

线程2：SetCurrentThreadActivity(A2)->在内部数据结构“线程2,A2”中记录

线程2：LOG-EVENT(Event＝SomeEvent)->事件被记录(因为A2被启用)

线程2：SetCurrentThreadActivity(0)->A2被从LOG-ENABLED ACTIVITIES 中移除，在内部数据结构“线程2,0”中记录

线程1：SetCurrentThreadActivityId(A3)(设置当前线程活动Id(A3))-> 在内部数据结构“线程1,A3”中记录。

线程1：LOG-EVENT(Event＝SomeEvent)->事件未被记录(因为A3未被启用)

线程1：LOG-EVENT(Event＝WebRequestStart)->事件未被记录(A3未被启用,WebRequestStart是开始事件但是已经被激活一次在另外三次记录 WebRequestStart(不包括这一次)的尝试之后，其将再次激活，因为其满足采样准则(每5次中将有一次激活且开始采样)。

现在特别注意图4，并且继续注意图1到3，在一些实施例中，开发者104 定义302要被记录356的事件，即事件定义204。至少一个事件定义204可被配置332为开始事件222(例如，上述WebRequestStart示例中的 WebRequestStart)。事件定义204可位于应用120中，或位于别处且由应用导入408。事件定义204还对事件消费器232可见，且可对记录器210或其它系统组件可见。事件定义可包括该事件的细节水平，例如，简略的或详细的。在一些实施例中，日志消费器可配置332任何事件以担当采样开始事件222。开发者还可定义302事件，其意图为所述事件可作为活动内的进程的指示被记录。为了在应用120执行期间触发事件202，开发者还将日志事件规程调用308放入306应用代码122中。

在一些实施例中，开发者还定义302可记录的停止事件。如果应用120停止对一活动的记录，则该活动被从启用日志的活动220的集合中移除。在一些实施例中，应用和/或记录器使用试探法来确定记录356何时对一活动停止。这样的一个试探法是在看到启用日志的活动上的开始事件之际停止记录，如果该开始事件是被触发用于开始记录的同一事件。这些试探法按照需要变化来获得被写到日志216中的事件的所需采样集合。在一些实施例中，没有明确的停止事件。在一些实施例中，仅在应用停止时或在日志到达最大准许大小或系统达到某个其它资源约束时停止记录。

开始事件、停止事件、以及里程碑事件反映开发者对应用的语义的视角。例如，在以上示例中，WebRequestStart和DatabaseCallStop(数据库调用停止)是一个开发者的针对反映活动的进程的事件的有意义的名称。记录器210 未必基于那些语义采取任何动作，而是反而简单地如所指示地记录事件。从记录器采样技术的角度，所有里程碑事件彼此基本相同，且所有开始事件彼此基本相同。

在一些实施例中，不存在用于将线程126与活动124相关联342的可记录事件，但是存在用于在记录器210内创建关联的至少一个规程228，例如SetCurrentThreadActivityID()规程。记录系统具有用于记录哪些线程在针对什么活动工作的机制(例如，<线程id,活动id>对的列表或表格)，且通过在被记录的每个事件中包括该活动id来将该信息显现给日志消费器232。在一些实施例中，线程id可作为SetCurrentThreadActivityID()参数被传递，而在其它实施例中，记录器从内核线程调度器或通过检查该函数被调用的线程来获得当前线程的ID。活动id作为SetCurrentThreadActivityID()参数被传递。当然，名称“SetCurrentThreadActivityID”在此处被简单地用作示例，具有其它名称的规程228可提供相同功能性。

在一些实施例中，采样在运行时被来自性能监视器410或其它日志消费器 232的消息动态地启用或禁用。日志消费器232发送330消息来配置一个或多个开始事件的集合，每个开始事件具有在看到该事件时将如何经常地采样的采样频率224。例如，为了采样每100个web服务请求中的一个web服务请求，一个实施例将传递自变量arguments[“ActivitySamplingStartEvents(活动采样开始事件)”]＝“WebRequestStart(Web请求开始):100”。随后，每100次 WebRequestEvent方法被调用时，将记录该事件并随后开始该活动的其余部分以及之后创建的每个子活动的采样。在一些实施例中，可能也具有超过一个的开始事件。例如，为了捕捉已被观察到导致不良性能的URL的日志，可能激活“ProblematicUrlObserved(观察到有问题Url)”事件且每当其被调用时开始采样：arguments[“ActivitySamplingStartEvents”]＝“RequestStart(请求开始):100ProblematicUrlObserved:1”.

在一些实施例中，开发者控制性能监视器或其它日志消费器232(诸如EventListener(事件监听程序)或ETW会话)，其向记录器发送消息来配置 332一个或多个开始事件的集合。ETW代表针对的Event Tracing (事件跟踪)(微软公司的商标)。基于活动的采样为生产监视解决方案提供了更好的动态过滤能力，以实现比熟悉的记录体系结构(诸如ETW)中的能力更低的开销，其中数据集合被“打开”或“关闭”。应用性能管理解决方案使用的基于探测工具的方法不与频繁跳跃线程的异步代码一起工作。

该消息还包括针对该开始事件222的陈述在该开始事件被看到之后何时和 /或多频繁地采样的采样频率条件224。采样开始事件id被放置在记录器的开始事件列表中。尽管性能监视器/日志消费器设置了开始事件，采样频率对，其不向启用日志的活动列表添加任何东西。当在运行时作为log-event()调用的结果观察到开始事件时，且当记录器确定所观察到的事件满足用于记录的准则(例如，自该事件id的上次成功登录满足配置采样频率时跳过的事件数)，开始事件被记录且针对开始事件的活动被置于启用日志的活动的列表中。

尽管日志消费器232被示出在图4中的应用120外，在一些实施例中，日志消费器在该应用内。即，应用可消费其自己的日志。更一般地，组件204、 210、216、232中的任一者或全部可驻留在应用120内或外。例如，应用可记录到存储器内缓冲区中，其中记录器、日志消费器和日志均在该应用内。一种可能流行的配置在应用内具有记录器，其中日志和日志消费器在该应用外，如图4中所示。

在一些实施例中，启用日志的活动的任何子活动被自动置于启用日志的活动220的列表内。在一些实施例中，子活动的存在通过在记录事件时包括子活动ID来记录，例如，WriteEventWithRelatedActivity(用相关活动来写事件)() 记录事件且还将新活动id标识为当前活动的子活动。与其它进程名称一样， WriteEventWithRelatedActivity()可被不同地命名，例如， WriteEventWithChildActivity(用子活动来写事件)()或WriteEventWithActivityCausedByCurrentActivity(用由当前活动引起的活动来写事件)()。子活动的标识也可不被考虑为因素，例如，在一些实施例中， ActivityCausedByCurrentActivity(由当前活动引起的活动)(新活动id)不记录任何事件但是向启用日志的活动的列表添加新活动id。在许多实施例中，父-> 子关系被记录，以使得日志消费器知晓针对父活动和子活动的事件是相关的。在一些场景中，可采样子活动而不记录该关系。

在一些实施例中，在应用执行期间，set-activity-id(设置活动id)()规程 228和log-event(日志事件)()规程206被调用。在一些实施例中，这些调用被开发者放入306代码122中。在一些实施例中，设置活动id和日志事件也可被平台(框架128)调用。在一些实施例中，开发者将无需调用set-activity-id()，因为增强的.NET^TM框架128(微软公司的商标)将已经在正确的地方调用了它。

在一些实施例中，SetCurrentThreadActivityID(线程id,活动id)及其带不同因素的变形SetCurrentThreadActivityID(活动id)是Set-activity-id()规程的示例。set-activity-id()规程228更新记录器<线程id,活动id>对406，但是不在日志216 中带来任何条目。

在一些实施例中，所有其它采样规程(WebRequestStart、 DatabaseCallStop……)是log-event()规程206的示例。如此，如果采样频率准则被满足或当前线程的活动在启用日志的活动的列表中，则它们将在日志里带来条目。日志条目的精确内容取决于其log-event()规程被调用的事件的事件定义。

MvpEventSource.Log.foo(线程id,活动id,某个其它事件)是log-event()规程206的一个示例格式，而其它格式对本领域技术人员将显而易见。在一些实施例中，当log-event()被调用时，通过检查调度器来确定当前线程id来获得线程id，且该线程id被记录器用来查找该线程的活动id。在一些实施例中，当 log-event()被调用时，记录器在启用日志的活动列表上寻找活动id，要么能找到，要么找不到。如果在启用日志的活动列表上的确找到了活动id，则该事件被记录。如果在启用日志的活动列表上没有找到活动id，则检查318来查明此记录尝试是否是基于采样频率应当开始采样的记录尝试，例如，每100个log-event()调用1个日志条目的事件中的第100次尝试，且相应地要么创建日志条目并将当前活动添加到启用日志的活动的列表，要么不这么做。如上所述，开始事件的成功记录将开启当前与线程id相关联的活动id、以及从其活动id 被设置的线程id创建的任何子活动id的活动采样。

在一些实施例中，在应用120执行期间或执行后，日志条目被性能监视器或其它日志消费器232消费412。

经配置的介质

一些实施例包括经配置的计算机可读存储介质112。介质112可包括盘(磁盘、光盘，或其他)、RAM、EEPROM或其他ROM、和/或其他可配置存储器，特别包括计算机可读介质(而不仅仅是传播信号)。经配置的存储介质可以特别地是诸如CD、DVD或闪存之类的可移动存储介质114。通用存储器(其可以为可移动或不可移动的，且可以为易失性的或非易失性的)可被配置到使用诸如以下的项的实施例中：启用日志的活动220的集合、一个或多个采样开始事件222、采样频率条件224、设置活动id规程228、采样配置消息238、以及图3或图4中示出的其它项，其形式为从可移动介质114和/或诸如网络连接的另一源读取以形成经配置介质的数据118和指令116。经配置介质112能够使计算机系统执行本文所述的用基于活动的采样以提供诊断数据的技术过程步骤。伴随本文档的文本的附图从而帮助示出了经配置的存储介质实施例和过程实施例，以及系统和过程实施例。具体而言，图3和/或图4中示出的各过程步骤中的任一步骤或本文以其他方式教导的任一步骤可被用来帮助配置存储介质来形成经配置的介质实施例。

其他示例

下面提供了额外的细节和设计考虑。如同此处的其他示例，在给定实施例中，所描述的特征可以单独地使用和/或组合地使用，或根本不使用。

那些本领域的技术人员将理解，实现细节可以涉及诸如特定API和特定示例程序之类的特定代码，且因此不必出现在每个实施例中。本领域的技术人员还将理解，在讨论细节时所使用的诸如规程名称和事件名称之类的程序标识符和某些其他术语是针对具体实现的，且如此不必涉及每个实施例。尽管如此，虽然它们不一定需要出现在这里，但是提供了这些细节，因为它们通过提供上下文可以帮助一些读者，和/或可以示出此处所讨论的技术的许多可能的实现中的一些。

作为基于活动的采样的另一概述，在一些实施例中，采样状态跟随机器的执行流，包括当执行在线程间跳跃时。在一些实施例中，活动采样按通用方式实现且可被配置而无需修改应用120。

在一些实施例中，针对线程上的每个顺序执行单元生成活动id并将该活动 id记录于在给定线程上运行的代码能够访问的位置中。诸如由应用记录的事件之类的机制触发给定活动id的采样的开始。一旦采样已开始，该实施例将当前活动id添加到记录正被采样的活动的表格。开发者可配置一实施例以使得在活动被采样时将仅记录所需的诊断数据集。当此诊断数据具有被记录的机会时，该实施例检查来查明其当前活动是否处于正被采样的活动的表格中。如果其在表格中，则该数据被记录，如果其不在表格中，则该实施例不记录该数据。

在一些实施例中，如果活动导致另一执行单元稍后在当前线程或另一线程上运行，且在该执行单元被调度时该活动正被采样，则该另一执行单元的活动 id被添加到活跃活动的表格。一种替代方案是生成单一活动id，该单一活动id 可针对子活动重用，但是这减少了可从执行流推断的信息量，诸如什么诊断数据可作为执行流的一部分被分组在一起。

图8示出了这样的基于活动的采样的技术结果和可能益处。具体而言，针对三个线程T1到T3示出了若干活动A1到A6。本示例中的基于活动的采样的一个效果是：由不带采样的活动生成的过量诊断数据被减少到被实施采样的特定活动的诊断数据的更相关子集。

图5和7从不同角度提供了附加示例。图5示出了其中不同活动在web服务器中的不同线程上运行但形成整个web请求流的相关部分的示例。一些实施例通过在一个活动派生另一个活动时在日志中进行注释340和/或通过在父活动在启用日志的活动220的列表上时向该列表添加354被派生(也被称为子) 活动来促进这种不同活动的连接。图7示出了用于另一web请求的被采样执行流生成的信息，并且具体示出了当一个活动派生另一活动时在日志中的注释 340。

关于在一些实施例中定义活动124，首先考虑以下背景。性能上下文包括唯一标识符、PID、以及子任务标识符、STID。性能ID(PID)对于每个新根任务是唯一的且跨与根任务相关联的任务树共享。子任务ID(STID)是描述每个任务在任务树中的位置的有序数字集。起始数字通常为0。起始数字1指示在整个子任务树内跟踪子任务的位置不是可能的。以下三个场景示出了在 HTTP请求被从HTTP服务器(作为反向代理)发送至应用服务服务器且HTTP 服务器涉及来自应用服务服务器的两个远程web服务的调用时PID和STID如何被使用。

PID-STID场景一包括HTTP服务器上的根任务，其中：新PID＝1234,根 STID＝0。

PID-STID场景二包括HTTP服务器上的应用服务服务器上的单个子任务，其中：相同PID＝1234,子任务STID＝0:1。

PID-STID场景三包括两个子任务，每个web服务上一个子任务，其中：被调用的第一web服务使用相同PID＝1234,子任务STID＝0:1:1，而被调用的第二web服务使用相同PID＝1234,子任务STID＝0:1:2。

在一些实施例中在PID-STID方法和用于活动的定义的方法之间存在某种重叠，但是这两种方法也在某些方面不同。例如，在一些实施例中，所有任务 (根任务和子任务)是活动，但是并非所有活动都是根任务或子任务(活动的定义更宽泛)。类似地，任务的PID-STID树(开始于根任务)也可被认为单一活动，但是并非所有活动都是任务树。PID是活动ID，因为其可唯一标识系统内的(任务树)，但是并非所有活动ID是PID。STID自己不是活动ID，因为其将与PID组合来唯一标识任务(即，任务A可具有PID＝1234,STID＝0:1，而任务B可具有PID＝1235,STID＝0:1)。在这些实施例中，活动ID从来不是 STID。性能上下文是活动ID，因为PID和STID的组合能唯一标识系统内的活动(任务)。并非所有活动ID是性能上下文。

从而，一些实施例具有比PID-STID机制更宽泛的用于跟踪执行的机制。为了突出这两种机制之间的一些差异，可通过如下地约束一实施例的更宽泛的定义来表达PID-STID机制。每个任务都是活动，其中活动ID由PID和STID 构成(例如，活动ID是性能上下文)。活动之间的关系在父->子关系树中描述。对于具有相同PID的两个任务，它们被约束为是相同活动树的部分。该ID的 STID部分可编码活动之间的父->子关系，其中所述关系是有序数字集。

即，这些实施例不要求活动ID编码活动之间的关系，因为活动之间的关系可被记录在独立数据结构中(例如，通过记录包含活动之间的关系的事件)。的确，这些实施例甚至可以没有活动124之间的关系。也不必存在作为活动ID 的部分的有序数字集。在这些实施例中，活动ID可以是在给定时间点可唯一标识进程内的单个活动的任何数据集。尽管活动和活动ID对本领域技术人员是熟知的，然而这些实施例通过创新型工具和技术来利用它们来实现运行时的记录(采样)的动态启用和禁用。

在一些实施例中，活动被定义为系统102中的执行单元的编组，其中执行单元是特定线程在两个时间点之间所做的工作。编组可以是任意的，但是通常被形成以具有对用户或开发者104而言有逻辑或语义意义。在线程上执行的代码能够确定它当前与什么活动相关联。例如，活动可以是web服务器为对http 请求作出响应而做的所有执行。

活动可任选地与其它活动相关，其中活动之间的关系是任意的且可在运行时或在事实之后被表达。这些关系允许形成活动组。例如，可具有活动树，该活动树表示web服务器为对http请求作出响应而做的所有执行。在此示例中，该树可通过父->子关系来表达所有活动是相关的，其中父活动引起了要进行的子活动的所有执行。

一些实施例在此定义之上构建以准许采样技术的设计的更正式的定义。例如，为了允许采样相关活动组，一些人对被采样组中的活动施加了以下约束：如果活动A与活动B相关，且活动A的执行在活动B的执行之前开始，则“A 与B相关”的关系要在程序执行期间知晓活动A是被采样组的一部分的时间点处、且在活动B的任何执行发生之前被表达。这未必是全面的定义；例如，其可被放松以与旧式代码一起工作。

线程状态(诸如新、准备好、正在运行、以及被阻塞)是比线程上的序列执行单元更低级别(更详细)的概念。线程可在执行任务中间从正在运行改变为准备好或被阻塞，但是在其恢复到例如装备好状态时可继续执行该任务。执行单元是在其它工作可开始之前要在线程上完成的工作。通过异步代码，分派器将调度单一线程来代表系统中的其它组件运行许多小的不相关工作单元。每个单元在另一单元可被调度之前将运行到完成。由调度库来确定每个单元何时开始和停止。在.NET^TM 4.5环境(微软公司的商标)中，异步/等待这些单元被称为任务，但是第三方库可实现其自己的线程调度并设置活动ID来匹配本文的定义。

定义执行单元的两个时间点可以是(a)HTTP请求的自动确定的开始点和结束点，或(b)由用户或开发者在运行时期间或之后显式指定的时间点，例如，以便指示对用户或开发者具有逻辑或语义含义的执行单元。在许多(如果不是全部)情况下，在开发时或通过动态生成代码(在剖析代理在运行时注入代码的情况下)，所述时间点由正在执行的代码确定(即，被编程地确定)。一时间点中的执行代码将在某个数据结构中记录给定线程正在活动A上工作，且在稍后时间点将记录该线程现在没有在活动上工作或在一不同活动上工作。

例如，如果两个请求先后进入web服务，则web框架可采取以下动作：

t0(在请求1的开始):“线程1正在A1上工作”

t1(在请求1的结束):“线程1没在任何活动上工作”

T2(在请求2的开始):“线程1正在A2上工作”

t3(在请求2的开始):“线程1没在任何活动上工作”

A1由线程1在t0和t1之间所做的工作构成，A2由线程2在t2和t3之间所做的工作构成。记录或保持t0和t1不重要，但是在t0和t1之间在线程1上执行的代码可询问“我现在正在什么活动上？”并从系统得到答案“A1”。

以下讨论从生产中的活动跟踪和采样(ATSP)文档得出。ATSP文档包括用于以下用户故事的说明：“作为生产诊断方案提供商，我想要能够高效地跟踪使用异步/等待和/或.NET^TM线程池(微软公司的商标)”的web 应用上的请求，以使得我能向我的顾客提供智能监视和诊断信息。ATSP软件和/或文档的各方面与本文描述的实施例的各方面一直或另行解说本文描述的实施例的各方面。然而，要理解，ATSP文档和/或实现选择不必约束这些实施例的范围，且同样地ATSP和/或其文档将很好地包含位于这些实施例范围外的特征。还要理解，下面的讨论是部分作为对未必是本领域技术人员的读者的帮助的一部分来提供的，并且因此可能包含和/或省略了其下面的引述没有被阉割要求来支持本公开的细节。

ATSP文档包括以下定义：

APM:应用性能监视

ETW:的事件跟踪(微软公司的商标)。

活动或基础活动：单一线程上的序列执行单元。

逻辑活动：作为相同执行流的一部分的基础活动集合。

因果链：活动树，其父-子边缘代表父活动创建了子活动。

关于所解决的技术问题，ATSP文档意识到提供诊断信息的挑战，其将帮助开发者改善服务器和云应用的性能。改善其应用的性能意味着它们能降低其成本且向其用户提供良好体验。对于客户端应用，诸如CPU(处理器)和存储器分配之类的对于性能数据的每进程或每线程聚集几乎总是足以改善性能。这是因为特定应用仅服务一个用户，且重CPU使用或存储器分配的时段将通常指示性能问题。重CPU或存储器使用的时段可被分析以寻找改善应用的性能的可操作工作。

然而，在web应用上，数千用户可由单个进程同时服务。高CPU和存储器通常仅意味着许多用户正在使用该服务。为了提供有意义且可操作的信息，性能数据将在每请求基础上被聚集。为了在每请求基础上提供数据，跟踪系统正在做的所有工作以完成请求。这通过具有标识请求何处开始、请求何处完成、以及跟随其间的执行流的方法来完成。对于使用异步编程模型的应用这几乎是不可能做的，因为请求将被分为小执行单元，所述小执行单元与多个线程上的其它请求交织。一些熟悉的工具可在每请求视角上提供一些数据，但是其不是通用(不在每处工作)且是太高的开销(收集太多数据)。同时，通过网络将所有生产诊断解决方案移动到基于ETW的技术存在潜在益处。ETW具有许多有吸引力的特性，一个特性是在给定时间多个剖析器可以活跃。当前生产诊断解决方案使用CLR剖析API，该API向应用注入探测工具。

ATSP文档从技术角度提出所建议的解决方案。首先，对于活动ID 208支持，向活动ID的现有ETW概念的事件源添加支持。被记录到系统中的每个 ETW事件具有两个字段：活动ID以及相关活动ID。这些字段意味着要被用于跟踪请求，但是它们关于它们要如何被使用没有已确立的指南。传统方法是定义唯一活动ID，该唯一活动ID表示整个请求。出于本文讨论的理由，确立将在每次请求改变线程时使用不同活动ID的约定。有人可能认为这些活动是“基础活动”。为了对尽可能多的应用进行活动跟踪工作，向任务并行库(TPL) 和.NET^TM线程池(微软公司的商标)添加EventSource(事件源) 探测工具，其将设置活动ID和相关活动ID字段。

通过web服务请求的基本示例来考虑这如何工作。以下是针对web服务的用于处理http请求、对搜索服务器、数据库服务器作出请求并向用户返回网页的一些伪代码。

每当从等待调用返回执行时，可能处于不同线程上。我们已经将保证呆在单一线程上的每个执行单元标记为活动1-3。参见图5以获得代表此代码的图片。对于该系统，这看着像是在线程池上出现的三个不相关执行单元。以上代码看上去就像序列代码。将这些工作单元缝在一起是有用的，以使得诊断工具能提供正完成的工作的序列视图以匹配开发者对其代码的序列理解。为了将所有该工作缝起来，设置每个执行单元的活动ID 208并记录356指示新活动何时被创建的事件。可将活动124及其之间的关系指代为因果链。事件流随后可被后处理以形成逻辑活动124，该逻辑活动是作为相同执行流的一部分的活动集。

在图6中示出了此处理的一个示例。想象图6左侧的线程视图不带标签和箭头，使得难以(如果不是不可能)明确知道这些工作单元相关。相反，每个执行单元的活动ID将通过使用新静态方法 EventSource.SetCurrentThreadActivityId()来设置，且在新活动被创建时记录的事件将通过调用新实例方法EventSource.WriteEventWithRelatedActivityId()来生成。TPL将是调用这些应用程序接口(API)的主要库，但是在此实现中，调度其它线程上的工作的任何代码也将调用这些API。

在一些实现中，在请求过程期间记录的任何有意思的事件(诸如所使用的 web框架或各种库中的探测工具)将被自动打上活动ID的标签。这一点的有用示例是异常：如果抛出异常事件，则将用正确的活动ID来将其自动标记。该 ID可被用来确定每个被记录的事件属于什么逻辑活动。图7包含可能从示例 web请求记录的事件集的示例。此例假定开发者正使用的库记录请求的开始/ 结束事件并对搜索服务和数据库服务做出调用。随后可将逻辑活动定义为在请求开始和结束事件(即，A1、A2和A3)之间创建的所有活动。由于数据库和搜索事件被用活动ID标记，可将数据库和对请求的搜索调用相关并确定诸如该请求上多少时间被花在等待数据库和搜索服务上之类的感兴趣的信息。

关于采样，ATSP文档假定活动跟踪将在生产中使用，且具体而言将被想要以最小开销(1-2％CPU)运行的监视代理使用。通过每秒可能数千请求被单一机器处理，对于在每个请求上的每个活动转换发出事件将是计算上昂贵的。为了减少开销量但仍旧提供高价值信息，一些实现允许在逻辑活动级别对活动事件采样。事件被关闭，且随后根据请求，开始事件将开始被记录，但是仅对于该基础活动且由该基础活动创建的逻辑活动集。图8示出了每次两个请求正在该系统上运行，且示出了采样将如何减小系统生成的信息量。这允许APM 采样系统上的请求，但是对于被采样请求仍旧获得信息的全保真性。采样和采样频率将通过在EventSource提供方经由ETW系统或通过EventListener(事件监听程序)被打开时向该EventSource提供方提供参数集来配置。在一些实现中，此活动采样仅对于基于EventSource的探测工具工作。

在一些实现中，可通过使用TPL和/或ThreadPool(线程池) (.NET^TM线程池；微软公司的商标)的任何事物来跟踪活动因果关系。开发者可检索324当前执行线程的活动ID。可与也利用活动字段ID的其它系统互操作，其可能具有不同约定。活动跟踪是按播放付费的：当TPL和线程池提供者被关闭时其具有0开销。第三方可支持在调度线程上的工作的库中的活动跟踪而不使用TPL或线程池。

在一些实现中，有可能采样针对系统中单一请求的事件而无其它记录事件的请求。可配置EventSource组合上的任何事件以担当活动链的采样起始点。当采样被关闭而正常EventSource记录被开启时采样具有0开销。在一些情况下，有可能配置采样率来实现系统中的<1-2％的开销(每秒<5,000ETW事件)。作为不变情况，开启采样比不采样具有更低的开销。在一些情况下，新特性通过进程内EventListener(事件监听程序)和事件的进程外跟踪事件/ETW消费器两者可用。

在一些实现中，.NET^TM框架128中的探测工具被添加以支持框外请求跟踪，诸如TraceEvent库的被支持版、ASP.NET和HttpClient中的基于 EventSource的请求开始/停止事件(微软公司的商标)。采样代理开启活动跟踪和采样。一些配置可包括：进程外的、基于ETW的代理；进程内的、 EventListener代理；不使用过滤而是以“flight-recorder(飞行记录仪)”模式操作的进程内的EventListener代理。飞行记录仪意味着该代理将记录所有转换事件，并在感兴趣的事件发生时经由ETW事件将其写出。

ATSP文档包括功能设计。关于活动跟踪，在一些实现中，活动是在ETW 中用来将原本看上去不相关的一群事件相关在一起的概念。所发出的每个ETW 事件具有用于一活动ID的字段，以及相关活动ID。传统上，系统中的单一web 请求将具有一个活动或少量活动(例如，每个组件一个活动)。活动ID是线程局部变量，所以一旦活动ID在线程上被设置，则该线程上记录的所有事件将包含该活动ID。当另一组件创建其自己的活动ID时，相关活动ID字段被用来使两个活动相关在一起。包含父和子活动ID的事件被称为转移事件。

然而，这些语义使得用户代码的部分负责生成活动ID、四处传递该ID、以及拥有该ID的寿命。它们还意味着在开发时决定请求的诊断信息的粒度。例如，ASP.NET的进程请求方法可能想要将整个请求定义为单个活动。该请求可由并行进行的多个操作(数据库调用、挖掘数据、渲染文本等)构成。作为请求的一部分来隔离单个并行操作的影响可能是有用的，在这种情况下，可能想要为该并行操作分派活动ID。应用和框架开发者在编写其代码时不自动将此纳入考虑。库和web框架可能不实现活动ID跟踪系统。

不是尝试推理所有这些复杂疑问，而是完全翻转该问题。将系统上的执行打断为最小的可期望粒度单元：活动是线程上的序列执行单元。创建以下规则：任何时间执行在不同线程上继续时，实现将创建新活动并生成转移事件。在转移事件被编写时，新活动是子活动(在该事件的相关活动ID字段中设置)，且原始活动是父活动(在该事件的活动ID字段中设置)。

此方法允许开发者在分析时(即，在程序执行期间和/或程序执行后)决定出于其分析的目的对什么工作分组感兴趣。该工具化可根据任何基础活动集合形成“逻辑活动”，如在图6中建议的。渲染HTML的并行化工作器均可被独立地或作为整体被查看和分析，无论开发者需要诊断其什么性能问题。通过此方法，大多数应用和框架开发者的负担小得多：通过调用开始/停止事件规程 206，他们仅指示其应用的某些部分是感兴趣的。这些事件可标记请求的开始和结束、HTML渲染的开始和结束、或任何有可能感兴趣的。这些事件可在事实之后(因为大多数开发者在事后意识到他们需要这些东西)用非常少的代码行122来添加且无需对其代码库的大的中断。如果对于库和框架开发者而言做此相对少量的工作成为标准，则大多数应用开发者将不需要对其应用做任何事。一旦这种模式成为主流，开发者必须主动管理其“端到端跟踪上下文”并将GUID填充到方法参数中的日子将一去不返。

关于活动采样，另一设计考虑是事件量vs.数据的价值。当面临具有每秒 10,000个请求的web服务时，通过收集来自每秒10-100个请求的数据可获得与通过收集来自所有事件的数据所获得的几乎同样有价值的信息。一个技术问题是不能仅盲目地抛出事件：对于被采样的任何请求，具有针对该请求的所有事件是最有用的。为了以低量开销提供高价值数据，一些实现将开启在一活动以及该活动创建的任何子活动上的采样。这在图8中被解说。启动采样的一逻辑位置是当感兴趣的事件被激活(诸如启动事件)时，所以一些实现支持配置采样开始事件222的能力。

关于设计架构，.NET^TM 4.5环境(微软公司的商标)包括用于具有EventSource类的ETW事件的记录的添加的抽象。使用此类，可以通过 Windows中的ETW系统将事件记录到进程外监听程序。为了进程中读取探测工具，用于读取EventSource类生成的事件的EventListener(事件监听程序) 类被引入。

在一些实现中，用于写出转移事件的方法将被添加至EventSource类。转移事件将能由ETW和EventListener消费。一些实施例还向EventSource添加允许线程本地存储上的活动ID的设置和检索的静态方法。为了使得采样成为可能，将存在每监听程序过滤器。ETW会话和EventListener是监听程序的实例且具有其自己的过滤器。过滤器将允许所有事件通过，或基于该事件上的活动 ID选择性地允许事件通过。过滤器是开发者不能直接访问的概念细节。来自 EventSource的事件通过过滤器且到监听程序的传播在图9中示出。

在根据图9的实施例中，从事件源到过滤器的每个连接以及通过过滤器的事件集合被独立地配置。配置在监听程序是事件监听程序的情况下由 EventListener.EnableEvents(事件监听程序.启用事件)完成，或在监听程序是 ETW的情况下由TraceEventEnableEvents()完成。仅四个ETW会话可使用采样，该方法施加的实现限制被用于将被采样事件路由到ETW会话。一直仅有一个 ETW监听程序，但是可以有许多EventListener实例。EventListener的能力匹配 ETW监听程序的能力。

ATSP文档包括详细实现信息，将其在下面重现。然而，如所指出的，各实施例不限于ATSP实现，且ATSP文档和实现包含在给定实施例中未必需要的细节。

对EventSource类的改变

这些是对Systems.Diagnostics.Tracing.EventSource类的改变以支持活动跟踪和采样特性。

本能地期望能够在EventCommand.Update(事件命令.更新)中向事件源传递以更改当前其上正活跃的自变量(以改变活动过滤及其它)。在其当前状态中不具有这种可能性。而且，当编写EventSource(事件源)方法时，WriteEvent (写事件)开始于1处。在事件id和方法本身之间存在准确地1-1的映射。这一点的任何变化导致异常。而且，具有类似MyEvent(){WriteEvent(1, “HOWDY！”)；}的方法抛出不解释为何该情况失败的异常。

新SetCurrentThreadActivity方法

此新方法具有两个过载。

签名：public static void SetCurrentThreadActivityId(Guid activityId)

参数：activityId:要在当前线程上设置活跃的活动ID。

此方法被用来设置线程本地存储上的当前活动ID。这使得同一线程上的任何事件都被用所提供的活动ID标记，直到在该同一线程上开始新活动为止。非常少的人将实际上使用此API。实现这将从其自己的任务库中调用它，且仅管理其自己的线程的库将这样做。线程经常“代表”调用者做工作，所以概念上调用此方法告知诊断工具谁要负责正被完成的工作。调用 SetCurrentThreadActivityId(Guid.Empty)(设置当前线程活动Id(Guid.空)) 意味着当前线程上的工作将不与任何活动相关联，直到用有效活动ID来调用SetCurrentThreadActivityId为止。如果出于某种理由调用者想要打断因果链和/ 或从活动过滤器排除子活动，则这可能是期望的。

签名public static void SetCurrentThreadActivityId(Guid activityId,outGuid oldActivityThatWillContinue)

参数activityId:要在当前线程上设置活跃的活动ID。

oldActivityThatWillContinue(将继续的旧活动):当前线程上先前活跃的活动ID。

过载的此版本要被用来盖写别人在当前线程上的活动id。其通过输出参数oldActivityThatWillContinue返回旧活动id。在调用此API之后，在将控制返回给正被盖写的活动id的所有者之前调用 SetCurrentThreadActivity(oldActivityThatWillContinue)。其原本具有与以上相同的行为。调用SetCurrentThreadActivityId(0,out Guid)允许人们在后续 SetCurrentThreadActivityId调用中使用当前活动id并具有到该调用的采样流。活动将仅在其活动ID在线程上被设置且SetCurrentActivityId(Guid)被调用时被从过滤器表移除338。

新CurrentThreadActivity(当前线程活动)属性

签名public static Guid CurrentThreadActivityId{get；}

参数返回：当前线程上的活动ID。

用于检索线程本地存储上的当前活动ID。在一些情况下，获得活动ID而无需必须监听事件流可能是期望的。这种方法被用于包括将信息与 ETW/EventSource事件相关且不使用ETW/EventSource来存储该信息的场景。

新WriteEventCreatingRelatedActivityId方法

签名protected unsafe void WriteEventWithRelatedActivityId(inteventId, Guid relatedActivityId,params object[]args)

参数eventId:在EventSource内唯一表示此事件的id(而不是该事件的实例！)。

relatedActivityId(相关活动Id):

·如果该事件正被父(发送者语义)写，则这是由此活动创建的子活动的ID。

·如果该事件正被子(接收者语义)写，则这是创建此活动的父活动的ID。

自变量：该事件的载荷。如果仅需要创建子信息则可以为空，但是经常存在与子活动的创建同时发生的事件。

记录事件以指示当前活动与具有所提供的relatedActivityId的另一活动有关。当前线程的活动将与该事件一起被记录，从而允许两个活动被事件的消费器相关在一起。这被称为“转移事件”。

发送者和接收者语义之间的差异是转移事件被写的时间。发送者语义意味着父将在其被完成之前记录转移事件。通过发送者语义，将在活动完成之前知道该活动的所有子，且这使得活动采样的持续成为可能。接收者语义意味着子活动写转移事件，有可能在其父完成执行之后。这意味着在父活动已完成执行之前不知道该父的子的完整集合，且不可能用接收者语义来对子活动开启采样。

调用此方法的事件将在其针对该事件的属性中使EventOpcode.Send(事件操作码.发送)或EventOpcode.Receive(事件操作码.接收)操作码被设置。这些操作码声明正使用发送者还是接收者语义。在此示例中采样特性将与发送者语义一起工作，所以将向开发者提供使用Send操作码的指南。如果在当前线程上没有活动是活跃的，则在该事件被写出之前将创建新活动。如果对于当前 ActivityId采样是活跃的，且EventOpcode.Send操作码被针对该事件指定，则也将针对RelatedActivityId启用采样。在创建子活动的动作与应用中的另一诊断事件(例如TaskScheduled事件)同时发生时，这种调用可任选地包括事件载荷。对此方法做出太多调用而不调用活动ID上的SetCurrentThreadActivityId()可能最终打断采样。这是可被包括以阻止存储器泄漏失控的实现细节。如果事件属性不指定Eventopcode.Send或EventOpcode.Receive，则该方法将抛出异常

新WriteEventCore过载

签名protected unsafe void WriteEventWithRelatedActivityIdCore(inteventId,Guid*relatedActivityId,int eventDataCount,EventSource.EventData*data)

参数eventId:唯一标识正被写的事件的id(而不是该事件的实例！)。

relatedActivityId:指向子活动id的guid的指针。

eventDataCount(事件数据计数):数据字段中的条目数。

eventData(事件数据):指向事件数据字段中的第一个自变量的指针。

这是6.4.3的更高性能版本，在必须封盒和开盒relatedActivityId和事件载荷(args)上有节省。

更新IsEnabled方法

现有

签名public bool IsEnabled(EventLevel level,EventKeywords keywords)

参数级别：在确定事件源是否被启用时使用的级别

关键字：在确定事件是否被启用时使用的关键字

先前行为:如果事件有可能针对所提供的级别和关键字被记录则返回真。新行为:除了如果此事件将不因采样而被写到任何监听程序则返回假之外，与以前相同。

这可被用来避免事件将作为采样的结果而被抑制的情况下的昂贵计算。其还是跨机器跟踪故事的一部分：当一请求在被采样时，机器可通过线缆发送令牌至另一机器。这允许对于同一请求采样在该另一机器上继续。一变体包括发出回调以在已确定该事件将被写的情况下形成该事件。在一些实施例中，使用 IsEnabled(被启用)或类似机制帮助减少开销并促进机器到机器采样。例如，如果http请求源自启用日志的活动，则一些实施例在http通信中包括 SamplingEnabled(采样启用)旗标和/或头部。

经更新的GenerateManifest(生成清单)行为

现有

签名publicstaticstringGenerateManifest(

TypeeventSourceType,

stringassemblyPathToIncludeInManifest

)

参数eventSourceType:事件源的类型。

assemblyPathToIncludeInManifest:到要在清单中包括的.dll文件的路径。

当前行为:通过检查EventSource类上的方法的参数来写出事件源的事件数据的模式。经更新的行为：如果第一方法参数是名称为‘RelatedActivityId’(大小写敏感)的GUID，则将其忽略。这允许相关活动id被写到现有 RelatedActivityId字段(其不是事件载荷的一部分)而解析器不预期在事件载荷中看到此字段。

新ConstructionException(构建异常)属性

签名public Exception ConstructionException{get；}

此属性被用来收集在事件源的构建期间发生的异常。添加此属性是因为记录经常是任选的且因而将不生成毁灭性错误(异常)，且因为EventSource经常在类构造器中被初始化(其不良地传播异常)。

事件源构造器不抛出异常。相反，此实现记住被生成的任何异常(其也被记录到Trace.WriteLine)。

EventWrittenEventArgs上的新属性

System.Diagnostics.Tracing.EventWrittenEventArgs类被传递至EventListener.OnEventWritten()回调且包含由事件源写出的事件信息。两个属性被添加到此类，以使得活动Id和相关活动id可针对事件的进程中消费器被读取。

新ActivityId属性

签名publicGuidActivityId{get；internalset；}

描述在该事件被写时，返回该事件被写的线程上的活动id。

访问ActivityId字段将导致对线程本地存储的访问(使用p/invoke)。这具有一些暗示。EventWrittenArgs该字段仅对OnEventWritten()回调的持续期有效。这也是TLS变量将具有正确活动id值的唯一时间。而且，如果活动id在该回调期间被改变，则这将导致此属性所返回的已返回活动ID无效。

新RelatedActivityId属性

签名publicGuidRelatedActivityId{get；internalset；}

描述如果这不是Guid.Empty，则其意味着该事件的活动id与另一活动相关。

.NET框架代码的约定是：RelatedActivityId是由该事件的ActivityId所导致的子活动。将存在活动id->相关活动id的1-多关系。

扩展EventListener/ETW EnableEvents行为

System.Diagnostics.EventListener类将被扩展以能够配置采样。此类上的EnableEvents方法接受用于扩展性的自变量词典。这一实现将使用这些扩展性自变量来允许按照EventListener和ETW两者均支持的方式采样。

这些部分中的“API”按照现有EventListener.EnableEvents方法的自自变量参数中的字段来定义(在下方示出)。

publicvoidEnableEvents(

EventSourceeventSource,

EventLevellevel,

EventKeywordsmatchAnyKeyword,

IDictionary<string,string>arguments

)

此方法还具有相应的TraceEvent.EnableProvider()调用。此实现针对进程外ETW会话逆转EventKeywords(事件关键字)的4个位。这些关键字将在进程外ETW会话的matchAnyKeyword(匹配任意关键字)字段中被指定，以使得被采样的事件202可被路由到正确会话。这意味着在此实现中采样不能针对超过4个ETW会话被开启。TraceEvent将通过windows注册表来协调这些关键字的归属。如果第5个会话允许提供方采样，则TraceEvent将不能够找到可用关键字且将抛出异常。

StartSamplingWithEvent

此实现将提供标准“StartSamplingWithEvents(用事件来开始采样)”自变量，其可被用来配置被用于开始采样的一个或多个事件。

字段event-specifier:是事件的文本名称或该事件的数字id。

sample-rate:指示当此事件被看到时采样被多经常地开始。“从第一个开始，每n个事件被激活”更正式地：采样将在每n/<采样率>次事件202被看到时被开始，其中n是当采样没有开始时事件被激活的次数。如果在看到此事件时采样已经被开始，则其不朝n计数。

ETW监听程序将镜像同一功能，但是将被使用TraceEvent.EnableEvents() 进程外配置。当开始事件配置改变时，经更新设置可被使用字符串消息记录到 ETW，以使得日志的读者知晓数据正按什么频率被报告。对此方法的多个调用将盖写给定EventListener或ETW会话的先前采样开始事件配置。调用不带 ActivitySamplingStartEvents自变量或具有“”值的EnableEvents将不带采样地开启提供方。当事件被激活时，活动采样以该事件在其上激活的活动开始，且将对该活动的所有子活动继续。当开始事件被配置时，ActivitySampling自变量将对此事件源被设置为真，以使得仅按期望采样频率来记录事件。如果 sampling-config字段无效，则此实现将通过字符串日志消息在ETW流中报告错误。将尝试解析尽可能多的采样串，且将用有效说明来配置针对该事件的采样。

ActivitySampling(活动采样)

此实现提供了标准“ActivitySampling”自变量，其可被用来配置事件源以使其仅在针对当前活动启用采样时记录。

约定arguments["ActivitySampling"]＝“真”|“假”

字段如果为真，则此事件源将仅在对于当前活动而言采样活跃时报告事件。默认为假。

多次调用此参数将盖写先前设置的值。此值可每EventListener且每ETW 会话地配置。

任务并行库(TPL)的探测工具

此特性的一部分将探测TPL来创建因果活动链。可能机会主义地探测核心框架的其它区域(例如，定时器、GUI线程操作、或QueueUserWorkItem(排队用户工作项))。TPL已经使用EventSource类被探测。存在与子活动的创建同时发生的两个现有事件：

这些事件现在将使用WriteEventCreatingRelatedActivity()API来记录，且将使用从OriginatingTaskID生成的GUID作为RelatedActivityId。此外，新Tasks.Keywords.TaskTransfer关键字将被添加，其可与Informational(信息) 冗长级别相组合地使用以仅启用这两个事件。

当相关任务开始执行时，EventSource.SetCurrentThreadActivityId()方法将用RelatedActivityId来调用。通过对TPL探测工具的这些修改，此实现将能够跟随大多数应用的执行因果关系。

示例代码。下面提供若干段解说性伪代码来解说所指示的概念。本领域技术人员将理解，需要做出改变来从伪代码转换为商业实现。

向线程跳跃库添加活动跟踪支持

以下代码解说了管理其自己的线程调用的库的开发者为了流动活动因果关系必须做的事情。基础地，他们必须写转移事件并在正确时间点设置活动ID。

以下代码展示了如果库完全拥有该线程则该库将如何使用 SetCurrentThreadActivityId。

以下示例展示了先前活动ID语义的使用，其针对整个请求生成一个活动 ID并将其四处传递至所有线程。在此情况下使用SetCurrentThreadActivity API 有点不自然，但是鼓励开发者使用在以上代码样本中所显示的约定。

进程内事件过滤

以下代码显示了开发者将如何创建EventListener以开启TPL提供者并配置采样以每100次ASP.NET请求开始时发生

进程外代理

以下代码显示了TraceEvent可如何被用来开启TPL提供者且配置332采样以每100次请求开始事件222被激活时发生

以下代码展示了将如何使用ConstructionException来检查异常。

有人可能问：在为请求传递单个GUID对于工具而言更简单且在运行时发出更少事件的情况下，为何此实现为每个线程转换创建活动ID。然而，此方法牺牲了一点性能来使该特征更有用且对应用更一般地可用。使用单一活动ID 意味着开发者在其应用的逻辑执行点显式地创建活动ID。此外，在应用中可能存在想要将执行单元标识为唯一活动且将必须协作的多个组件。此处的设计对开发者是透明的，并取决于人们希望做的分析的类型，将允许人们在事实之后决定活动何处开始和结束。这可设计工具/剖析出售商的更多复杂性，然而这可通过提供基于开始和停止事件的配置来重写活动ID到逻辑活动的代码来简单化。

结语

虽然具体实施例在此处被明确示出并描述为进程、已配置的介质、或系统，但是可以理解，对一种类型的实施例的讨论也一般性地延伸到其他实施例类型。例如，结合图3对过程的描述也帮助描述已配置的介质，并帮助描述类似于结合其他附图所讨论的那些的系统和产品的技术效果和操作。对一个实施例的限制也不一定适用于另一个实施例。具体而言，进程不一定仅限于在讨论诸如已配置的存储器之类的系统或产品时呈现的数据结构和方案。

本文对具有某一特征X的实施例的引用以及本文别处对具有某一特征Y 的实施例的应用不从具有特征X和特征Y两者的本公开的实施例中排除，除非这一排除在此被明确指明。术语“实施例”在此仅仅被用作“过程、系统、制品、经配置的计算机可读介质和/或此处如以与适用法律一致的方式应用的教导的其它示例”的更方便的形式。因此，给定“实施例”在该实施例与至少一个权利要求一致的情况下可包括此处所公开的特征的任何组合。

不是图中所示出的每一项都需要存在于每个实施例中。相反，实施例可以包含图中未显式地示出的项。虽然一些可能性在此处通过具体示例在文本和附图中示出，但是各实施例可以偏离这些示例。例如，一示例的具体技术效果或技术特征可以被省略、重命名、以不同的方式分组、重复、不同地以硬件和/ 或软件实例化，或是在两个或更多示例中出现的效果或特征的混合。在一些实施例中，在一个位置示出的功能也可以在不同位置提供；技术人员认识到在给定实现中功能模块能够以各种方式定义，而不必从作为一个整体来看的交互模块的集合中省略所需技术效果

通过附图标记参考了附图。在附图或文本中与给定附图标记相关联的措词中的任何显而易见的不一致性应该被理解为仅仅时拓宽该标记所引用的内容的范围。即使使用相同的附图标记，给定附图标记的不同实例也可以指不同的实施例。

如此处所使用的，诸如“一”和“该”等术语包括了所指示的项或步骤中的一个或多个。具体而言，在权利要求书中，对一个项的引用一般表示至少一个这样的项存在，并且对一个步骤的引用表示执行该步骤的至少一个实例。

标题仅是为了方便；关于给定话题的信息可在其标题指示该话题的章节之外被寻找到。

所提交的所有权利要求和摘要是说明书的一部分。

尽管在附图中示出并在上文中描述了示例性实施例，但本领域普通技术人员将明白，可作出多种修改而不脱离权利要求书中阐明的原理和概念，且这些修改不需要涵盖整个抽象概念。尽管用结构特征和/或过程动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于权利要求书上面所描述的具体特征或动作。不一定在给定定义或示例中标识的每一个手段或方面或技术效果都在每个实施例中存在或使用。相反，所描述的具体特征和动作以及效果是作为供当实现权利要求书时考虑的示例来公开的。

无法包围整个抽象概念但落入权利要求的等效技术方案的意义和范围内的所有改变都在法律所准许的最大程度内被包含在其范围内。

Claims

1.一种被配置用于诊断数据的基于活动的采样的计算机系统，所述系统包括：

至少一个处理器；

与所述处理器操作地通信的存储器；以及

驻留在所述存储器中并定义事件的事件定义的集合；

驻留在所述存储器中并具有被配置成调用至少一个日志事件规程的应用代码的应用；

当前活动id，所述当前活动id指定所述应用的活动是否当前被指明，以及在某个活动当前被指明时还指定哪个活动当前被指明；以及

驻留于所述存储器中并具有记录器代码的记录器，所述记录器代码被配置成将线程id与活动id相关联并与所述处理器和存储器交互以检查指定记录条件的集合并在至少一个指定记录条件被满足时响应于日志事件规程的调用而向日志发送日志条目；

所述记录器包括启用日志的活动的集合，并且还包括具有相应的采样频率条件的一个或多个开始事件的集合，每个开始事件还是在所述事件定义的集合中定义的事件；

所述指定记录条件包括(a)第一条件，所述第一条件指定所述当前活动id存在于所述启用日志的活动的集合中，以及还包括(b)第二条件，所述第二条件指定所述当前活动id不存在于所述启用日志的活动的集合中，所述日志事件规程标识开始事件，以及所述日志事件规程的调用与所述开始事件的采样频率条件相一致；以及

子活动规程调用，所述子活动规程调用被配置成通知所述记录器当前活动正创建子活动，且其中记录器代码被配置成响应于所述子活动规程调用自动向所述启用日志的活动的集合添加所述子活动。

2.如权利要求1所述的系统，其特征在于，所述一个或多个开始事件采样频率条件的集合包括以下至少一者：

指定所述日志事件规程的调用是对具有每N次日志事件规程调用一个日志条目的采样频率的开始事件的第N次记录尝试的采样频率条件；

指定在指定时间段内已存在少于M个的开始事件的采样频率条件。

3.如权利要求1所述的系统，其特征在于，所述应用是多线程应用，且所述系统进一步包括当前线程id以及至少一个日志条目，所述当前线程id标识在所述应用的执行期间所述应用的当前执行线程，所述至少一个日志条目包含所述日志条目的创建时的所述当前线程id。

4.一种用于计算系统中的诊断数据的基于活动的采样的方法，所述方法包括以下步骤：

用代表启用日志的活动的集合的数据以及用代表具有相应采样频率条件的开始事件的集合的数据来配置记录器；

在所述记录器中注释将线程id与活动id相关联的数据，所述线程id标识所述计算系统的线程，所述活动id标识至少部分由所标识的相关联线程执行的活动；

在所述记录器中接收由调用线程对日志事件规程调用的指示，所述指示指定一事件；

确定在所述启用日志的活动的集合中表示的任何活动是否当前是所述调用线程的活动；

如果所述启用日志的活动的集合中表示的任何活动当前是所述调用线程的活动，则将所述事件记录在所述计算系统的诊断数据日志中；

如果所述启用日志的活动的集合中表示的活动当前均不是所述调用线程的活动但是所述事件为开始事件且所述日志事件规程的调用满足所述开始事件的采样频率条件，则将所述事件记录在所述计算系统的所述诊断数据日志中且还将所述调用线程的所述活动添加到所述启用日志的活动的集合；以及

自动向所述启用日志的活动的集合添加处于所述启用日志的活动的集合中的父活动的子活动，所述添加步骤响应于接收所述子活动是所述父活动的子的指示同时所述父活动处于所述启用日志的活动的集合中而被执行。

5.如权利要求4所述的方法，其特征在于，所述方法进一步包括提供定义事件的事件定义的集合，所述提供步骤向驻留于所述计算系统中的存储器中的以下组件中的至少一个组件提供所述事件定义：应用、所述记录器、日志消费器；并且其中所述事件定义指定所述事件中的至少一个事件的细节水平。

6.如权利要求4所述的方法，其特征在于，所述方法进一步包括响应于以下的至少一者来停止对特定活动的记录：看到停止记录事件、在先前看到开始事件已触发了对所述活动的记录之后再次在启用日志的活动上看到开始事件。

7.如权利要求4所述的方法，其特征在于，所述方法进一步包括：

响应于以下的至少一者中的设置活动id规程调用来设置当前活动id：在所述计算系统中的应用、包括支持所述应用的运行时的框架；以及

其中所述当前活动id指定所述应用的任何活动是否当前被指明为要被记录，且当某个活动当前被指明时还指定哪个活动当前被指明。

8.如权利要求4所述的方法，其特征在于，所述方法包括将此处表示为线程1的线程id与此处表示为活动1的活动id相关联，在所述记录器中接收线程1进行的日志事件规程调用的指示，所述指示指定此处表示为事件1的事件，且因为活动1不处于所述启用日志的活动的集合中而避免记录事件1。

9.如权利要求4所述的方法，其特征在于，所述方法包括将此处表示为线程1的线程id与此处表示为活动1的活动id相关联，在所述记录器中接收线程1进行的日志事件规程调用的指示，所述指示指定此处表示为事件3的事件，且即使事件3是开始事件也避免记录事件3，因为事件3的采样频率是每N次日志事件规程调用一个日志条目而所述日志事件规程的调用不是对事件3的第N次记录尝试。

10.一种具有指令的计算机可读存储介质，所述指令被执行时使得一机器执行权利要求4-9中任一的方法。

11.一种计算机系统，包括用于执行权利要求4-9中任一的方法的装置。