Smart distributed tracing context injection

Abstract

To automatically provide a telemetry function to an enterprise application.SOLUTION: In a method of propagating tracing across a distributed software application, an application is configured to: log tracing data for a web page from an original server; determine, on a web browser, that the web page from the original server requires a request to an external server located outside a domain of the original server; interrogate the external server to determine whether the external server allows tracing of headers in requests; update an allow list, on the web browser, to indicate that the external server allows tracing of headers in requests from the original server; inject a tracing header in the request based on a result of the interrogation; and send, from the web browser to the external server, the request including the tracing header. The external server is configured to log tracing data based on the tracing header.SELECTED DRAWING: Figure 11

Description

[Technical Field]

[0001] REFERENCE TO RELATED APPLICATIONS [Background technology]

[0002] background As web-based applications continue to evolve, traditional tracking applications no longer provide accurate telemetry data for servers, platforms, or threads. The disclosed solution overcomes these drawbacks and facilitates improved telemetry capabilities and analysis. Summary of the Invention

[0003] overview In one aspect, a method for propagating tracing throughout a distributed software application includes recording tracing data for a web page from an original server, the web page being executed by a web browser. The method further includes determining, on the web browser, that the web page from the original server requires a request to an external server located outside the domain of the original server. The method further includes searching, on the web browser, a deny list indicating whether the external server denies tracking of headers in requests from the original server. The method further includes searching, on the web browser, a permit list indicating whether the external server is permitted to track headers in requests from the original server. The method further includes determining whether the external server is permitted to track headers in requests by querying the external server. The query is based on a negative result of the deny list or permit list search. The method further includes updating, on the web browser, the permit list to indicate that the external server is permitted to track headers in requests from the original server. The method further includes inserting a tracking header into the request based on a result of the query. The method further includes sending a request including the tracking header from the web browser to an external server, the external server being configured to record the tracing data based on the tracking header.

[0004] In one aspect, the method further includes determining, on the web browser, that the web page from the original server requires an additional request to the external server. The method further includes determining that a cache includes an entry corresponding to the external server. The method further includes retrieving a response corresponding to the entry from the cache and providing the response to the additional request.

[0005] In one aspect, the method includes, in response to determining that the origin server does not implement Cross-Origin Resource Sharing (CORS), inserting a tracking header into the request; The method further includes sending a request including the header.

[0006] In one embodiment, the request is a Hypertext Transfer Protocol (HTTP) request. In one aspect, the method further includes receiving, from the external server, performance measurements for the span, the span including operations performed to service the request, the performance measurements including one or more of (i) a number of processing cycles corresponding to execution of the operations or (ii) an execution time of the operations.

[0007] In one aspect, the request to the external server is triggered by the execution of an event initiated by an interaction with the web page. The method further includes automatically recording the additional span based on the execution of the event. The span is a child span of the additional span.

[0008] In one aspect, the method further includes receiving a notification from the external server that the request was denied. The method further includes adding the external server to a denied list on the web browser. The method further includes resending the request from the web browser to the external server without the tracking header.

[0009] The above methods may be implemented as a tangible computer-readable medium and / or may operate within a computer processor and associated memory. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 illustrates an example system for automatically instrumenting enterprise applications using telemetry according to an aspect of the present disclosure. [Figure 2] FIG. 1 illustrates an example of a process used to collect telemetry data according to an aspect of the present disclosure. [Figure 3] FIG. 1 illustrates an example of an instrumented application for generating span context in accordance with certain aspects of the present disclosure. [Figure 4]FIG. 2 illustrates an example of a span hierarchy according to one aspect of the present disclosure. [Figure 5] FIG. 1 illustrates a tracing component of an instrumented application used to generate span contexts and logs in accordance with certain aspects of the present disclosure. [Figure 6] FIG. 1 illustrates an example of a tracking architecture used to manage backpressure caused by instrumentation of a span in accordance with certain aspects of the present disclosure. [Figure 7] FIG. 2 illustrates an example of a span hierarchy including priorities in accordance with certain aspects of the present disclosure. [Figure 8] FIG. 2 illustrates an example process for prioritizing spans in accordance with certain aspects of the present disclosure. [Figure 9] FIG. 1 illustrates an example of a distributed tracking environment including a tracking worker client in accordance with certain aspects of the present disclosure. [Figure 10] FIG. 2 illustrates an example process for instrumenting threads in accordance with certain aspects of the present disclosure. [Figure 11] FIG. 1 illustrates an example process for propagating traces throughout a distributed software application in accordance with certain aspects of the present disclosure. [Figure 12] FIG. 1 illustrates an example for propagating span context across services in a distributed system in accordance with certain aspects of the present disclosure. [Figure 13] FIG. 2 illustrates an example of a header in accordance with certain aspects of the present disclosure. [Figure 14] 1 is a simplified diagram illustrating a distributed system for implementing one aspect. [Figure 15] FIG. 1 is a simplified block diagram illustrating components of a system environment in which services can be provided as cloud services, according to one aspect. [Figure 16] FIG. 1 illustrates an exemplary computer system in which various aspects of the present invention may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0011] Detailed Description The technology disclosed herein provides telemetry capabilities to enterprise applications. Telemetry refers to the collection of performance reporting data about the runtime execution of software. Examples of such data include frequency of use of specific features on a web page or application, startup or execution time measurements, process crash detection, failure information, and user experience. Telemetry data can be collected on an application basis or runtime reports about the completion time of each process on a web page. It can be collected at a more granular level, such as time metrics. The disclosed solution can access telemetry data using application programmer interface (API) functionality.

[0012] As described above, existing solutions have deficiencies. For example, some existing solutions require developers to manually install or link to a tracing library and add one or more function calls to the portion of code where instrumentation data is desired. Furthermore, such solutions require developers to select instrumentation libraries from one or more vendors and configure these libraries. In contrast, the disclosed solution automatically instruments web-based applications by detecting events in the code and calls to a server and automatically instrumenting these events.

[0013] In one aspect, the disclosed system can automatically instrument enterprise applications without requiring input from software developers. Certain aspects of the present disclosure relate to software development tools for providing a runtime telemetry framework that can be automatically integrated into custom applications designed by software developers. For example, the software development tool can automatically insert tracking functionality into enterprise applications. The tracking functionality automatically tracks behaviors such as user interactions, page navigation, and server calls, and groups related logical transactions, enabling end-to-end tracking from user clicks on web pages, including distributed server systems (heterogeneous or otherwise) that implement backend services.

[0014] In another aspect, the disclosed system enables prioritization of spans and messages associated with spans to minimize network congestion potentially caused by large amounts of instrumentation data. For example, at runtime or before runtime, a particular span can be assigned a lower priority. This allows the instrumentation to not measure the performance of a particular span, but to collect data on child spans that are of greater interest to developers.

[0015] In yet another aspect, the disclosed solution enables a developer of a web-based application to obtain instrumentation details about one or more processes running as part of an enterprise application, regardless of whether the one or more processes contain multiple threads. During runtime execution of the application, a telemetry framework facilitates instrumentation of various processes, threads, and servers. In this way, the instrumentation environment is maintained across threads, resulting in more granular instrumentation data.

[0016] In another aspect, the disclosed system facilitates telemetry across distributed systems that include distributed servers that may not automatically allow instrumentation indicated by tracking headers due to security requirements or other reasons. More specifically, certain aspects can automatically discover protocol support and tailor the insertion of tracing information into different calls based on protocol support. Thus, the disclosed system can obtain detailed telemetry data for processes running on remote servers, particularly those accessed by cross-domain requests. Such servers may be operated by different entities in different domains.

[0017] FIG. 1 illustrates an example system for automatically instrumenting enterprise applications using telemetry in accordance with one aspect of the present disclosure. 1 illustrates a developer computing device 110, an end-user computing device 130, a network 150, and servers 140a-n. In the example illustrated in FIG. 1, developer computing device 110 builds an instrumented application 120 and deploys it to server 140a. Server 140a provides the application to end-user computing device 140. FIG. 2 illustrates an example of a process used by an instrumented application to obtain telemetry data. FIG. 3 illustrates an example of an instrumented application. Examples of computing devices suitable for developer computing device 110 and end-user computing device 140 include client computing devices 1402, 1404, 1406, and 1408 illustrated in FIG. 14, and an example of a suitable server includes server 1412 illustrated in FIG. 14.

[0018] During or in connection with the execution of the instrumented application 120, the end-user computing device 140 may connect to one or more servers 140b-n to obtain different resources (e.g., images, scripts, etc.) and / or to perform instrumented functions. During or after the execution of the instrumented application 120, telemetry data 122 is transmitted to the developer computing device 110 and analyzed.

[0019] Developer computing device 110 includes one or more of a developer integrated development environment (IDE) 112, developer back-end tools 114, a console 116, and telemetry data 122. Developer IDE 112 is a graphical development tool that provides compiling, linking, debugging, tracing, or other functions. Developer back-end tools 114 may include one or more compilers, linkers, debuggers, simulators, etc. Console 116 is used to view telemetry data 122 obtained by executing instrumented application 120. As shown, telemetry data 122 includes data indicating that a particular web page took 0.5 seconds to execute on "Server 1," that an image took 0.4 seconds to load on "Server 2," and that a button click caused 0.2 seconds of processing.

[0020] Servers 140a-n may be configured to perform the same, similar, or different functions. For example, servers 140a-n may operate as a distributed server system. In another example, servers 140a-n may be web servers, file servers, or other servers that can serve one or more components from a web page or that can receive database queries and provide results. In some cases, servers 140a-n may be controlled by different entities (companies or individuals) and / or located in different locations. Accordingly, certain aspects described herein relate to obtaining telemetry data from different servers via span context propagation. Developer computing device 110, end-user computing device 140, network 150, and servers 140a-n may be connected via one or more connections, such as network 150. Examples of network 150 include a wired network, a wireless network, and the Internet.

[0021] The end-user computing device 130 includes a web application 134 (e.g., a web page), a web browser 132, and a tracking application 136. The web application 134 can be rendered by the web browser 132. The tracking application 136, which can be part of the web application 134, provides instrumentation functionality. For example, the tracking application 136 can generate telemetry data that can be exported to an external device periodically or on demand. Examples of telemetry data include frequency of use of particular features, startup or execution time measurements, process crash detection, failure information, and user types.

[0022] In one example, a software developer builds a custom web-based application using a developer IDE 112 and developer back-end tools 114. Specifically, the software tools running on the developer computing device 110 insert code that provides telemetry functionality (e.g., tracking code) and generate the instrumented application 120. In some cases, the instrumented application 120 may be transmitted directly from the developer computing device 110 to the end-user computing device 140. In other cases, the instrumented application 120 may be transmitted directly to the servers 140a-n, hosted by the servers 140a-n, and downloaded by the end-user computing device 140.

[0023] The end-user computing device 140 accesses an application from, for example, server 140a via network 150. A user operating the end-user computing device 140 accesses one or more servers 140a-n by interacting with the application. One or more servers 140a-n provide all or part of the application to the end-user computing device 140. The end-user computing device 140 implements telemetry functionality, which instruments actions directly triggered by the user's interaction with the application (e.g., clicks, reloads) or indirectly triggered (e.g., by loading an image linked to a page). In this way, more detailed telemetry information can be obtained than with previous solutions. Telemetry data 122 is collected by one or more servers 140a-n.

[0024] As described above, certain aspects relate to obtaining telemetry information from an enterprise application. To facilitate telemetry, one or more spans are created in the enterprise application. As used herein, a span refers to a set of named operations that represent a unit of work. A particular span can refer to a process. A span has a span context. As used herein, a span context can include a tracking identifier and a span identifier. Thus, a first process may have a first span, and a second process may have a second span. If the second process is invoked by the first process, the first span and the second span have a parent-child relationship. That is, the first span is the parent span and the second span is the child span. Tracking spans of different processes facilitates more detailed instrumentation.

[0025] Certain figures and associated descriptions further explain certain aspects. For example, Figures 4-5 relate to different aspects of span instrumentation. Figures 6-8 relate to the prioritization of various spans during instrumentation. Figures 9 and 10 relate to instrumenting threads. Figures 11-13 relate to propagating span contexts between different devices. Figures 14-16 illustrate various computing systems in which instrumentation functionality can be implemented.

[0026] Instrumenting web-based enterprise applications 2 illustrates an example process 200 used to collect telemetry data according to one aspect of the present disclosure. Process 200 may be performed by developer computing device 110 and one or more of servers 140a-n.

[0027] In block 202, the process 200 starts a web page application on a client. The process 200 may include providing a web application 134 to a web browser on the client device. For example, server 140a provides web application 134 to web browser 132. Web application 134 includes tracking application 136 for providing instrumentation. Web application 134 has been instrumented to include tracking application 136 prior to process 200.

[0028] At block 204, process 200 includes detecting the start of a web page application. Web browser 132 begins execution of web application 134 and tracking application 136. Server 140a can detect the start of execution by determining that web browser 132 has requested one or more resources.

[0029] At block 206, the process 200 includes instantiating a tracking application 136 based on the initiation of the web page application. The tracking application 136 is configured to record tracking data for the web application 134.

[0030] At block 208, the process 200 includes detecting an event initiated by an interaction with the web page application. The web application 134 continues to run and an event is triggered. Examples of events include user interface interactions, clicks, navigation, mouse-overs, refreshes, etc. Additionally, the event may be a representational state transfer (REST).

[0031] At block 210, the process 200 includes automatically recording the start of the span based on the detection, which recording associates the span with the tracking application 136. The tracking application 136 triggers the recording of the span corresponding to the event.

[0032] At block 212, the process 200 includes performing an action corresponding to the event. The web browser 132 executes code corresponding to the event, such as loading an image or resource.

[0033] At block 214, process 200 includes automatically recording the end of the span based on the completion of the operation corresponding to the event. When the code referenced in block 212 completes, tracking application 136 records the end of the span. The collected data can include processing cycles executed, span execution time, memory consumption, etc.

[0034] As described herein, certain aspects may measure data associated with spans that traverse multiple servers or processing threads or spans that use multiple separately identifiable actions. For example, execution of block 210 may create additional spans, each providing more granular information. For example, the tracking application 136 may create a first child span corresponding to a first action and a second child span corresponding to a second action. The first child span and the second child span may be child spans of a span.

[0035] Continuing the example, the tracking application 136 automatically records the end of a first child span based on the completion of a first action, and automatically records the end of a first child span based on the completion of a first action. Thus, the tracking application 136 obtains more granular information than just the span. The first child span and the second child span are associated with the span.

[0036] The following example shows code for inserting a client-side span context using JavaScript.

[0037]

number

[0038] FIG. 3 illustrates an example of an implementation for generating a span context in accordance with certain aspects of the present disclosure. FIG. 3 illustrates an example of an instrumented application. The instrumented application may be built and instrumented by a software development tool, such as the developer IDE 112, or may be executed by a browser running on a computing device. FIG. 3 illustrates a web application environment 300. The web application environment 300 includes a web application 302, a server 340, a query 350, and a response 352. In the example illustrated in FIG. 3, the tracking-enabled web application 302 runs on a web browser and provides one or more web pages by communicating with the server 340. The web application 302 sends one or more queries 350 and, in response, receives one or more responses 352. Note that while FIG. 3 is described with respect to a web page, the flows and components may be performed by a mobile application or other application.

[0039] Web application 302 shows flow 310, which includes web page 312 with components 314, 316, and 318. These components may be mobile applications, web applications, service connections, business objects, or processes. Each component may perform a different function as part of the web page. Components 314, 316, and 318 may raise component events 315, 317, and 318, respectively. Each of component events 315, 317, and 318 triggers one or more incidents in telemetry runtime 320, which causes one or more actions to be performed while the event is recorded.

[0040] The modules of a flow 310 or web page 312 can interact or relate to each other. For example, for a particular web page, the components may be user interface (UI) components, variables, behavior chains, web page flows, page navigation, and data access via REST endpoints. Variables may be a mechanism used to store and manage the state of browser settings, client device settings, user preferences, or other parameters. The components of a web page may interact with a telemetry runtime to handle various events for each component.

[0041] Telemetry runtime 320 can generate actions or behavior changes corresponding to component events 315, 317, and 319. For example, a user can trigger a component event by clicking a particular visual element on a web page displayed in a browser. Telemetry runtime 320 can determine that the web browser should navigate to a new web page 330. Telemetry runtime 320 can determine that the action associated with the user click is to update a portion of the user interface (UI) of web page 312.

[0042] In another example, the telemetry runtime 320 can initiate an action chain 333 corresponding to updating a portion of the UI. For example, an action chain may be a set of one or more related individual or sequential actions 336. Each action chain may be triggered by an event. For example, a user click may trigger navigation to a page corresponding to the location on the browser where the user click was received (e.g., a hyperlink, a navigation button, etc.). An action chain may define input parameters and local variables available within the scope of the action chain, and may include parameters and variables within the application. The telemetry runtime may determine that one or more REST calls 338 to a server are required to update a portion of the UI.

[0043] In response to the REST call 338, the web application 302 sends a query 350 to the REST service endpoint 332 of the server 340. The query 350 may include an insert span context. Accordingly, the server 340 sends a response 352, including additional HTTP headers, back to the web application 302. The web application 302 uses this response to complete the action triggered by the component event.

[0044] The flow of web pages and page navigation manages the communication of information between a first page and a second page. Each web page, like each application running in a browser, has a defined lifecycle. Each lifecycle event, such as entering or exiting a page, can trigger an operation chain. All data entering a mobile or web application is based on the REST protocol. This data can be obtained from custom business objects or from business objects provided by a service connection. Operations and variables control the transmission of data to and from REST endpoints within a mobile or web application. Operation chains have clearly defined contexts and contracts. An operation chain orchestrates its underlying operations and coordinates state flow and execution paths. An operation chain can define input parameters and local variables available only to its context. An example of an operation chain is one that makes a REST call (first operation) and retrieves the result and stores it in a variable (second operation). An operation can export new state to its context, which is available only to future operations along the same operation chain. An action chain can be created in the context of a page or application and exists within the scope of the page or application. An action chain has a defined interface and contract and can be invoked by an event trigger using its ID.

[0045] The telemetry application programmer interface (API) 322 can provide programmer access to the activities of the telemetry runtime, any operations or chains of operations, component events, and other related activities (e.g., server responses to operations). The telemetry API 322 can output span logs to a database, storage medium, another server, or another browser for further processing. In one example, the telemetry API can be a REST API. The telemetry API 322 can store cloud infrastructure objects, such as audit logs, application flow logs, or other log files. The telemetry API 322 can periodically sample the stored cloud infrastructure objects and output telemetry data to the common analysis ingestion unit 324 or the client log ingestion endpoint 326.

[0046] The common analysis ingestor 324 can ingest log data from the telemetry API 322. In one example, the common analysis ingestor 324 can ingest log data from a cloud infrastructure object store using a REST API. In one example, the common analysis ingestor 324 can determine a storage location for the collected log data. The common analysis ingestor 324 can ingest various log data at a user level, a group level, or an organization level. In some examples, the common analysis ingestor 324 can convert the log data into visualization data for an analysis console.

[0047] Similarly, the client log ingestion endpoint 326 may be configured to receive log data from the telemetry API 322. The agent 326 may store the log data, convert the log data into various visualization data, or perform additional processing on the log data.

[0048] In general, distributed tracing may be implemented using a tracing client API within a distributed tracing architecture. The tracing client API consists of tracers that are used to create spans around operations within an application. Spans can have child spans that represent finer-grained behavior of the corresponding parent span, which in turn can have child spans that represent finer-grained behavior than the first child span. A set of spans originating from a single parent can be considered a trace. A span can be any number of spans. It contains metadata about the behavior being measured, along with some identifying information. For applications whose behavior makes out-of-process calls (e.g., client applications making calls to REST services), the span context can be propagated with the outgoing request (e.g., in the form of special HTTP headers). The receiving application or server can extract the span context and use it to create child spans of the parent span on the client. The tracking client API has the ability to output span information (one at the start and one at the end of the span) to various backend servers in the form of log messages.

[0049] An example application span is a simple application flow: for example, a user navigates to a web page and clicks a button. The button click triggers an event that causes the application to invoke an event handler. The event handler issues a REST (definition) request, which is processed by a REST service. The REST service returns a response to update the application's user interface. This example is shown in Figure 4.

[0050] FIG. 4 illustrates an example of a span hierarchy according to one aspect of the present disclosure. FIG. 4 illustrates a span hierarchy 410 and a span timeline 430. Together, the span hierarchy 410 and the span timeline 430 describe the relationships between various spans within a span context. In the span hierarchy 410 or the span timeline 430, parent spans are related to child spans. As illustrated, the span hierarchy 410 represents a hierarchy of events, such as a user click 412, an event handler 414, a REST request 416, a processing response 418, a server processing request 420, and a UI update 422. The span timeline 430 includes span A 424, span B 434, span C 436, span D 440, span E 438, and span F 442.

[0051] In one example, web browser 132 receives a user click 412. User click 412 causes the creation of span A 424. In response, web browser 132 fires an event represented by the action of the user click, triggering the action of event handler 414. Web browser 132 can use event handler 414 to determine one or more actions to take in response to the detected event based on the received user click. Instantiation of event handler 414 creates span B 434, a child span of span A 424.

[0052] Continuing with this example, event handler 414 generates REST request 416 and processes response 418. Because response processing for a REST request occurs after the REST itself, span C 436 (corresponding to the REST request) is generated before span E 438. The REST request causes the server to process the request. Processing the REST response updates the user interface (UI). Thus, as shown, REST request 416 causes the server to process the request and update UI 422. Because the UI is not updated until the server processes the request, span D 440 (corresponding to the server processing request) is generated before span D 440 (corresponding to the UI update). It begins and completes before span F 442. Span D 440 therefore represents the processing of the request by the server.

[0053] As can be seen from the figure, span D440 is generated between span C436, and span F442 is generated between span E438. Span E438 represents the browser's processing of a response from the server (corresponding to a REST request from the browser). Span F442 represents the browser updating the user interface based on the processing of the response from the server. Span C436 and span E438 are child spans of span B and are executed sequentially. Span D440 is a child span of span C436, and span F442 is a child span of span E438.

[0054] Span contexts such as those described with respect to FIG. 4 are managed by instrumentation libraries that are added to custom enterprise applications by software development tools (eg, developer IDE 112).

[0055] Figure 5 illustrates the tracing components of an instrumented application used to generate span contexts and logs in accordance with certain aspects of the present disclosure. In the example illustrated in Figure 5, an end-user computing device 520 running a web application 522 communicates with a server 560 via various commands and / or API calls. The web application 522 may be developed by the developer IDE 112 or may be customer-developed software. Code to support instrumentation is added automatically by the developer IDE 112.

[0056] The end-user computing device 520 includes one or more modules, such as a web application 522 (or any other consuming client), a tracing module 524, a tracing interface 526, a span interface 528, a tracer 530, spans 532, a span recording library 534 (i.e., Bunyan logger), a span stack 536, a browser console 538, a compression layer 544, a tracing server stream 546, a sender task 548, a message queue 542, and a tracing console stream 552. The tracer 530 operates to perform instrumentation on the web application, create one or more spans 532, and add active spans to the span stack 536. The server 560 includes one or more modules, such as a trace collection servlet 562.

[0057] Web application 522 then receives or detects an interaction from a user (e.g., a user click). Web application 522 interacts with tracking module 524 and / or tracking interface 526 to launch one or more tracers 530. Span recording library 534, via span interface 528, records information and metadata such as the type of event, the name of the event, the URL of the server request, the return status code, errors, warnings, etc.

[0058] Various API calls are available: The API call initTracer() initializes and returns a global tracer object. The API call initTracer is called once for an application context and returns a Tracer options object. The API call activeTracer returns a global tracer object. For example, the API call inject() injects a span into a request (e.g., to the server). The API call extract() returns The span can be extracted using

[0059] Multiple spans can be generated. For example, the tracer 530 can create a span that represents an event or a thread in the web application 522. 530 may create child spans as needed (e.g., as described with respect to FIG. 4) based on the particular action for which the tracer created the span. As discussed further herein, an instrumented application may obtain information from different threads and / or different servers servicing requests caused by the triggering of events in the application.

[0060] Web application 522 can use trace interface 526 to control the tracer or receive insertions for spans. Tracers can also monitor, write to, or read span stack 536, which can cache or use one or more spans to monitor parent spans, or can insert span context into newly created spans, such as span 532. Web application 522 can use span interface 528 to send span-related information to span recording library 534. Compression layer 544 can compress span-related information to minimize it before sending it to trace collection servlet 562. Exemplary compression techniques used by compression layer 544 include zip and gzip. In one example, the trace console stream 552 can output a stream of span logs to a browser console displayed on the end user computing device 140. The server 560 can then run a trace collection servlet 562 that streams the span logs on the end user computing device 520 and collects traces from the sender task 548.

[0061] Span Priority Aspects of the present disclosure relate to instrumenting web applications. In some cases, calls that result in many events, resulting spans, and / or child spans can make it difficult to manage or prioritize a large number of spans. In such cases, certain aspects provide functionality for reducing the payload of spans in order to reduce the volume of span logs and streamline telemetry data.

[0062] In default mode, the instrumentation captures all spans and can send messages based on all spans to the browser console and to any service. However, in some cases, there may be an unmanageable number of span messages, so you want to obfuscate the relevant telemetry data you are interested in. Therefore, you can filter spans based on one or more criteria.

[0063] Furthermore, in some cases, a span of interest is a child span that provides more detailed information than the corresponding parent span. However, parent span information can cause span data congestion. Therefore, certain aspects introduce the concept of a proxy span, which allows for collecting only the instrumentation details of one or more specific child spans of interest while maintaining the span tree.

[0064] 6 illustrates an example tracing architecture used to manage backpressure caused by instrumenting spans in accordance with certain aspects of the present disclosure. Figure 6 illustrates tracing architecture 600 including one or more of an application runtime 602, a tracer implementation 604, a span controller 606, a browser span recording library 634, a console stream 610, a client recording service (CLS) stream 612, and a client recording service 614. In the illustrated example, span controller 606 manages and prioritizes spans based on one or more parameters. Application runtime 602 is similar to telemetry runtime 320 described with respect to FIG. 3 and may perform similar operations to telemetry runtime 320.

[0065] In a first example, the tracer implementation 604 initiates a span in the application runtime 602. While the tracer implementation 604 executes the span, it can communicate span monitoring data to the browser span recording library 634. The browser span recording library 634 outputs span log data to the console stream 610. These span log data may be displayed in a browser on the end user device. The browser span recording library 634 can also output span log data to the CLS stream 612. The CLS stream 612 may be a stream of log data that is sent to the client recording service 614. The client recording service 614 can store the log data for further processing.

[0066] In another example, the tracer implementation 604 receives spans created by the span controller 606. The tracer implementation 604 can also return spans (e.g., terminate the span) upon completion of the event that created the span. The tracer implementation 604 can also receive a command to terminate a span from the application runtime 602. The span controller 606 can perform span prioritization. Each span can have a priority level. For example, the span controller 606 can receive one or more parameters that indicate which spans should be prioritized. In one example, a default span priority is set. If the priority level of a given span is less than the default priority, data for that span and its associated child spans is not returned.

[0067] In yet another example, tracking architecture 600 generates an initial set of spans, for example, as described with respect to process 200. Each span in the initial set of spans has a corresponding priority. Then, at runtime, the spans in the initial set of spans may be measured, not measured, or pruned to a subset based on programmer or user input. For example, a threshold priority may be set. At runtime, any spans with a priority greater than the threshold priority are converted to proxy spans and not measured.

[0068] Proxy spans maintain a span tree that shows the relationships between parent and child spans. However, because proxy spans are not measured, the span controller 606 does not obtain runtime instrumentation measurements for the span, but does obtain measurements for any child spans that are not proxy spans. Because proxy spans preserve the relationships between parent and child spans, they maintain the tree structure even if a particular proxy span in the tree does not have instrumentation data. Thus, in this way, the span tree can be pruned to maintain data for spans that are of interest to developers. Figure 7 provides an example of using proxy spans.

[0069] 7 illustrates an example of a span hierarchy without and with priorities, in accordance with certain aspects of the present disclosure. Specifically, FIG. 7 illustrates a span hierarchy 700 that does not use priorities and a span hierarchy 730 that does use priorities.

[0070] In span hierarchy 700, span A 702 is the parent span of span B 704. Span B 704 is also the parent span of span C 706, span D 708, and span E 710. In span hierarchy 700, data for all spans, namely span A 702, span B 704, span C 706, span D 708, and span E 710, is collected.

[0071] In contrast, span hierarchy 730 shows a span hierarchy with priority. Layer 730 includes span A 732 and span proxy B 734, a child span of span A 732. Span A 732 has a priority of 1. Span proxy B 734 has a priority of 2, which is greater than the priority of span A 732. In this example, the default priority is set to 1. Span proxy B 734 has been transformed from the original span B because instrumentation data from span B is not needed, as indicated by span B's priority being 2, which is greater than the default priority.

[0072] As a result, span C 736, span D 738, and span E 740 are not pruned because they all have priority 1, but are marked as having parent span A 732 because their original parent span, span B, is a proxy. Therefore, at runtime, instrumentation data is collected for span A 732, span proxy B 734, span D 738, and span E 740.

[0073] From an implementation perspective, the span options used to create the span (SpanOptions ) object contains a priority field. In some cases, when you do not specify a priority for a span, the root span has an implicit "high" priority (1) and child spans have an implicit "medium" priority (2). The span (specified by SpanImpl) is created and returned, and the message is sent normally. If the span is proxied, a SpanProxy object is created instead. Just like any other span object You can then interact with the SpanProxy object, but the SpanProxy The fields and methods of the SpanProxy delegate to the active span. For example, in the above example, SpanProxy B 734 is a SpanProxy object. The object corresponds to the object, and its methods and fields correspond, by default, to the object of span A 732. In this way, there is no need to adjust the application runtime environment, since the involved applications are always receiving the span.

[0074] In some implementations, priority values ​​are represented by positive numbers, with higher values ​​indicating lower priority. For example, priority level 0 may be the highest priority, followed by level 1, then level 2, and so on. Thus, in this implementation, any span with a priority value higher than the threshold priority is converted to a proxy span. However, different ranking schemes are possible. For example, higher values ​​indicate higher priority. In some cases, priorities may be represented as aliases. For example, "critical" may be assigned to level 0, "high" to level 1, "medium" to level 2, and "low" to level 3. By default, a root span may have priority 1, and child spans may have priority 2.

[0075] In some cases, the priority threshold is determined by a fleetwide sampling algorithm. The algorithm may be modified by a tracer configuration or server-side profile option. This algorithm involves assigning a percentage and a random number chosen to fall within one of the percentages to each priority. To ensure that most application users send a minimum amount of telemetry (for capacity and performance reasons), typically higher percentages will be assigned to higher priorities. Smaller percentages may be assigned to lower priorities. This indicates that fewer users will send more telemetry in order to obtain deeper information about user journeys or other higher granularity information. The percentages may be applied according to the tracer configuration or server-side profile options.

[0076] In some cases, priority boosting can be performed. Priority boosting refers to increasing the priority of a proxy span at runtime. This can happen if the span is found to have interesting instrumentation data, e.g., duration. Priority boosting can occur if is too long and the span does not have a child span that forms the majority of the span's duration, or if an error occurs.

[0077] The tracking system can be configured to dynamically adjust the priority threshold, for example, when excessive requests are received and / or the payload is too large (also known as "ingestion service backpressure"). For example, an ingestion service (CLS) for collecting spans and logs can respond with an HTTP error code indicating that too many spans and / or logs have been sent (e.g., "429" indicates excessive requests and "413" indicates a payload that is too large). Thus, the system can respond by dynamically changing the priority threshold to send fewer logs on subsequent requests.

[0078] The following table shows an example priority for different event spans:

[0079] [Table 1]

[0080] 8 illustrates an example process 800 for prioritizing spans in accordance with certain aspects of the present disclosure. Process 800 may be performed by developer computing device 110 and one or more of servers 140a-n.

[0081] At block 802, process 800 includes verifying from the web application's code that the web application includes events triggered by user interaction. For example, during instrumentation, developer IDE 112 running on developer computing device 110 determines that web application 134 includes events triggered by user interaction.

[0082] At block 804, the process 800 includes associating the event with the first span. The developer IDE 112 may then execute the first span triggered by the event (i.e., its execution). The tracer is configured to record trace information based on execution of a first set of operations (corresponding to rows). The tracer is configured to obtain a first performance measure for a first span, the span referring to the first set of operations. Examples of performance measures include cycles, processing time, memory usage, latency, etc.

[0083] At block 806, the process 800 includes identifying from the code that execution of the first set of operations sends a request to a server. For example, the first set of operations can include a REST call.

[0084] At block 808, the process 800 includes associating the request with a second span. Based on the identified request, the tracer is configured to record tracking information based on execution of a second set of actions caused by the request. The tracer is configured to obtain second performance measures of the second span. The second span is a child span of the first span.

[0085] At block 810, the process 800 includes receiving a priority of the first span. For example, at runtime when the web browser 132 is executing the web application 134, a developer may adjust the priority of the first span. The priority may be adjusted up or down.

[0086] At block 812, the process 800 includes determining that the priority is outside a priority tolerance range. In some cases, a threshold value can be used instead of a tolerance range.

[0087] At block 814, process 800 includes classifying the first span as a proxy span based on this determination. Continuing the example, web browser 132 classifies the first span as a proxy span and does not collect instrumentation data. At runtime when the web application is executing, the tracer does not record information based on the execution of the first set of operations corresponding to the first span.

[0088] Instrumented Threads Traditionally, web-based applications can use the main browser thread to perform user interface operations. For example, improvements in asynchronous JavaScript programming allow the main browser thread to create responsive applications. However, for certain long-running background processes, application developers can choose to use the Web Worker API, which allows them to create actual native threads to execute application logic.

[0089] However, in a typical distributed tracing application, separate threads (e.g., threads via the worker API) are considered to be out of the process, or at least in a different scope than the tracer running on the main thread, so you need to configure the tracer in your code to run on a worker thread.

[0090] In contrast, certain aspects can automatically instrument threads. For example, the tracing worker class abstracts the task of configuring tracers within application code by encapsulating the tracer in a subclass of the standard worker class. The tracing worker class uses an algorithm to automatically create a worker thread, configure the tracer, and then load the application code, which is automatically telemetry-enabled. Thereafter, if necessary, a native web worker thread can be instrumented. A tracking worker can be configured to override the API so that when an application creates a worker thread it becomes a tracking worker wrapping the standard worker functionality.

[0091] Advantages of this approach include transparent behavior to developers and users, and enabling off-thread code telemetry while maintaining the spanning hierarchy between threads. Additionally, each thread's configuration data automatically inherits the main thread's configuration, eliminating the need to duplicate configuration data.

[0092] 9 illustrates an example of a distributed tracing environment including a tracing worker client in accordance with certain aspects of the present disclosure. Figure 9 shows a main browser thread 910 and a worker thread 920. In the example shown in Figure 9, the main browser thread 910 invokes the worker thread 920, which returns instrumented data to the main browser thread 910.

[0093] The main browser thread 910 includes a main application 912, a tracer 914, and a trace worker client 917. The worker thread 920 includes a trace worker shim code 922, an application worker script 924, and a tracer 925. The worker thread 920 is an object created using the trace worker client 917 and can be written in JavaScript.

[0094] Worker thread 920 may run in a different environment than the main browser operation, such as a browser window, in this way, a more responsive user interface can be maintained, for example, if the task being performed by worker thread 920 is time-consuming or complex.

[0095] The tracking worker client 917 can manage threads such as worker thread 920, for example, by configuring the worker thread 920 with tracking worker shim code 922. Adding tracking worker shim code 922 makes it easy to obtain the span context and tracking context. The wrapper's constructor wraps the child span of the current span's context, if applicable. When a worker thread is created, it is initialized with the application script to run and has a communication port.

[0096] The tracking worker client 917 generates and executes shim code 922 that performs the following operations: (1) temporarily installs a message handler to handle all incoming messages from the main thread, (2) loads all distributed tracking dependencies, and (3) responds with a message indicating success (or failure).

[0097] If successful, the trace worker client 917 obtains the active span context and tracer configuration and sends it to the shim. The shim receives the tracer configuration, initializes the tracer, and creates child spans for the received span context. The shim then inserts application worker code and removes message handlers. The application thread and worker thread then perform various operations.

[0098] Once created, worker thread 920 can create a tracer and copy one or more configuration parameters from worker thread 920 to tracer 925. Worker thread 920 can also extract span contexts associated with spans created by main application 912. Worker thread 920 can extract child spans of spans created by main application 912 and include span contexts. During execution of the application worker script 924 by the worker thread 920, child spans may be created and captured by the tracer 925 for further processing. The worker thread 920 may communicate the successful completion of the application worker script 924 to the tracking worker client 917. The tracking worker client 917 may then communicate the success of the worker thread to the main application 912. The main application 912 may communicate the completion of the span to the tracer 914 and terminate the span.

[0099] In one example, data may be sent between a worker thread and the main application via a messaging system where both sides send messages. Messages may be sent using methods such as postMessage(), and responses to received messages may be communicated using an onMessage event handler to include the message in the data property of the message event. In this particular configuration, message data is copied rather than shared between the main application and the worker thread. Worker threads can spawn auxiliary workers (e.g., auxiliary threads) where the workers are hosted within the same origin as the parent page.

[0100] The following example code shows how a developer can use the tracking worker thread:

[0101]

number

[0102] 10 illustrates an example process 1000 for instrumenting threads in accordance with certain aspects of the present disclosure. Process 1000 may be performed by developer computing device 110 and one or more of servers 140a-n.

[0103] At block 1002, the process 1000 includes providing a web page application to a web browser on a client device. For example, the server 140a provides the web application 134 to the web browser 132 on the end-user computing device 130.

[0104] At block 1004, process 1000 includes creating a global tracer from the web page application, the global tracer being configured to record tracking data for the web page application. The global tracer is created in a manner similar to that described with respect to block 206 of process 200.

[0105] At block 1006, the process 1000 includes instantiating a wrapper for the auxiliary thread from the web page application, the wrapper configured to execute shim code before executing the auxiliary thread.

[0106] At block 1008, the process 1000 includes passing configuration data for the global tracer from the wrapper to the shim code.

[0107] At block 1010, the process 1000 includes creating an auxiliary tracer from the shim code. The auxiliary tracer is configured to record trace data for the auxiliary thread. The trace data for the web page application and the trace data for the sub-thread are associated via configuration data for the global tracer.

[0108] At block 1012, the process 1000 includes executing an auxiliary thread from the shim code.

[0109] Instrumenting spans across server calls 11 illustrates an example process 1100 for propagating traces throughout a distributed software application in accordance with certain aspects of the present disclosure. Process 1100 may be implemented by a computing system, such as end-user computing device 140, or may be part of trace application 136. Process 1100 includes making an appropriate request to a remote server to retrieve a resource (e.g., a web page, an image, or a file). The request may be Hypertext Transfer Protocol (HTTP). For illustrative purposes, process 1100 will be described in conjunction with FIG. 12.

[0110] FIG. 12 illustrates an example for propagating a span context across services in a distributed system in accordance with certain aspects of the present disclosure. The example service includes a REST call to a server. For example, rendering a particular web page may require multiple REST calls, each with a specific purpose. A first REST call may cause a web browser to render the page, a second REST call may be located on the server (a REST endpoint) and retrieve an image to be displayed on the page, or a third REST call may be a database query to retrieve information such as the name of an employee's manager. Additionally, a REST call may cause one or more child REST calls to be executed.

[0111] A REST call may be a cross-origin call. A cross-origin call invokes a request information from a server that is not the original server (e.g., the server serving the web page). For example, the original server may be on oracle.com, and the second server may be on google.com. In some cases, process 1100 is performed after determining that a web page from the original server requires a request to an external server located outside the original server's domain. The determination may be compatible with Cross-Origin Resource Sharing (CORS).

[0112] FIG. 12 includes service 1210 and service 1220. Service 1210 can run a browser, and service 1220 runs on a server identified by a REST endpoint. Service 1210 includes parent span 1212, child span 1214, and child span 1216. Service 1220 includes child span 1222 after the REST call. In one example, child spans 1214 and 1216 represent processing that needs to occur before the REST call. The context of child span 1222 is sent over the network to the server. The server can then propagate the span context to other servers that make such requests. Each server collects its own traces and sends them to the appropriate location.

[0113] As explained, a span context includes a root span or tracking identifier, which indicates the overall goal to be achieved (e.g., loading a page). A complete span context includes a tracking identifier (ID), which is typically a 128-bit representation, and a child ID, which is typically a 64-bit random number. A graph can be constructed from each span context, i.e., from all span contexts that point to their respective parents.

[0114] Returning to FIG. 11 , process 1100 begins at block 1101. A tracking application 136 can record tracking data for web pages from origin servers. The tracking data can include previous requests and the success and failure of those requests. From the tracking data, the tracking application 136 can form a deny list including destination servers that deny requests that include tracking headers and / or an allow list including destination servers that allow requests that include tracking headers. In some cases, process 1100 is executed when a cross-domain request is detected.

[0115] Instrumentation can be achieved by inserting tracking headers into server requests for resources (e.g., as part of loading a web page). However, tracking headers are often rejected, e.g., for security reasons. Therefore, process 1100 includes circumventing such security measures to facilitate telemetry. For example, considering FIG. 12 , service 1210 runs on an original server and service 1220 runs on an external server. Thus, parent span 1212 (e.g., of a first process) runs on the original server. Using the techniques disclosed herein, tracking application 136 can analyze not only parent span 1212 but also child spans 1214 and 1216 derived from child span 1214. However, as shown, parent span 1212 is also associated with child span 1222, which runs on service 1220 (and thus on the external server). Process 1100 can be used to propagate span context from parent span 1212 to child span 1222, thereby facilitating instrumentation.

[0116] At block 1102, the process 1100 includes determining whether CORS is active (e.g., whether a cross-domain request is detected). If so, the process 1100 proceeds to block 1103. In this case, if CORS is not required, the process 1100 proceeds to block 1108 and inserts the header.

[0117] At block 1103, process 1100 includes determining whether the request for the resource is idempotent. Idempotent means that the intended effect of the method on multiple identical requests of the server is the same as the effect on a single such request. Thus, if the intended effect of the server's request is not idempotent, i.e., not the same as the previous request, process 1100 proceeds to block 1104. Conversely, if the request is idempotent, process 1100 proceeds to block 1115.

[0118] At block 1104, process 1100 includes determining whether the destination of the request is a server on a deny list. For example, the tracking application 136 determines whether the external server denies the tracking header in the request from the original server by searching the deny list. The server deny list includes servers identified as denials that include extra headers (e.g., created by the request identified by block 1112 of process 1100). The deny server list is useful because, if the choice is between failing the REST call and simply not having telemetry information, simply not having telemetry information is preferable.

[0119] If a request to a service does not support propagation headers, the request is added to a deny list, preventing further automatic attempts to insert context for this user session and performing the request without the inserted headers. In one aspect, the deny list is not cached in local storage so that an incomplete configuration does not cause future requests to be blocked. It is possible for a destination to be on both the allow list and the deny list, in which case the deny list takes precedence.

[0120] To improve search time, the allow and deny lists are implemented as associative arrays. The lists are encoded by the URL origin of the failed request (without parameters) or by individual services, which may be determined by the request's configuration. The values ​​in the map may be zero, but can later contain other metadata about the actual failure or the reason for its addition to the list.

[0121] Examples of calls include:

[0122]

number

[0123] If the server is on the denied list, the process 1100 proceeds to block 1114. If the server is not on the denied list, the process 1100 proceeds to block 1105.

[0124] At block 1105, process 1100 includes determining whether the request is destined for a server on a permitted list. For example, the tracking application 136 may determine whether the external server allows tracking headers in requests from the original server by searching the permitted list. The permitted list may include information that prevents requests containing extra headers (e.g., created by a request identified by block 1112 of process 1100) from being accepted. This includes servers identified as

[0125] If it is determined that the propagation header is supported, the particular destination is added to the allow list. The allow list can be cached in local storage so that an additional options call does not have to be made. This approach eliminates the need to support a user interface for explicitly allowing a list of service endpoints. If the destination is on the allow list, process 1100 inserts the header at block 1108. If the destination is not on the allow list, process 1100 proceeds to block 1106.

[0126] At block 1106, process 1100 includes executing an HTTP options call. The options call requests allowed communication options from the server. In the CORS protocol, a preflight request is sent with the options method so the server can respond whether to send the request. The options call determines whether to allow insertion of tracking headers. Optionally, at block 1106, process 1100 includes executing a preflight request before the browser automatically performs such checks. Process 1100 proceeds to block 1107.

[0127] At block 1107, process 1100 includes determining whether tracking headers are supported by the server from the results of the options call. In some cases, the options call can return a list of allowed (or accepted) headers. If tracking headers are supported, process 1100 proceeds to block 1108 and inserts the headers. If tracking headers are not supported, process 1100 proceeds to block 1113 and adds the server to a server reject list.

[0128] Below are some example option requests / responses (some headers have been omitted for brevity): For example, the following shows an option request to detect propagation:

[0129]

number

[0130] Another example shows the response when the service endpoint is configured for propagation.

[0131]

number

[0132] Another example shows a response with no propagation set.

[0133]

number

[0134] At block 1108, the process 1100 includes inserting a header into the request. Inserting the tracking header into the request is based on a determination that the external server allows tracking headers in the request. As an example, the content of the tracking header includes a span context.

[0135] As an example, Zipkin and / or ECID (Execution Context) can be used. These protocols provide the coverage for preserving context with minimal effort on the part of the service developer.

[0136] In one example, the Zipkin B3 HTTP header scheme is used because it has wide support. Examples of B3 headers include:

[0137]

number

[0138] The TraceId is a unique 32 character UUID string, the SpanId is a unique 16 character string that surrounds the span, and the ParentSpanId is the span ID of the parent span. A unique ID for the pan (if applicable), Sampled is the span telemetry This is a flag indicating whether to report the setting.

[0139] In another example, an Oracle-specific ECID-Context header is used.

[0140]

number

[0141] The RID is an encoded string of bytes that indicates the path of the context. This string from the browser is "kXjE" and when decoded indicates the route of the request.

[0142] If it is determined that a header can be injected, the injection is performed using the Tracer.inject() API call. This call inserts an HTTP header into the outgoing request before sending it to the server.

[0143] Figure 13 illustrates an example of a header in accordance with certain aspects of the present disclosure, showing header 1310, an HTTP header with no instrumentation, and header 1320, the same HTTP header as header 1310, but with additional instrumentation (depicted in bold text).

[0144] Returning to FIG. 11, process 1100 proceeds to block 1109. At block 1109, the process 1100 includes sending a request to a server. The web browser sends the request including the tracking header to an external server. The external server is configured to record tracking data based on the tracking header.

[0145] At block 1110, process 1100 includes determining whether the request to the server was successful. If the request was successful, process 1100 proceeds to block 1111, where the process ends. If the request was not successful, process 1100 proceeds to block 1112.

[0146] At block 1111, process 1100 includes terminating the process for making the request. At block 1111, the extra headers are successfully sent to the server, resulting in the span context being propagated to the destination server for instrumentation assistance by the destination server.

[0147] At block 1112, process 1100 includes determining whether the failure identified at block 1110 was due to a header, as opposed to some other error. If the failure was not due to a header, process 1100 may proceed to block 1116 and perform normal failover / retry procedures. If the failure was due to a header, process 1100 proceeds to block 1113 and adds the server to a server reject list.

[0148] At block 1113, process 1100 includes adding the destination server to a server reject list. In this way, if a request with the same destination server is identified, process 1100 will not attempt to send the request with the tracking header to the same server that rejected it. After completing block 1113, process 1100 proceeds to block 1114 and creates an uninserted request.

[0149] At block 1114, process 1100 includes making an uninserted request, e.g., a normal REST call without tracking headers. In some cases, the timing of processing the request may be used for telemetry. After block 1114, process 1100 proceeds to block 1118 and processes the response normally.

[0150] At block 1115, process 1100 includes determining whether the request is in a cached request list. To improve performance and reduce failures, the request can be stored in a cache. If the request is cached, process 1100 proceeds to block 1117. If the request is not cached, process 1100 proceeds to block 1104. The request may include a span context.

[0151] At block 1116, process 1100 includes performing a failover process or retrying the request. In this case, given that a failed page load or completion is a suboptimal user experience, process 1100 at block 1116 includes retrying the failed operation to ensure that the tracking header insertion attempt did not cause the failure. In some cases, developers may want to add sufficient error checking or graceful exits to ensure that the failed operation does not result in a failure. Therefore, in this regard, block 1116 helps ensure that custom applications do not fail due to telemetry. The request may include a span context.

[0152] At block 1117, the process 1100 includes proceeding with the cached response. The cached response is used to process the request. The request may include a span context. The span and log are sent to the span recording library, as described with respect to Figures 4 and 5.

[0153] 14 is a simplified diagram illustrating a distributed system 1400 for implementing one of the embodiments. In the illustrated embodiment, the distributed system 1400 includes one or more client computing devices 1402, 1404, 1406, and 1408 configured to execute and operate client applications, such as web browsers or dedicated clients (e.g., Oracle Forms), via one or more networks 1410. A server 1412 may be communicatively coupled to the remote client computing devices 1402, 1404, 1406, and 1408 via the network 1410.

[0154] In various embodiments, server 1412 may be configured to run one or more services or one or more software applications provided by one or more components of the system. The services or software applications may include non-virtual environments and virtual environments. Virtual environments may include those used for virtual events, trade shows, labs, classrooms, shopping exchanges, and businesses, two-dimensional or three-dimensional (4D) representations, page-based logic environments, and the like. In certain embodiments, these services may be provided to client computing devices 1412 as web services or cloud services, or based on a Software as a Service (SaaS) model. The services provided by these components may be provided to users of client computing devices 1402, 1404, 1406, and / or 1408. Thus, users operating client computing devices 1402, 1404, 1406, and / or 1408 may utilize the services provided by these components by using one or more client applications to interact with server 1412.

[0155] In the illustrated configuration, software elements 1418, 1420, and 1422 of system 1400 are implemented on server 1412. In other embodiments, one or more components of system 1400 and / or services provided by these components may be implemented by one or more client computing devices 1402, 1404, 1406, and / or 1408. A user operating a client computing device may use one or more client applications to utilize the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be understood that various system configurations different from distributed system 1400 are possible. Thus, the illustrated embodiment is an example of a distributed system for implementing an embodiment of the system and is not intended to be limiting.

[0156] The client computing devices 1402, 1404, 1406 and / or 1408 may be implemented using software such as, for example, Microsoft Windows Mobile®, and / or iOS, Windows Phone, Android®, BlackBerry 15, and The client computing device may be an Internet-, email-, Short Message Service (SMS), Blackberry®, or other communication protocol-enabled handheld mobile device (e.g., iPhone®, mobile phone, iPad®, tablet, personal digital assistant (PDA) or wearable device (e.g., Google Glass® head-mounted display). The client computing device may be, by way of example, a device running Microsoft Windows (registered trademark) operating system. (trademark) operating system, Apple Macintosh (trademark) operating system The client computing devices 1402, 1404, 1406, and 1408 may be general-purpose personal computers, including personal and / or laptop computers running various versions of the Linux operating system. The client computing devices may be, for example, workstation computers running various GNU / Linux operating systems, commercially available UNIX or UNIX-like operating systems, including, but not limited to, Google Chrome OS. Alternatively or additionally, the client computing devices 1402, 1404, 1406, and 1408 may be other electronic devices, such as thin-client computers, Internet-enabled gaming systems (e.g., Microsoft Xbox game consoles with or without Kinect gesture input devices), and / or personal messaging devices, capable of communicating over the network 1410.

[0157] Although the distributed system 1400 is shown with four client computing devices, any number of client computing devices can be supported. Other devices, such as devices with sensors, can exchange information with the server 1412.

[0158] Network 1410 of distributed system 1400 may be any network including, but not limited to, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (Systems Network Architecture), IPX (Internet Packet Exchange), AppleTalk, etc. Network 1410 may support data communications using any of a variety of commercially available protocols, including, but not limited to, Ethernet, Token Ring, and / or other protocols, and may be any type of network familiar to those skilled in the art. By way of example only, network 1410 may be a local area network (LAN) based on Ethernet, Token Ring, and / or other. Network 1410 may also be a wide area network or the Internet. Network 1410 may be a virtual network, including, but not limited to, a virtual private network (VPN), an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., using the IEEE (Institute of Electrical and Electronic Engineers) 802.14 protocol suite, Bluetooth, and other protocols). and / or networks operating under any other wireless protocol) and / or combinations of these and other networks.

[0159] The server 1412 may be comprised of one or more general-purpose computers, dedicated server computers (including, by way of example, PC (personal computer) servers, UNIX servers, midrange servers, mainframe computers, and rack-mount servers), server farms, server clusters, or any other suitable configuration and / or combination. The server 1412 may include one or more virtual machines running a virtual operating system or other computing architecture requiring virtualization. One or more flexible pools of logical storage may be virtualized to maintain virtual storage for the server. The server 1412 may use software-defined networking to control the virtual network. In various aspects, the server 1412 may be configured to run one or more services or software applications described in the foregoing disclosure. For example, the server 1412 may correspond to a server for executing the processes described above in accordance with embodiments of the present disclosure.

[0160] Server 1412 may run an operating system, including any of those mentioned above, as well as any commercially available server operating system. Server 1412 may also run a variety of additional server applications and / or services, including an HTTP (Hypertext Transfer Protocol) server, an FTP (File Transfer Protocol) server, a CGI (Common Gateway Interface) server, a Java server, a database server, etc. can run any of the middle-tier applications. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle®, Microsoft®, Sybase®, and IBM®.

[0161] In some implementations, server 1412 may include one or more applications that analyze and consolidate data feeds and / or event updates received from users of client computing devices 1402, 1404, 1406, and 1408. By way of example, the data feeds and / or event updates may be received from Twitter® (R) feeds, Facebook® updates, or real-time updates received from one or more third sources and continuous data streams. Real-time updates may include real-time events associated with sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring devices, etc. Server 1412 may also include one or more applications for displaying data feeds and / or real-time events via one or more displays of client computing devices 1402, 1404, 1406, and 1408.

[0162] Distributed system 1400 may also include one or more databases 1414 and 1416. Databases 1414 and 1416 may reside in a variety of locations. Illustratively, one or more databases 1414 and 1416 may reside on non-transitory storage media near (and / or within) server 1412. Alternatively, databases 1414 and 1416 may be remote from remote server 1412 and communicate with server 1412 via a network-based or dedicated connection. In one set of embodiments, databases 1414 and 1416 may reside on a storage area network (SAN). Similarly, any necessary files for performing functions contributed to server 1412 may be stored on server 1412 and / or remote from server 1412, as needed. In one set of embodiments, databases 1414 and 1416 may comprise relational databases, such as those provided by Oracle. These relational databases may store data in response to SQL formatting instructions. It is configured to retrieve, store and update

[0163] 15 is a simplified block diagram illustrating one or more components of a system environment 1500 according to an embodiment of the present disclosure. Services provided by one or more components of a system according to an embodiment can be provided as cloud services. In the illustrated embodiment, the system environment 1500 includes one or more client devices 1504, 1506, and 1508. A user can use the client computing devices to interact with a cloud infrastructure system 1502 that provides cloud services. The client computing devices can be configured to run a client application, such as a web browser, a dedicated client application (e.g., Oracle Forms), or other application. A user can utilize services provided by the cloud infrastructure system 1502 by interacting with the cloud infrastructure system 1502 using the client application.

[0164] It should be understood that the illustrated cloud infrastructure system 1502 may include components other than those shown. Furthermore, the illustrated embodiment is merely one example of a cloud infrastructure system that may incorporate aspects of the present invention. In some other embodiments, cloud infrastructure system 1502 may have more or fewer components than shown, and may include two or more components. It may combine components or have components in different configurations or arrangements.

[0165] The client devices 1504, 1506, and 1508 may be similar to the client computing devices 1402, 1404, 1406, and 1408 described above.

[0166] Although the exemplary system environment 1500 is shown with three client computing devices, any number of client computing devices may be supported. Other devices, such as devices with sensors, may exchange information with the cloud infrastructure system 1502.

[0167] Network 1510 may facilitate the communication and exchange of data between client devices 1504, 1506, and 1508 and cloud infrastructure system 1502. Each network may support data communication using any of a variety of commercially available protocols, including those described above with respect to network 1410, and may be any type of network familiar to those skilled in the art.

[0168] Cloud infrastructure system 1502 may include one or more computers and / or servers, which may include the components described above with respect to server 1412 .

[0169] In certain aspects, services provided by a cloud infrastructure system may include many services, such as online data storage and backup, web-based email services, hosted office suites and document collaboration services, database processing, and managed technical support services, that can be provided to users from the cloud infrastructure system on demand. The services provided by the cloud infrastructure system can be dynamically scaled to meet user needs. A particular instance of a service provided by a cloud infrastructure system is referred to herein as a "service instance." In general, any service that can be provided to users from a cloud service provider's system over a communications network such as the Internet is referred to as a "cloud service." Typically, in a public cloud environment, the servers and systems that make up the cloud service provider's system are different from the customer's on-premises servers and systems. For example, the cloud service provider's system can provide applications, and users can order and use the applications as needed over a communications network such as the Internet.

[0170] In some examples, services within a computer network cloud infrastructure may include protected computer network storage access, hosted databases, hosted web servers, software applications, or other services provided to users by a cloud vendor, or other services known in the art. For example, a service may include password-protected access to remote storage on the cloud over the Internet. As another example, a service may include a relational database hosted on a web service and a scripting language middleware engine for private use by developers on the network. As another example, a service may include access to an email software application hosted on a cloud vendor's website.

[0171] In certain embodiments, the cloud infrastructure system 1502 is a self-service A cloud infrastructure system may include a suite of application, middleware, and database services that can be provided to customers in a flexible, scalable, reliable, highly available, and secure manner based on subscriptions to services. An example of such a cloud infrastructure system is the Oracle Public Cloud offered by the assignee of the present application.

[0172] Large amounts of data, sometimes referred to as big data, may be hosted and / or manipulated by infrastructure systems at many levels and at different scales. Such data can include datasets so large and complex that they may be difficult to process using typical database management tools or traditional data processing applications. For example, terabytes of data would be difficult to store, search, and process using a personal computer or a rack of personal computers. Data of this size would be difficult to process using modern relational database management systems, desktop statistical data, and visualization packages. Acquiring, organizing, managing, and processing data of this size within acceptable elapsed times requires massively parallel processing software running thousands of server computers, which is beyond the reach of commonly used software tool architectures.

[0173] By storing and manipulating extremely large datasets, analysts or researchers can visualize large amounts of data, detect trends, and / or otherwise interact with the data. Dozens, hundreds, or thousands of processors linked in parallel can act on such data to present it or simulate external forces on it or what it represents. These datasets can include structured data organized in databases or according to structured models, and / or unstructured data (e.g., emails, images, data blobs (binary large objects), web pages, complex event processing). By leveraging aspects of their ability to relatively quickly focus more (or fewer) computing resources on a purpose, cloud infrastructure systems may be more available to perform tasks on large datasets based on requests from businesses, government agencies, research institutions, private individuals, like-minded groups or organizations, or other entities.

[0174] In various aspects, cloud infrastructure system 1502 can be configured to automatically provision, manage, and track services subscribed to by customers. Cloud infrastructure system 1502 can provide cloud services through various deployment models. For example, services can be provided in a public cloud model, with cloud infrastructure system 1502 owned by an organization selling cloud services (e.g., owned by Oracle), and available to the general public or to businesses in different industries. As another example, services can be provided in a private cloud model, with cloud infrastructure system 1502 dedicated to a single organization, and available to one or more entities within the organization. Cloud services can also be provided in a collective cloud model, whereby cloud infrastructure system 1502 and the services provided by cloud infrastructure system 1502 are shared by multiple organizations within an associated collective. Cloud services can also be provided in a hybrid cloud model, consisting of a combination of two or more different models.

[0175] In certain aspects, the services provided by the cloud infrastructure system 1502 fall into the Software as a Service (SaaS) category, the Platform as a Service (PaaS) category, the Infrastructure as a Service (IaaS) category, or a hybrid service. A subscription order may include one or more services provided pursuant to other categories of services, including cloud infrastructure system 1502 services. A customer may order one or more services provided by cloud infrastructure system 1502 through a subscription order. In response, cloud infrastructure system 1502 processes the delivery of the services included in the customer's subscription order.

[0176] In certain embodiments, the services provided by the cloud infrastructure system 1502 include, but are not limited to, application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services that conform to the SaaS category. For example, the SaaS platform may function to build and deliver a suite of on-demand applications on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure to provide the SaaS services. By utilizing the services provided by the SaaS platform, customers can utilize applications running on the cloud infrastructure system. Customers can obtain application services without having to purchase separate licenses and support. A variety of different SaaS services may be offered. Examples include, but are not limited to, services that provide solutions for sales performance management, enterprise integration, and business flexibility for large organizations.

[0177] In certain aspects, platform services may be provided by a cloud infrastructure system via a PaaS platform. The PaaS platform may be configured to provide cloud services that conform to the PaaS category. Examples of platform services include, but are not limited to, services that enable an organization (e.g., Oracle) to integrate existing applications on a shared, common architecture and build new applications that leverage shared services provided by the platform. The PaaS platform can manage and control the underlying software and infrastructure to provide the PaaS services. Customers can utilize applications that run on the cloud infrastructure system. Customers can obtain application services without having to purchase separate licenses and support. A variety of different SaaS services may be offered. Examples of platform services include, but are not limited to, Oracle Java Cloud Services (JCS), Oracle Database Cloud Services (DBCS), and others.

[0178] By utilizing the services provided by the PaaS platform, customers can utilize programming languages ​​and tools supported by the cloud infrastructure system and control the deployed services. In certain embodiments, the platform services provided by the cloud infrastructure system can include database cloud services, middleware cloud services (e.g., Oracle Fusion middleware services), and Java cloud services. In one aspect, database cloud services can support a shared services deployment model that can give organizations the ability to pool database resources and can provide customers with database as a service (DBaaS) as a cloud database. Middleware cloud services can provide customers with a platform for developing and deploying various business applications on a cloud infrastructure system, and Java cloud services can provide customers with a platform for deploying Java applications on a cloud infrastructure system. .

[0179] A variety of different infrastructure services may be provided by the IaaS platform to the cloud infrastructure system. These infrastructure services facilitate the management and control of underlying computing resources, such as storage, network and other fundamental computing resources, for customers using the services provided by the SaaS and PaaS platforms.

[0180] Additionally, in certain aspects, cloud infrastructure system 1502 may include infrastructure resources 1530 for providing resources used to provide various services to customers using the cloud infrastructure system. In one embodiment, infrastructure resources 1530 may include a combination of hardware, such as server resources, storage resources, and network resources, pre-integrated and optimized for running the services provided by the PaaS and SaaS platforms.

[0181] In certain aspects, resources in cloud infrastructure system 1502 can be shared among multiple users and dynamically reallocated according to their needs. Resources can also be allocated to users in different time zones. For example, cloud infrastructure system 1530 can make cloud infrastructure system resources available to a first group of users in a first time zone for a specified period of time, and then reallocate those same resources to another group of users in a different time zone to maximize resource utilization.

[0182] In certain aspects, multiple internal shared services 1532 can be provided and shared among different components or modules of cloud infrastructure system 1502 and among services provided by cloud infrastructure system 1502. These internal shared services include, but are not limited to, security and identification services, integration services, enterprise repository services, enterprise management services, virus scanning and whitelisting services, high availability backup and recovery services, services enabling cloud support, mail services, notification services, file transfer services, and the like.

[0183] In particular aspects, cloud infrastructure system 1502 may provide functionality for comprehensively managing cloud services (e.g., SaaS services, PaaS services, and IaaS services) within the cloud infrastructure system. In one aspect, cloud management functionality may include functionality for provisioning, managing, and tracking customer subscriptions received by cloud infrastructure system 1502, etc.

[0184] In one aspect, as shown, cloud management functionality is provided by one or more modules, such as an order management module 1520, an order orchestration module 1522, an order fulfillment module 1524, an order management and monitoring module 1526, and an identity management module 1528. These modules may include or be formed using one or more computers and / or servers. These computers and / or servers may be general-purpose computers, dedicated server computers, server farms, server clusters, or any other suitable arrangement and / or combination thereof.

[0185] In an exemplary operation 1534, a customer may access a client device, e.g., A customer may exchange information with cloud infrastructure system 1502 by using devices 1504, 1506, or 1508 to request one or more services offered by cloud infrastructure system 1502 and order one or more services offered by cloud infrastructure system 1502. In particular embodiments, a customer may access and order subscriptions via cloud user interfaces (UIs), cloud UI 1512, cloud UI 1514, and / or cloud UI 1516. Order information received by cloud infrastructure system 1502 in response to a customer's order may include information identifying the customer and the one or more services offered by cloud infrastructure system 1502 to which the customer wishes to subscribe.

[0186] After a customer places an order, the order information is received via the cloud UI 1512, 1514 and / or 1516.

[0187] In operation 1536, the order is stored in order database 1518. Order database 1518 may be one of several databases operated by cloud infrastructure system 1518 or in conjunction with other system elements.

[0188] At operation 1538, the order information is forwarded to the order management module 1520. In some examples, the order management module 1520 may be configured to perform billing and accounting functions related to the order, such as confirming the order and filling the order after confirmation.

[0189] At operation 1540, information regarding the order is sent to the order orchestration module 1522. The order orchestration module 1522 utilizes the order information to prepare the delivery of services and resources ordered by the customer. In some examples, the order orchestration module 1522 can use the services of the order fulfillment module 1524 to prepare the delivery of resources to support the ordered services.

[0190] In particular aspects, the order orchestration module 1522 can manage the business processes associated with each order and apply business logic to determine whether to fulfill the order. In operation 1542, upon receiving a new subscription order, the order orchestration module 1522 sends a request to the order fulfillment module 1524 to allocate resources and configure the resources needed to fulfill the subscription order. The order fulfillment module 1524 can allocate resources for the services ordered by the customer. The order fulfillment module 1524 forms a level of abstraction between the cloud services provided by the system environment 1500 and the physical implementation layer used to provide the resources to provide the requested services. In this way, the order orchestration module 1522 can be isolated from implementation details, such as whether services and resources are provisioned on-the-fly, provisioned in advance, or allocated / granted on demand.

[0191] In operation 1544, after provisioning the services and resources, the order provisioning module 1524 of the cloud infrastructure system 1502 may send a notification of the services provided to the customer operating the client device 1504, 1506 and / or 1508.

[0192] In operation 1546, the order management and monitoring module 1526 may manage and track customer subscription orders. In some examples, the order management and monitoring module 1526 may be configured to collect usage statistics for the services in the subscription order, such as storage usage, data transfer, number of users, system start times, and system stop times.

[0193] In certain aspects, cloud infrastructure system 1500 may include identity management module 1528. Identity management module 1528 may be configured to provide identity services, e.g., access management and authorization services, to cloud infrastructure system 1500. In certain aspects, identity management module 1528 may control information regarding customers who wish to use services provided by cloud infrastructure system 1502. Such information may include information validating the customer's identity and information describing the customer's permitted execution permissions for various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). Identity management module 1528 may include descriptive information about each customer, methods for accessing and modifying the descriptive information, and controls over which customers have accessed and modified the descriptive information.

[0194] 16 illustrates an example of a computer system 1600 capable of implementing various aspects of the present invention. Computer system 1600 can be used to implement any of the computer systems described above. As shown, computer system 1600 includes a processing unit 1604 in communication with multiple peripheral subsystems via a bus subsystem 1602. The peripheral subsystems may include a processing acceleration unit 1606, an I / O subsystem 1608, a storage subsystem 1618, and a communications subsystem 1624. The storage subsystem 1618 includes a tangible computer-readable storage medium 1622 and a system memory 1610.

[0195] Bus subsystem 1602 provides a mechanism by which the various components and subsystems of computer system 1600 communicate with each other as needed. While bus subsystem 1602 is shown generally as a single bus, in alternative embodiments, the bus subsystem may utilize multiple buses. Bus subsystem 1602 may have any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a Microchip bus, or an ISA bus. These buses can include the Multi-Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus. These buses can be implemented as manufactured mezzanine buses conforming to the IEEE P1686.1 standard.

[0196] Processing unit 1604, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of computer system 1600. Processing unit 1604 may include one or more processors. These processors may be single-core or multi-core processors. In particular embodiments, processing unit 1604 may be implemented as one or more independent processing units 1632 and / or 1634, each comprising a single-core or multi-core processor. In other embodiments, processing unit 1604 may be implemented as two dual-core processors integrated on a single chip. The processor may be implemented as a quad-core processing unit formed by a plurality of processors.

[0197] In various embodiments, the processing unit 1604 executes various processes in response to program code. The computer system 1600 may also include a processing acceleration unit 1606, which may include a digital signal processor (DSP), a dedicated processor, or the like.

[0198] The I / O subsystem 1608 can include user interface input devices and user interface output devices. User interface input devices can include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touchscreen integrated into a display, a scroll wheel, a click wheel, dials, buttons, switches, keypads, a voice input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices can also include motion sensing and / or gesture recognition devices, such as a Microsoft Kinect® motion sensor, which can provide input via a natural user interface (NUI) that utilizes gestures and voice commands, such as a Microsoft Xbox® 460 game controller. The user interface input device can control and interact with a force device. The user interface input device can also include an eye gesture recognition device, such as a Google Glass® blink detector. The Google Glass® blink detector detects a user's eye activity (e.g., "blinks" when taking a photo and / or selecting a menu) and converts the eye activity into input for input into the input device (e.g., Google Glass®). Furthermore, the user interface input device may include a voice recognition detection device that enables a user to interact with a voice recognition system (e.g., Siri® Navigator) via voice commands.

[0199] User interface input devices may also include, but are not limited to, three-dimensional (4D) mice, joysticks or pointing sticks, gamepads, graphics tablets, audio / visual devices such as speakers, digital cameras, digital video cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 4D scanners, 4D printers, laser range finders, and eye-tracking devices. User interface input devices may also include medical imaging input devices, such as computed tomography (CT) scanners, magnetic resonance imaging (MRI) scanners, ultrasound emission tomography (EMC) scanners, and medical ultrasound scanners. User interface input devices may also include audio input devices, such as MIDI keyboards and electronic musical instruments.

[0200] User interface output devices may include non-visual displays such as a display subsystem, indicator lights, or audio output devices. The display subsystem may be, for example, a flat-panel device using a cathode ray tube (CRT), liquid crystal display (LCD), or plasma display, a projection device, or a touchscreen. In general, when the term "output device" is used, it is intended to include all possible types of devices and mechanisms for outputting information from computer system 1600 to a user or to another computer. For example, user interface output devices include, but are not limited to, various display devices that visually convey text, images, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0201] Computer system 1600 may include a storage subsystem 1618. Storage subsystem 1618 comprises software elements, which are illustratively located in system memory 1610. System memory 1610 stores processing Unit 1604 may store loadable and executable program instructions, as well as data generated by the execution of these programs.

[0202] Depending on the configuration and type of computer system 1600, system memory 1610 may be volatile memory (e.g., random access memory (RAM)) and / or non-volatile memory (e.g., read-only memory (ROM), flash memory). Generally, RAM contains data and / or program modules that are immediately accessible to and / or presently being operated on and executed by processing unit 1604. In some implementations, system memory 1610 may be static random access memory (SRAM). In some implementations, the computer system 1600 may include a number of different types of memory, such as a basic input / output system (BIOS), which contains the basic routines that help to transfer information between elements within the computer system 1600, such as during start-up. Typically, the system memory 1610 may be stored in ROM. By way of example and not limitation, the system memory 1610 may include client applications, web browsers, mid-tier applications, relational database management systems (RDBs), and the like. Also shown are application programs 1612, program data 1614, and an operating system 1616, which may include applications such as Microsoft Windows, Apple Macintosh, and the like. ) and / or various versions of the Linux operating system, various commercially available UNIX or UNIX-like operating systems (including various GNU / Linux operating systems, Google Chrome including, but not limited to, iOS, Windows Phone, Android OS, BlackBerry Mobile operating systems such as the 15 OS and Palm OS The operating system may include:

[0203] Additionally, the storage subsystem 1618 may provide a tangible, computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by a processor, provide the above-described functionality may be stored in the storage subsystem 1618. These software modules or instructions may be executed by the processing unit 1604. The storage subsystem 1618 may also provide a repository for storing data used in accordance with the present invention.

[0204] Storage subsystem 1610 may also include computer-readable storage medium reader 1620 that may further be connected to computer-readable storage medium 1642. Computer-readable storage medium 1642 may comprehensively represent remote, local, fixed, and / or removable storage devices, as well as storage media for temporarily and / or permanently containing, storing, transmitting, and retrieving computer-readable information together with, or in combination with, system memory 1610 as needed.

[0205] Additionally, the computer-readable storage medium 1642 containing the code or portions of the code may include any suitable medium known or used in the art, including, but not limited to, storage media and communication media, such as volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting information, including RAM, ROM, electronically erasable programmable memory (ERAM), and the like. This may include tangible, non-transitory computer-readable storage media such as electronically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage devices, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer-readable media. Also, where specified, this may include intangible, transitory computer-readable media such as data signals, data transmissions, or other media usable to transmit the desired information and accessible by computer system 1600.

[0206] By way of example, computer-readable storage medium 1622 may include a hard disk drive that reads from or writes to non-removable, non-volatile magnetic media, a magnetic disk drive that reads from or writes to a removable, non-volatile magnetic disk, and a CD The computer-readable storage medium 1622 may include an optical disk drive that reads from or writes to removable, non-volatile optical disks such as ROM, DVD and Blu-ray disks, or other optical media. The computer-readable storage medium 1622 may include, but is not limited to, Zip drives, flash memory cards, universal serial bus (USB) flash drives, secure digital (SD) cards, DVD disks, digital video tapes, etc. The computer-readable storage medium 1622 may also include flash memory-based SSDs, enterprise flash drives, solid-state drives (SSDs) based on non-volatile memory such as solid-state ROM, solid-state RAM, digital SSDs based on volatile memory such as dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1600.

[0207] The communications subsystem 1624 provides an interface with other computer systems and networks. The communications subsystem 1624 serves as an interface for receiving data from other systems and transmitting data from the computer system 1600 to other systems. For example, the communications subsystem 1624 may enable the computer system 1600 to connect to one or more devices via the Internet. In certain embodiments, the communications subsystem 1624 may include a radio frequency (RF) transceiver component for accessing wireless voice and / or data networks (e.g., using cellular technologies, advanced data network technologies such as 4G, 4G, or EDGE (enhanced data rates for global evolution)), Wi-Fi (WiFi) (IEEE 802.11b), or other wireless technologies (e.g., IEEE 802.11c). E802.28 family of standards or other mobile communication technologies or any combination thereof), a global positioning system (GPS) receiver component; and / or other components. In certain aspects, the communications subsystem 1624 can provide a wired network connection (e.g., Ethernet) in addition to or instead of a wireless interface.

[0208] Also, in certain aspects, the communications subsystem 1624 can receive incoming communications in the form of structured and / or unstructured data feeds 1626, event streams 1628, event updates 1630, etc., on behalf of one or more users who may be using the computer system 1600.

[0209] As an example, the communications subsystem 1624 may provide Twitter feeds, Facebook updates, Rich Site Summary (RSS) feeds, and other similar services. The data feeds 1626 may be configured to receive unstructured data feeds, such as web feeds, in real time from users of social media networks and / or other communication services, and / or to receive real-time updates from one or more third-party sources.

[0210] Additionally, the communications subsystem 1624 may be configured to receive data in the form of a continuous data stream, which may include an event stream 1628 of real-time events that may be continuous or may be essentially unbounded with no clear ends and / or event updates 1630. Examples of applications that generate continuous data include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

[0211] The communications subsystem 1624 may also be configured to output structured and / or unstructured data feeds 1626, event streams 1628, event updates 1630, etc. to one or more databases that may communicate with one or more streaming data source computers coupled to the computer system 1600.

[0212] The computer system 1600 may be one of a variety of types, including a handheld mobile device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head-mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or other data processing system.

[0213] Because computers and networks are constantly evolving, the description of the illustrated computer system 1600 is intended only as a specific example. Many other configurations are possible, having more or fewer components than the system shown. For example, customized hardware may also be used, and / or particular elements may be implemented in hardware, firmware, software (including applets), or a combination. Additionally, connections to other computing devices, such as network input / output devices, may be utilized. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will appreciate other means and / or methods for implementing various aspects.

[0214] In the foregoing specification, embodiments of the invention have been described with reference to specific embodiments thereof, but those skilled in the art will recognize that the invention is not limited thereto. Various features and aspects of the above-described invention may be used individually or together. Moreover, embodiments may be utilized in any environment and application beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

1. 1. A method for propagating traces throughout a distributed software application, comprising: recording tracking data of a web page from an origin server, the web page being executed by a web browser; determining on the web browser that the web page from the original server requires a request to an external server located outside the domain of the original server; retrieving a denial list on the web browser indicating whether the external server is denied from following headers in requests from the original server; retrieving a permission list on the web browser indicating whether the external server is allowed to follow headers in requests from the original server; determining whether to allow the external server to track headers in the request by querying the external server, the query being based on a negative result of the search of the deny list or the allow list; updating the permission list on the web browser to indicate that the external server is allowed to follow headers in requests from the original server; inserting a tracking header into the request based on a result of the query; sending the request including the tracking header from the web browser to the external server, wherein the external server is configured to record tracking data based on the tracking header.

2. determining on the web browser that the web page from the original server requires an additional request to the external server; determining that the cache contains an entry corresponding to the external server; 2. The method of claim 1, further comprising: obtaining a response corresponding to the entry from the cache; and providing the response to the add request.

3. If the original server does not implement CORS (Cross-Origin Resource Sharing), 2. The method of claim 1, further comprising: in response to determining that the tracking header is not required, inserting the tracking header into the request and sending the request including the tracking header.

4. The method of claim 1 , wherein the request is a Hypertext Transfer Protocol (HTTP) request.

5. The method further includes receiving performance measurements of the span from the external server; the span includes the actions performed to service the request; The method of claim 1 , wherein the performance measures include one or more of: (i) a number of processing cycles corresponding to the execution of the operation; or (ii) an execution time of the operation.

6. the request to the external server is triggered by the execution of an event initiated by an interaction with the web page; The method further includes automatically recording additional spans based on the execution of the event; The method of claim 5 , wherein the span is a child span of the additional span.

7. receiving notification from the external server that the request was denied; adding the external server to the denied list on the web browser; and resending the request from the web browser to the external server without the tracking header.

8. 1. A system comprising: a non-transitory computer-readable medium for storing computer-executable program instructions; at least one processor communicatively coupled to the non-transitory computer-readable medium for executing the computer-executable program instructions; The computer-executable program instructions include: instructions for recording tracking data of a web page from an origin server, the web page being executed by a web browser; instructions for determining that the web page from the origin server requires a request to an external server located outside the domain of the origin server; instructions for retrieving a permission list indicating whether the foreign server is permitted to follow headers in requests from the original server; instructions for inserting a tracking header into the request based on a negative result of the search; and instructions for sending the request including the tracking header to the external server, wherein the external server is configured to record tracking data based on the tracking header.

9. The computer-executable instructions include: instructions for receiving notification from the external server that the request was denied; instructions on the web browser for adding the external server to a denied list; and instructions for sending the request from the web browser to the external server without the tracking header.

10. The system of claim 8 , wherein the request is a Hypertext Transfer Protocol (HTTP) request.

11. The computer-executable instructions further include instructions for receiving performance measurements of spans from the external server; the span includes the actions performed to service the request; The system of claim 8 , wherein the performance measures include one or more of: (i) a number of processing cycles corresponding to the execution of the operation; or (ii) an execution time of the operation.

12. the request to the external server is triggered by the execution of an event initiated by an interaction with the web page; the computer-executable instructions further include instructions for automatically recording additional spans based on the execution of the event; The system of claim 11 , wherein the span is a child span of the additional span.

13. The computer-executable instructions include: instructions for receiving notification from the external server that the request was denied; instructions for adding the external server to a denial list; and instructions for resending the request to the external server without the tracking header.

14. 1. A non-transitory computer-readable medium for storing computer-executable program instructions that, when executed by a processor, perform the following operations: The operation is recording tracking data of the web page from the original server, Web pages are executed by a web browser, determining on the web browser that the web page from the original server requires a request to an external server located outside the domain of the original server; retrieving a denial list on the web browser indicating whether the external server is denied from following headers in requests from the original server; retrieving a permission list on the web browser indicating whether the external server is allowed to follow headers in requests from the original server; determining whether to allow the external server to track headers in the request by querying the external server, the query being based on a negative result of the search of the deny list or the allow list; updating the permission list on the web browser to indicate that the external server is allowed to follow headers in requests from the original server; inserting a tracking header into the request based on a result of the query; sending the request including the tracking header from the web browser to the external server, wherein the external server is configured to record tracking data based on the tracking header.

15. The operation is determining on the web browser that the web page from the original server requires an additional request to the external server; determining that the cache contains an entry corresponding to the external server; 15. The computer-readable medium of claim 14, further comprising: obtaining a response corresponding to the entry from the cache; and providing the response to the add request.

16. The operation is performed when the original server uses CORS (Cross-Origin Resource Sharing).

15. The computer-readable medium of claim 14, further comprising, in response to determining not to execute, inserting the tracking header into the request and sending the request including the tracking header.

17. The method of claim 1 , wherein the request is a Hypertext Transfer Protocol (HTTP) request.

18. The operations further include receiving performance measurements for the span from the external server; the span includes the actions performed to service the request; 15. The computer-readable medium of claim 14, wherein the performance measures include one or more of: (i) a number of processing cycles corresponding to execution of the operation; or (ii) an execution time of the operation.

19. the request to the external server is triggered by the execution of an event initiated by an interaction with the web page; The operations further include automatically recording additional spans based on the execution of the event; The computer-readable medium of claim 18 , wherein the span is a child span of the additional span.

20. The operation is receiving notification from the external server that the request was denied; adding the external server to the denied list on the web browser; resending the request from the web browser to the external server without the tracking header; The computer-readable medium of claim 14 , further comprising:

Images