User interface for selecting tracing origins for aggregating classes of trace data

Abstract

A tracing system may define an origin for consolidating and comparing trace paths within a traced application. A tracer may define an identifier that may be passed through a tracing route, and the identifier may be defined to capture specific instances or groups of instances of traces. The traces may be consolidated into a graphical representation of the program flow. The identifier may be passed across various boundaries, including function boundaries, library boundaries, application boundaries, device boundaries. An analysis system may consolidate or aggregate trace results having the same identifier, and may render such data graphically or provide statistics using the identified datasets.

Description

BACKGROUND

Tracing is a mechanism for monitoring the operations and sometimes performance of an application as it executes. When an application executes under production or artificial loads, the application may execute many different sequences or paths through the executable code, and may generate large amounts of tracer data.

SUMMARY

A tracing system may define an origin for consolidating and comparing trace paths within a traced application. A tracer may define an identifier that may be passed through a tracing route, and the identifier may be defined to capture specific instances or groups of instances of traces. The traces may be consolidated into a graphical representation of the program flow. The identifier may be passed across various boundaries, including function boundaries, library boundaries, application boundaries, device boundaries. An analysis system may consolidate or aggregate trace results having the same identifier, and may render such data graphically or provide statistics using the identified datasets.

A user interface may select a location within a graphical representation of an application's structure to identify an origin for tracing operations. The origin may define a location where identifiers may be inserted into a traced application, and the identifiers may be associated with tracer data collected under certain conditions. A set of rules may define certain conditions for tracing the application, and such rules may contain logic for assigning identifiers. The user interface may be a graphical depiction of an application's flow, and a user may select from a set of predefined options to define how tracing may be implemented.

A tracing system may add identifiers to tracing paths to identify which operations to collect data, such that those tracing operations where the identifier is present may collect data and those without an identifier may collect limited or no data. The identifiers may be added using a logic that may cause the tracing system to sample operations of an application, as opposed to tracing all operations. The sampling algorithm may be a general sampling algorithm where a certain percentage of operations may be traced, or may be targeted to tracing some execution paths at a higher rate than other execution paths. In some cases, the sampling algorithm may be defined by analyzing previous tracer data to identify those execution paths that are of interest for higher levels of tracing and other execution paths to which a lower sampling rate may be applicable.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings,

FIG. 1 is a diagram illustration of an embodiment showing topology graphs with and without execution path tracing enabled.

FIG. 2 is a diagram illustration of an embodiment showing a network environment with devices that may trace using execution path tracing.

FIG. 3 is a diagram illustration of an embodiment showing an example user interface for creating rules for execution path tracing.

FIG. 4 is a flowchart illustration of an embodiment showing a method for tracing with rules.

FIG. 5 is a flowchart illustration of an embodiment showing a method for creating rules from topology graph visualizations.

FIG. 6 is a flowchart illustration of an embodiment showing a method for sampling execution path traces.

DETAILED DESCRIPTION

Application Execution Path Tracing with Configurable Origin Definition

A computer software tracing system may be configurable to trace individual execution paths. An origin point may define a location within an application where a set of identifiers may be defined for tracing execution paths. At the origin, a tracer may create identifiers that may be passed throughout an execution path by a tracer. The tracer may create a tracer dataset having a common identifier, from which statistics, visualizations, and other analyses of the tracer data may occur.

The identifiers may be defined by a set of rules that may be evaluated at a point within an application. In some embodiments, the set of rules may be defined for different functions, libraries, modules, reusable software components, interfaces, events, or other situation. When evaluated, the identifiers may classify tracing paths with unique identifiers or for identifiers that may represent a class or group of tracing paths.

In one use case, an identifier may be added to trace data for an input to a web service. In the example use case, the web server may respond to requests for web pages or other data across a network interface. A tracer may be implemented to gather performance and operational data as each function executes within the web server application. A set of rules may be evaluated at the incoming web requests to identify each incoming request with the session identifier for a particular user. As the tracer operates, the session identifier may be associated with each data item. A subsequent trace data analyzer may aggregate the trace data with each session identifier to show statistics for each session independently.

In the example use case, the set of rules may be modified to create an identifier for a specific class of input, such as creating an identifier for a specific web page request. Each instance of the web page request may have the same identifier, such that a subsequent trace data analyzer may aggregate trace data for all requests of each specific web page. Statistics, visualizations, or other output may be generated for how the web server responded to the various web pages.

User Interface for Selecting Tracing Origins for Aggregating Classes of Trace Data

A user interface may display a graphical topology of an application structure from which a tracing origin may be selected. A topology may show functions, libraries, modules, or other components of an application from which a user may select. After selecting a component, a user may be able to define logic for aggregating trace data that may flow from the selected component.

The user interface may illustrate an application's topology from trace data gathered by observing the operations of the application. The illustration may show application components as nodes in a graph, with edges of the graph illustrating connections between the components. In some cases, such illustrations may include representations of performance data.

A user may select a component from a graph, then be able to define how trace data may be aggregated for downstream operations. At the origin, the tracer may create identifiers that may be passed along the execution path. Subsequent analyses may aggregate the commonly labeled trace data into statistics, graphical representations, or other analyses.

The user may be able to select from a set of input values received by a function as an option for aggregating trace data. The set of input values may be observed by a tracer over time, then sorted and listed to the user as possible options for tracing. In some cases, the user may be able to select individual input value, groups of input values, or other each of the input values for tracing. The subsequent tracing data may be aggregated and presented to the user according to the selected options.

The user may be presented with other options for classifying and aggregating downstream trace data. Such options may be generated by analyzing previously gathered trace data to classify the downstream behavior of the application. The classifications may identify those execution paths or conditions where excessive errors occur, for example, or where other conditions may exist. Such options may allow a user to configure a tracer to collect trace data of interest while possibly not tracing conditions that may yield little or no interesting data.

Tracing Origin Rules for Minimizing Trace Data Collection by Sampling

A tracing system may have rules for labeling or identifying trace datasets, and such rules may define a sampling mechanism for tracing. By sampling the operations of an application, overhead effects of a tracer may be minimized in a production application. The sampling may be applied at different levels, based on a set of conditions defined in a set of rules for an origin point. The rules may define conditions for low frequency sampling, such as sampling one time out of 10, 100, or 1000, and other conditions for higher sampling frequencies.

The sampling may selectively identify execution sequences to trace and following those execution sequences to completion. Such sampling may more accurately reflect the operations of an application than separately sampling trace data from individual function within an application.

Sampling trace data may be useful in production situations where many operations of an application may be repetitive. Sampled trace data may be useful to identify trends in the operation of an application. Such trends may be identified with nearly the same statistical accuracy on sampled data as with a complete set of data, however, sampled data consumes less tracer overhead, trace data storage, and analyses.

In some embodiments, the sampling rate may be adjusted over time as trace data becomes more stable. For functions that are well behaved, the sampling frequency may be decreased, while functions with poor reliability may be increased. In some embodiments, sampling frequency may be increased when an error or other abnormality may be detected. Such increased sampling frequency may provide more accurate data to identify conditions where an error or abnormality occurred.

Throughout this specification and claims, the term “component” is used to define a group of reusable code that may be incorporated into an application. A component may be known as a ‘module’, ‘library’, ‘subroutine’, or some other notion. For the purposes of this specification and claims, these terms are considered synonymous.

The “component” may be code that is arranged in a way that multiple applications may access the code, even though the applications may have no connection with each other. In general, a “component” may be code that is configured to be reused. In some cases, a component may be reused within the scope of a large application, while in other cases, the component may be shared to other application developers who may use the component in disparate and unconnected applications.

Many programming languages and paradigms have a notion of a “component” or library, where the component may have a defined interface through which an application may invoke and use the component. Some paradigms may allow a programmer to incorporate a component in a static manner, such that the component code does not further change after the application is written and deployed. Some paradigms may allow for dynamic libraries, which may be loaded and invoked at runtime or even after execution has begun. The dynamic libraries may be updated and changed after the application may have been distributed, yet the manner of invoking the libraries or components may remain the same.

Components may be distributed in source code, intermediate code, executable code, or in some other form. In some cases, components may be services that may be invoked through an application programming interface.

Throughout this specification and claims, the term “component” may be applied to a single reusable function. Such a function may be distributed as part of a library, module, or other set of code, and may reflect the smallest element of reusable code that may be distributed. A single “component” as referenced in this specification and claims may be an individual application programming interface call or callable subroutine or function, as well as a module, library, or other aggregation of multiple callable functions, application programming interface calls, or other smaller elements.

Throughout this specification and claims, the terms “profiler”, “tracer”, and “instrumentation” are used interchangeably. These terms refer to any mechanism that may collect data when an application is executed. In a classic definition, “instrumentation” may refer to stubs, hooks, or other data collection mechanisms that may be inserted into executable code and thereby change the executable code, whereas “profiler” or “tracer” may classically refer to data collection mechanisms that may not change the executable code. The use of any of these terms and their derivatives may implicate or imply the other. For example, data collection using a “tracer” may be performed using non-contact data collection in the classic sense of a “tracer” as well as data collection using the classic definition of “instrumentation” where the executable code may be changed. Similarly, data collected through “instrumentation” may include data collection using non-contact data collection mechanisms.

Further, data collected through “profiling”, “tracing”, and “instrumentation” may include any type of data that may be collected, including performance related data such as processing times, throughput, performance counters, and the like. The collected data may include function names, parameters passed, memory object names and contents, messages passed, message contents, registry settings, register contents, error flags, interrupts, or any other parameter or other collectable data regarding an application being traced. The collected data may also include cache misses, garbage collection operations, memory allocation calls, page misses, and other parameters.

Throughout this specification and claims, the term “execution environment” may be used to refer to any type of supporting software used to execute an application. An example of an execution environment is an operating system. In some illustrations, an “execution environment” may be shown separately from an operating system. This may be to illustrate a virtual machine, such as a process virtual machine, that provides various support functions for an application. In other embodiments, a virtual machine may be a system virtual machine that may include its own internal operating system and may simulate an entire computer system. Throughout this specification and claims, the term “execution environment” includes operating systems and other systems that may or may not have readily identifiable “virtual machines” or other supporting software.

Throughout this specification and claims, the term “application” is used to refer to any combination of software and hardware products that may perform a desired function. In some cases, an application may be a single software program that operates with a hardware platform. Some applications may use multiple software components, each of which may be written in a different language or may execute within different hardware or software execution environments. In some cases, such applications may be dispersed across multiple devices and may use software and hardware components that may be connected by a network or other communications system.

Throughout this specification, like reference numbers signify the same elements throughout the description of the figures.

In the specification and claims, references to “a processor” include multiple processors. In some cases, a process that may be performed by “a processor” may be actually performed by multiple processors on the same device or on different devices. For the purposes of this specification and claims, any reference to “a processor” shall include multiple processors, which may be on the same device or different devices, unless expressly specified otherwise.

When elements are referred to as being “connected” or “coupled,” the elements can be directly connected or coupled together or one or more intervening elements may also be present. In contrast, when elements are referred to as being “directly connected” or “directly coupled,” there are no intervening elements present.

The subject matter may be embodied as devices, systems, methods, and/or computer program products. Accordingly, some or all of the subject matter may be embodied in hardware and/or in software (including firmware, resident software, micro-code, state machines, gate arrays, etc.) Furthermore, the subject matter may take the form of a computer program product on a computer-usable or computer-readable storage medium having computer-usable or computer-readable program code embodied in the medium for use by or in connection with an instruction execution system. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media.

Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by an instruction execution system. Note that the computer-usable or computer-readable medium could be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, of otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.

When the subject matter is embodied in the general context of computer-executable instructions, the embodiment may comprise program modules, executed by one or more systems, computers, or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.

FIG. 1 is an illustration of an embodiment 100 showing topology graphs before and after classification of execution paths. A general topology graph 102 may show an application's components and their connections, where each connection may be an observed connection from tracer data. A topology graph 104 may show the connections after applying execution path tracing.

Execution path tracing may begin at an origin location within an application and may create identifiers for the execution paths. The identifiers may be passed along the execution path so that tracer data may be identified with the execution path. Tracing data with the same execution path identifiers may be grouped and displayed on a topology graph.

The execution path identifiers may be unique identifiers for each instance of the execution path. In such embodiments, every traversal through the application code may have a different identifier and thus each path may be separately stored, analyzed, and visualized.

The execution path identifiers may have an identifier for specific classes of execution paths. In such embodiments, the trace data from a given execution path may be consolidated and analyzed as a group.

Execution path tracing may allow certain portions of an application to be observed. At an origin location within the application, a tracer may create identifiers for execution paths, then pass the identifiers along the execution path, collecting tracer data along the way. The tracer data may be labeled with the identifier, then the data with the same identifiers may be analyzed as a group.

In one use case, a specific execution path may be identified as starting at a specific function. When tracing the function, a set of tracer rules may be evaluated to determine if the current execution path fits the definition of an execution path of interest. The tracer may create an identifier for the execution path, then begin tracing the function. As the execution continues, the identifier may be passed to subsequent functions in the execution path. At each downstream function, a tracer may detect the presence of the identifier, then trace the downstream function and label the data. The resulting data may reflect the trace of just the execution path of interest, without other trace data. Such resulting data may be analyzed, visualized, or otherwise processed to give a developer a detailed look at the specific execution path.

In another use scenario, an application may function in several distinct modes, but may use overlapping sets of functions to deliver each of the modes. The application may be traced by identifying a function where the modes may originate, then creating identifiers for each execution path. A tracer may make an evaluation at the origin function to determine the execution path, then label each execution path.

In one example of such a scenario, a website server application may respond to requests for various web pages. Each web page may have different functionality, but may generally use many of the same downstream functions. An origin function may be a function where webpage requests are received, and a tracer may label each execution path with the label of the webpage being requested. After executing a tracer in such a configuration, the tracer data for each webpage may be readily identified and studied.

Embodiment 100 illustrates one such change in topology when execution path labeling is used. Graph 102 may illustrate a complete topology graph of an application, where each node may represent a function or block of executable code, and each edge may represent a connection or program flow between the functions.

Node 106 is connected to node 108, which branches to nodes 110 and 112. Node 110 may loop back on itself, and may branch to nodes 113 and 118. Node 113 may branch to nodes 114 and 116, and node 114 may return to node 113. Node 112 may flow to node 118, which may loop back on itself, then branch to nodes 120 and 122. Node 122 may continue to node 116.

The topology of graph 102 may reflect the complete topology of an application. However, the application may have three major functions, which may originate at node 108. When execution path tracing is deployed at node 108, each mode of node 108 may start a new execution path, which may be traced using an identifier for the corresponding execution path.

In graph 104, the topology graph may be shown with the execution paths. The graph may begin with node 106. Because node 108 is an origin node and may operate in three distinct modes, the execution paths for the three modes may be labeled and displayed. The execution paths 124, 126, and 128 may illustrate such modes.

Execution path 124 contains node 108 in the first condition, then nodes 110, 113, and 114. Execution path 126 contains node 108 in the second condition, the nodes 110, 118, and 122. Lastly, execution path 128 contains node 108 in the third condition, then nodes 112, 118, and 120.

Graph 104 may illustrate the topology of an application in a more understandable way than graph 102. Graph 102 may illustrate all of the connections between various software elements, but graph 104 illustrates the execution flow of the application in its modes of operation. Such an illustration may be more useful to visualize the actual operation of an application.

FIG. 2 is a diagram of an embodiment 200 showing components that may collect data when an application executes by using tracer rules that may change tracer behavior, including adding execution path identifiers.

The diagram of FIG. 2 illustrates functional components of a system. In some cases, the component may be a hardware component, a software component, or a combination of hardware and software. Some of the components may be application level software, while other components may be execution environment level components. In some cases, the connection of one component to another may be a close connection where two or more components are operating on a single hardware platform. In other cases, the connections may be made over network connections spanning long distances. Each embodiment may use different hardware, software, and interconnection architectures to achieve the functions described.

Embodiment 200 illustrates a device 202 that may have a hardware platform 204 and various software components. The device 202 as illustrated represents a conventional computing device, although other embodiments may have different configurations, architectures, or components.

In many embodiments, the device 202 may be a server computer. In some embodiments, the device 202 may still also be a desktop computer, laptop computer, netbook computer, tablet or slate computer, wireless handset, cellular telephone, game console or any other type of computing device. In some embodiments, the device 202 may be implemented on a cluster of computing devices, which may be a group of physical or virtual machines.

The hardware platform 204 may include a processor 208, random access memory 210, and nonvolatile storage 212. The hardware platform 204 may also include a user interface 214 and network interface 216.

The random access memory 210 may be storage that contains data objects and executable code that can be quickly accessed by the processors 208. In many embodiments, the random access memory 210 may have a high-speed bus connecting the memory 210 to the processors 208.

The nonvolatile storage 212 may be storage that persists after the device 202 is shut down. The nonvolatile storage 212 may be any type of storage device, including hard disk, solid state memory devices, magnetic tape, optical storage, or other type of storage. The nonvolatile storage 212 may be read only or read/write capable. In some embodiments, the nonvolatile storage 212 may be cloud based, network storage, or other storage that may be accessed over a network connection.

The user interface 214 may be any type of hardware capable of displaying output and receiving input from a user. In many cases, the output display may be a graphical display monitor, although output devices may include lights and other visual output, audio output, kinetic actuator output, as well as other output devices. Conventional input devices may include keyboards and pointing devices such as a mouse, stylus, trackball, or other pointing device. Other input devices may include various sensors, including biometric input devices, audio and video input devices, and other sensors.

The network interface 216 may be any type of connection to another computer. In many embodiments, the network interface 216 may be a wired Ethernet connection. Other embodiments may include wired or wireless connections over various communication protocols.

The software components 206 may include an operating system 218 on which various software components and services may operate. Some embodiments may execute applications directly on the operating system 218, while other embodiments may use an execution environment 224, which may be a virtual machine or other abstraction. When applications execute on the operating system 218, a tracer 220 may have some operating system connections. The tracer 220 may execute with a set of rules 222 which may control the tracer behavior.

When applications execute in an execution environment 224, the application 226 may operate with a tracer 228 which may have a set of rules 230 that may control tracer behavior.

The rules 222 or 230 may define settings or options for the tracer, and may identify conditions for changing the tracer settings. In some cases, the rules may increase or decrease the amount of data being collected. Some such rules may identify specific types of data to collect, variable values to capture, performance or operational data that may be collected, or other behavioral changes.

The rules may also identify execution paths for tracing. The execution paths may be sequences of application operations that may be sequentially related to each other. Some execution paths may be sequential, while other execution paths may branch into multiple processes, threads, or other sequences of execution which may execute in parallel.

The execution paths may be traced by creating an identifier for the execution path, then passing the identifier through the execution path to downstream functions. One mechanism for transmitting such an identifier may be to wrap an origin function in a tracer function, and the wrapper may pass the identifier as state within the wrapper. Many other implementation mechanisms may be used to trace an execution path and apply an identifier to the trace data.

A network 234 may connect various devices in the example of embodiment 200. In other embodiments, all of the various functions may be implemented on a single hardware platform, while in still other embodiments, some of the various functions may be distributed on multiple hardware platforms.

A trace database system 236 may collect trace data, perform analysis of trace data, generate tracing rules, and provide visualizations of the trace data. The trace database system 236 may execute on a hardware platform 238, which may be similar to the description of hardware platform 204.

A trace database 240 may collect trace data created on the device 202. The trace database 240 may receive, store, and process trace data for analysis.

An analysis engine 242 may perform statistical and other analyses of the trade data, including generating visualizations 246 of the trace data, such as topology graphs and other visualizations.

The analysis engine 242 may assist in creating rules 244 for a tracer. The analysis engine 242 may identify statistics, modes of operation, or other information that may be used by a human to select rules from which execution paths may be traced. In some cases, the analysis engine 242 may include a set of heuristics or other mechanisms to determine conditions for sampling the traces performed on an execution path.

The rules 222 and 230 may identify execution paths that may be traced by sampling the execution paths. Sampling may not trace every instance of an execution path, but may trace only a subset of instances. Sampling may be useful to reduce the overhead consumed by a tracer, but may still yield statistically significant results.

Sampling may be applied with different frequencies based on the execution path. For example, an execution path that is very stable may have a low level of sampling, while an execution path with wide performance variability may be sampled at a high frequency. Such a system may capture larger sets of data for execution paths that may be poorly behaved while capturing less data for those execution paths that may be well behaved.

The analysis engine 242 may examine the trace database 240 to determine which execution paths may be well behaved and which may be poorly behaved. Based on the performance of the various execution paths, the analysis engine 242 may create rules 244 which may increase or decrease tracing sampling of the execution paths.

A client device 248 may be a device from which a user may view various visualizations 246 and may interact with the analysis engine 242, trace database 240, and create rules 244, among other things. The client device 248 may operate on a hardware platform 250, which may be similar to that described for the hardware platform 204.

The client device 248 may have a browser 252 in which a user interface 254 may be displayed. The user interface 254 may be served from a webserver that may access the trace database 240, analysis engine 242, rules 244, visualizations 246, and other information.

FIG. 3 is diagram illustration of an example embodiment 300 showing an application topology graph 302 and a mechanism for selecting rules for execution path tracing. Embodiment 300 is merely one example of an interactive mechanism for soliciting input from a user from which tracer rules may be generated.

The user interface may have an application topology graph 302 which may illustrate elements of an application and the flow between those elements. Each node may represent an application or other executable component, event, interface, element, or other item.

A user may be able to select a specific node, such as the selected node 304. When the node 304 may be selected, a user interface 306 may be presented to the user. The user interface 306 may present some information to a user that may be assist in creating rules for tracing execution paths.

The user interface 306 may show a function's name 308, as well as some analyzed data for possible execution paths. In the example of embodiment 300, three different input values may be illustrated in column 310 as “foo”, “bar”, and “baz”. Various statistics may be shown for the user for each input value, such as usage frequency in column 312, errors in column 314, and performance 316.

The suggested classifications for execution paths may be determined by analyzing tracing data previously collected for a given node. Such analysis may attempt to determine which variables may be dominant factors that may differentiate the behavior of different execution paths.

A user may have input mechanisms 318, 320, and 322 that may capture a user's input, which may be processed to generate tracer rules. In the example of embodiment 300, a user may have options to select between low, medium, and high levels of tracing. Each embodiment may have different definitions for such designators. In some cases, such terms may refer to the sampling frequency. In some cases, such terms may reflect the amount of data collected at each event that may be traced.

FIG. 4 is a flowchart illustration of an embodiment 400 showing a method for tracing with rules. Embodiment 400 may illustrate a system where rules may be applied at each function where tracing may occur. The rules may change the tracer behavior by adding or removing parameters to capture, performing analysis at a tracing event, and other items. In some cases, the rules may include executable code that may be evaluated during tracing.

Other embodiments may use different sequencing, additional or fewer steps, and different nomenclature or terminology to accomplish similar functions. In some embodiments, various operations or set of operations may be performed in parallel with other operations, either in a synchronous or asynchronous manner. The steps selected here were chosen to illustrate some principles of operations in a simplified form.

Embodiment 400 may illustrate one mechanism for deploying execution path tracing using tracer rules. The tracer rules may contain one or more conditions under which execution path tracing may occur, as well as a mechanism for identifying the execution paths. When the execution path at a given function matches the conditions for execution path tracing, the execution path may be identified. An identifier may be passed downstream to other functions, which may identify tracer data with the same identifier, thereby linking trace data into the same execution path.

Execution of an application may begin in block 402 and tracing may begin in block 404. The tracer rules may be received in block 406.

A function to trace may be identified in block 408. The function to be traced may be identified when the application execution has proceeded to the function and the function is identified by the tracer.

If no rules are defined for the function in block 410, the tracer may be set to default rules in block 412. If rules are defined for the function in block 410, the tracer may be configured according to the rules in block 414.

If the rules do not define execution path tracing in block 416, the function may be traced in block 426 with the tracer as configured.

When the rules do define execution path tracing in block 416, the function state may be evaluated in block 418 to classify the execution path. Based on the classification, an identifier may be retrieved in block 420. The function may be wrapped in a tracer function in block 422 and the identifier may be included in the wrapped tracer in block 424. The process may continue to block 426 to trace the function and gather trace data.

If an identifier is defined for the trace data in block 428, the trace data gathered by the tracing in block 426 may be associated with the identifier in block 430 and stored in block 432. The process may return to block 408 to continue execution until another function may be identified for tracing.

On downstream functions that may or may not have tracer rules defined, the tracer may continue to gather trace data in block 426 and associate identifiers with the trace data.

FIG. 5 is a flowchart illustration of an embodiment 500 showing a method for creating rules from a topology graph representation. Embodiment 500 may illustrate a method that may be performed by an analysis engine and user interface to generate useful data that may assist a user in selecting execution paths for tracing.

Other embodiments may use different sequencing, additional or fewer steps, and different nomenclature or terminology to accomplish similar functions. In some embodiments, various operations or set of operations may be performed in parallel with other operations, either in a synchronous or asynchronous manner. The steps selected here were chosen to illustrate some principles of operations in a simplified form.

Trace data may be received in block 502.

A graph of traced components may be generated in block 504 from the trace data, and a topology visualization may be generated from the graph in block 506.

The topology visualization may be displayed in block 508. A selection of an application component may be received in block 510. The selection may be made by a user viewing the topology visualization.

When a user wishes to create a new rule or update an existing rule relating to the selected component in block 512, a user interface with classification options may be presented in block 514.

The user interface with classification options may include modes of operation that may be derived from the tracer data by an analysis engine. In many embodiments, a set of heuristics may be applied to suggest common factors from which execution paths may be classified. An example of such a user interface may be the user interface 306 of embodiment 300.

A user may also be able to specify the sampling desired for a given execution path in block 516.

A set of classification options may be received from the user in block 516 and a set of rules may be created in block 518. If another component may be selected in block 520, the process may return to block 508. When no other components are selected in block 520, the process may end in block 522.

FIG. 6 is a flowchart illustration of an embodiment 600 showing a method for tracing with rules that include sampling. Embodiment 600 may illustrate operations of a tracer that may sample certain execution paths. Each traced execution path may be assigned an identifier. When the identifier may be present for downstream functions, tracing may be performed, but when the identifier is not present, tracing may be minimized or not performed at all.

Other embodiments may use different sequencing, additional or fewer steps, and different nomenclature or terminology to accomplish similar functions. In some embodiments, various operations or set of operations may be performed in parallel with other operations, either in a synchronous or asynchronous manner. The steps selected here were chosen to illustrate some principles of operations in a simplified form.

Embodiment 600 may assign identifiers to execution paths when the execution path may be selected for sampling. Such a system may use the identifier as an indication that tracing may be performed on downstream functions. By assigning identifiers to only a subset of execution paths, tracing may be performed on a sample or subset of execution paths. Sampling may be one mechanism to minimize overhead effects to an application's performance while still collecting some tracing data.

Tracing may begin in block 602. The rules for tracing may be received in block 604. A function may be identified for tracing in block 606.

If the function may be an origin for execution path tracing in block 608, the execution path may be classified in block 610. The sampling frequency of the execution path may be determined in block 612, and a determination may be made as to whether or not the current execution path is to be traced in block 614.

A sampling frequency may define a percentage or other fraction of execution paths to trace. For example, a sampling frequency of 10% may trace 1 of 10 execution paths, leaving 9 of 10 execution paths without tracing.

If the current execution path is not selected for sampling in block 616, the process may proceed to block 620. If the current execution path is selected for sampling in block 616, an identifier for the execution path may be determined in block 618 and the tracer may be configured to trace the execution path. The process may continue to block 620.

If the execution path does not have an identifier in block 620, the function may not be traced in block 622 and the process may continue to block 606.

When the execution path does have an identifier in block 620, the function may be traced and trace data may be gathered in block 624. The execution path identifier may be associated with the trace data in block 626 and the data may be stored in block 628. The process may continue to block 606.

The foregoing description of the subject matter has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the subject matter to the precise form disclosed, and other modifications and variations may be possible in light of the above teachings. The embodiment was chosen and described in order to best explain the principles of the invention and its practical application to thereby enable others skilled in the art to best utilize the invention in various embodiments and various modifications as are suited to the particular use contemplated. It is intended that the appended claims be construed to include other alternative embodiments except insofar as limited by the prior art.

Claims

1. A method performed on at least one processor, said method comprising: receiving trace data of an application, said application comprising a plurality of components;analyzing said trace data of said application to generate a first topology graph of said application, said first topology graph of said application comprising representations of said plurality of components;displaying said first topology graph of said application in an interactive user interface;receiving a first selection from a user input device, said first selection comprising a first component within said first topology graph of said application;receiving a second selection from said user input device, said second selection comprising a first condition for tracing execution paths passing through said first component within said first topology graph of said application; andcreating a tracer rule associated with said first component within said first topology graph of said application to store said first condition for tracing said execution paths passing through said first component within said first topology graph of said application.

2. The method of claim 1, said first topology graph of said application being generated from trace data gathered by monitoring said application and identifying said plurality of components within said trace data.

3. The method of claim 2 further comprising: displaying a second topology graph of said application in said interactive user interface, said second topology graph comprising trace data organized at least in part by said tracer rule.

4. The method of claim 3, said tracer rule being consumed by a tracer to classify at least one execution path of said application.

5. The method of claim 4, said tracer rule being consumed by a tracer to classify execution paths into a plurality of classifications.

6. The method of claim 1 further comprising: presenting a user selection interface comprising a plurality of classification suggestions, said second selection from said user input device being selected from said plurality of classification suggestions.

7. The method of claim 6 further comprising: analyzing tracer data for said application to determine a plurality of input values for said first component within said first topology graph of said application; andpresenting at least a subset of said plurality of input values as said plurality of classification suggestions.

8. The method of claim 6 further comprising: analyzing tracer data for said application to determine a plurality of execution paths organized by frequency of use; andpresenting at least a subset of said plurality of execution paths as said plurality of classification suggestions.

9. The method of claim 6 further comprising: analyzing tracer data for said application to determine a plurality of execution paths organized by errors detected; andpresenting at least a subset of said plurality of execution paths as said plurality of classification suggestions.

10. The method of claim 6 further comprising: analyzing tracer data for said application to determine a plurality of execution paths organized by a performance metric; andpresenting at least a subset of said plurality of execution paths as said plurality of classification suggestions.

11. A system comprising: at least one processor;a trace database comprising trace data gathered from tracing an application;an analysis engine that: receives trace data of said application, said application comprising a plurality of components; andanalyzes said trace data of said application to generate a first topology graph of said application, said first topology graph of said application comprising representations of said plurality of components; andan interactive user interface presented on a device comprising said at least one processor, said interactive user interface that: displays said first topology graph of said application;receives a first selection from a user input device, said first selection comprising a first component within said first topology graph of said application;receives a second selection from said user input device, said second selection comprising a first condition for tracing execution paths passing through said first component within said first topology graph of said application; andcreates a tracer rule associated with said first component within said first topology graph of said application to store said first condition for tracing said execution paths passing through said first component within said first topology graph of said application.

12. The system of claim 11, said interactive user interface that further: presents a user selection interface comprising a plurality of classification suggestions, said second selection from said user input device being selected from said plurality of classification suggestions.

13. The system of claim 12, said analysis engine that further: analyzes tracer data for said application to determine a plurality of input values for said first component within said first topology graph of said application;said interactive user interface that further: presents at least a subset of said plurality of input values as said plurality of classification suggestions.

14. The system of claim 13, said analysis engine that further determines said plurality of input values from a plurality of execution paths classified by frequency of use.

15. The system of claim 13, said analysis engine that further determines said plurality of input values from a plurality of execution paths classified by errors detected.

16. The system of claim 13, said analysis engine that further determines said plurality of input values from a plurality of execution paths classified by a performance metric.