Insertion of Smart Distributed Tracking Context

Abstract

The disclosed system relates to propagating tracing throughout a distributed software application. In one example, the application records tracing data for a web page from an origin server. The application determines on a web browser that the web page from the origin server requires a request to an external server located outside the origin server's domain. The application determines whether to allow the external server to trace headers in the request by querying the external server. The application updates a permission list on the web browser to indicate that the external server is allowed to trace headers in the request from the origin server. The application inserts a tracking header into the request based on the result of the query. The application sends the request including the tracking header from the web browser to the external server. The external server is configured to record tracing data based on the tracking header.

Description

Technical Field

[0001] Reference to Related Applications

Background Art

[0002] Background With the further progress of web-based applications, conventional tracking applications may not be able to capture accurate telemetry data of servers, platforms, or threads. The disclosed solutions overcome these drawbacks and facilitate the improvement of telemetry capabilities and analysis.

Summary of the Invention

[0003] Summary In one aspect, a method for propagating a trace throughout a distributed software application includes recording trace 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 a 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 to deny an external server from tracking headers in a request from the original server. The method further includes searching, on the web browser, a permit list indicating whether to permit an external server to track headers in a request from the original server. The method further includes determining, by querying the external server, whether the external server is permitted to track headers in the request, the query being based on a negative result of the search of the deny list or the permit list. The method further includes updating, on the web browser, the permit list to indicate that the external server is permitted to track headers in a request from the original server. The method further includes inserting a trace header into the request based on the result of the query. The method further includes transmitting, from the web browser to the external server, a request including the trace header, the external server being configured to record trace data based on the trace header.

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

[0005] In one aspect, the method further includes inserting a trace header into the request and transmitting a request including the trace header in response to a determination that the original server is not implementing CORS (Cross-Origin Resource Sharing).

[0006] In one aspect, the request is a Hypertext Transfer Protocol (HTTP) request. In one aspect, the method further includes receiving, from an external server, performance measurement values of a span. The span includes operations executed to service the request. The performance measurement values include one or more of (i) the number of processing cycles corresponding to the execution of the operation or (ii) the execution time of the operation.

[0007] In one aspect, the request to the external server is caused by the execution of an event initiated by interaction with a web page. The method further includes automatically recording additional spans 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, from the external server, a notification that the request has been rejected. The method further includes adding the external server to a rejection list on the web browser. The method further includes resending, from the web browser to the external server, a request that does not include a tracing header.

[0009] The above method can be implemented as a tangible computer-readable medium and / or can operate within a computer processor and associated memory.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

DETAILED DESCRIPTION OF THE INVENTION

[0011] Detailed Description The technology disclosed in this specification provides a solution for automatically providing a telemetry function to enterprise applications. Telemetry refers to collecting performance reporting data regarding the runtime execution of software. Examples of such data include the usage frequency of specific functions on a web page or application, measured startup or execution times, detection of process crashes, failure information, and user experience. Telemetry data can be collected at the application level or at a finer level such as runtime metrics regarding the completion time of each process on a web page. The disclosed solution can access telemetry data using an application programming interface (API) function.

[0012] As described above, existing solutions have drawbacks. For example, some existing solutions require introducing or linking to a manual tracking library and adding one or more function calls to the code portions where instrumented data is desired. Furthermore, with such solutions, developers need 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 and server calls in the code 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 tools can automatically insert a tracing function into enterprise applications. The tracing function can automatically trace operations such as user interactions, page navigation, and server calls, and group related logical transactions to enable end-to-end tracing from a user's click on a web page that implements a (heterogeneous or other) distributed server system including backend services.

[0014] In another aspect, the disclosed system enables prioritization of spans and messages associated with the spans, which in some cases minimizes network congestion caused by large amounts of instrumented data. For example, a lower priority can be specified for a particular span at runtime or before execution. This way, instrumentation does not measure the performance of a particular span but collects data for child spans that are of more interest to the developer.

[0015] In yet another aspect, the disclosed solution enables developers of web-based applications to obtain instrumentation details regarding one or more processes being executed as part of an enterprise application, regardless of whether the one or more processes include multiple threads. At runtime of the application, the telemetry framework facilitates instrumentation of various processes, threads, and servers. In this way, the instrumentation environment is maintained across the threads, resulting in more fine-grained instrumentation data.

[0016] In another aspect, the disclosed system facilitates the overall remote measurement of a distributed system that may not automatically permit the instrumentation indicated by a tracing header due to security requirements or other reasons, including distributed servers. More specifically, certain aspects can automatically discover protocol support and, based on the protocol support, adjust the insertion of tracing information for different calls. Thus, the disclosed system can obtain detailed remote measurement data of processes running on remote servers, particularly those accessed by cross-domain requests. Such servers may be operated by different entities within different domains.

[0017] Figure 1 shows an example of a system for automatically instrumenting an enterprise application using remote measurement, according to one aspect of the present disclosure. Figure 1 shows a developer computing device 110, an end-user computing device 130, a network 150, and servers 140a - n. In the example shown in Figure 1, the developer computing device 110 constructs an instrumentation application 120 and deploys the instrumentation application 120 to server 140a. Server 140a provides this application to the end-user computing device 140. Figure 2 shows an example of a process used by an instrumentation application to obtain remote measurement data. Figure 3 shows an example of an instrumentation application. Examples of suitable computing devices for the developer computing device 110 and the end-user computing device 140 include the client computing devices 1402, 1404, 1406, and 1408 shown in Figure 14, and an example of a suitable server includes the server 1412 shown in Figure 14.

[0018] When executing or in relation to the execution of the instrumented application 120, the end-user computing device 140 can connect to one or more servers 140b~n to obtain different resources (e.g., images, scripts, etc.) and / or execute instrumented functions. When executing or after executing the instrumented application 120, the telemetry data 122 is sent to the developer computing device 110 for analysis.

[0019] The developer computing device 110 includes one or more of a developer integrated development environment (IDE) 112, developer backend tools 114, a console 116, and the telemetry data 122. The developer IDE 112 is a graphical development tool that provides functions such as compilation, linking, debugging, tracing, or other functions. The developer backend tools 114 can include one or more compilers, linkers, debuggers, simulators, etc. The console 116 is used to view the telemetry data 122 obtained by the execution of the instrumented application 120. As shown in the figure, the telemetry data 122 includes data indicating that it took 0.5 seconds to execute a specific web page on "Server 1", it took 0.4 seconds to load an image on "Server 2", and a button click caused a 0.2-second process.

[0020] Servers 140a - n can be configured to perform the same function, similar functions, or different functions. For example, servers 140a - n can operate as a distributed server system. In another example, servers 140a - n can be a web server, a file server, or other servers that can provide services to one or more components from a web page or receive a database query and provide results. In some cases, servers 140a - n may be controlled by different entities (companies or individuals) and / or may be located in different locations. Thus, the specific embodiments described herein relate to obtaining remote measurement data from different servers via span context propagation. The developer computing device 110, the end - user computing device 140, the network 150, and servers 140a - n may be connected via one or more connections, for example, via network 150. Examples of network 150 include wired networks, wireless networks, 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 an instrumentation function. For example, the tracking application 136 collects remote measurement data that can be exported to an external device periodically or on demand. Examples of remote measurement data include the usage frequency of specific features, measured values of startup time or execution time, detection of process crashes, fault information, and user types.

[0022] In one example, a software developer constructs a custom web-based application using a developer IDE 112 and developer backend tools 114. Specifically, software tools running on a developer computing device 110 insert code (e.g., tracing code) that provides a remote measurement function and generate an instrumented application 120. In some cases, the instrumented application 120 may be sent directly from the developer computing device 110 to an end-user computing device 140. In other cases, the instrumented application 120 may be sent directly to 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 the application from, for example, server 140a via a 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 executes a remote measurement function, which instruments actions directly caused by the user's interaction with the application (e.g., clicks, reloads) or indirectly caused (e.g., by loading an image linked to a page). In this way, more detailed remote measurement information can be obtained than with previous solutions. Remote measurement data 122 is collected by one or more servers 140a - n.

[0024] As described above, certain aspects relate to obtaining telemetry information from enterprise applications. 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 trace identifier and a span identifier. Thus, a first process may have a first span, and a second process may have a second span. When the second process is called 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 across different processes facilitates more detailed instrumentation.

[0025] Certain drawings and related descriptions further illustrate certain aspects. For example, FIGS. 4-5 relate to different aspects of span instrumentation. FIGS. 6-8 relate to the priorities of various spans during instrumentation. FIGS. 9 and 10 relate to thread instrumentation. FIGS. 11-13 relate to propagating span contexts between different devices. FIGS. 14-16 show various computing systems in which an instrumentation function can be implemented.

[0026] Instrumentation of Web-Based Enterprise Applications FIG. 2 shows an example of a process 200 used to collect telemetry data in accordance with one aspect of the present disclosure. Process 200 may be executed by one or more of developer computing device 110 and servers 140a-n.

[0027] In block 202, process 200 includes providing a web page application to a web browser on a client device. For example, server 140a provides web application 134 to web browser 132. Web application 134 includes a tracing application 136 for providing instrumentation. Web application 134 is instrumented to include tracing application 136 prior to process 200.

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

[0029] In block 206, process 200 includes instantiating a tracing application based on the start of the web page application. Tracing application 136 is configured to record tracing data for web application 134.

[0030] In block 208, process 200 includes detecting an event initiated by interaction with the web page application. Web application 134 continues execution and the event is triggered. Examples of events include user interface interactions, clicks, navigations, mouse-overs, refreshes, etc. Additionally, the event may be a Representational State Transfer (REST).

[0031] In block 210, process 200 includes automatically recording the start of a span based on the detection, and this recording associates the span with the tracing application. Tracing application 136 causes the recording of a span corresponding to the event.

[0032] In block 212, process 200 includes performing operations corresponding to events. Web browser 132 executes code corresponding to events such as loading an image or a resource.

[0033] In block 214, process 200 includes automatically recording the end of a span based on the completion of operations corresponding to events. When the code referenced in block 212 is completed, tracing application 136 records the end of the span. The collected data can include the executed processing cycles, the execution time of the span, the memory consumption, and the like.

[0034] As described herein, certain aspects can measure data associated with a span that crosses multiple servers or processing threads or a span that uses multiple separately identifiable operations. For example, the execution of block 210 can create additional spans each providing more detailed information. For example, tracing application 136 can create a first child span corresponding to a first operation and a second child span corresponding to a second operation. The first child span and the second child span can be child spans of the span.

[0035] Continuing with the example, tracing application 136 automatically records the end of the first child span based on the completion of the first operation and automatically records the end of the second child span based on the completion of the first operation. Thus, tracing application 136 obtains not only the span but also more detailed information. 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] Figure 3 shows an example of an instrumented application for generating a span context according to a particular aspect of the present disclosure. The instrumented application may be built and instrumented by a software development tool such as a developer IDE 112 and may be executed by a browser running on a computing device. Figure 3 shows 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 shown in Figure 3, a web application 302 with a tracing function is executed on a web browser and provides one or more web pages by communicating with a server 340. The web application 302 sends one or more queries 350 and receives one or more responses 352 in response thereto. Although Figure 3 is described with respect to web pages, the flows and components may be executed by a mobile application or other application.

[0039] Web application 302 shows a flow 310 that includes a web page 312 having components 314, 316, and 318. These components may be mobile applications, web applications, service connections, business objects, or processes. Each component can perform different functions as part of the web page. Components 314, 316, and 318 can each cause component events 315, 317, and 318. Each of component events 315, 317, and 318 triggers one or more events in a telemetry runtime 320, thereby causing one or more operations to be performed while recording the events.

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

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

[0042] In another example, the remote measurement runtime 320 can initiate an action chain 333 that corresponds to updating a part of the UI. For example, the action chain may be a set of one or more individual or sequential actions 336. Each action chain may be triggered by an event. For example, a user click can trigger navigation to a page corresponding to the location on the browser that received the user click (e.g., a hyperlink, a navigation button, etc.). The action chain can define input parameters and local variables available within the scope of that action chain and can include parameters and variables within the scope of the application. The remote measurement runtime can determine that one or more REST calls 338 to the server are required to update a part 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 can include an insertion span context. Accordingly, the server 340 sends back a response 352 that includes additional HTTP headers to the web application 302. The web application 302 uses this response to complete the actions caused 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 has a predetermined life cycle, similar to each application running on a browser. Each life cycle event, such as entering or exiting a page, can trigger an action chain. All data input into a mobile application or web application is based on the REST protocol. This data can be obtained from custom business objects or business objects provided by a service connection. Actions and variables control the sending of data to and from REST endpoints within a mobile application or web application. An action chain has a clearly defined context and contract. The action chain orchestrates its underlying actions and adjusts the state flow and execution path. The action chain can define input parameters and local variables that are only available within its context. An example of an action chain is to make a REST call (first action) and obtain the result and store it in a variable (second action). An action can export a new state to its context. This is only available to future actions along the same action chain. An action chain can be created within the context of a page or application and exists within the scope of the page or application. The action chain has a predetermined interface and contract and can be called by an event trigger using its ID.

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

[0046] The common analysis ingestion unit 324 can ingest log data from the remote measurement API 322. In one example, the common analysis ingestion unit 324 can ingest log data from a cloud infrastructure object storage device using a REST API. In one example, the common analysis ingestion unit 324 can determine the storage location of the collected log data. The common analysis ingestion unit 324 can ingest various log data at the user level, group level, or organizational level. In some examples, the common analysis ingestion unit 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 remote measurement API 322. The client log ingestion endpoint 326 can store the log data, convert the log data into various visualization data, or perform additional processing on the log data.

[0048] Generally, 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. A span can have child spans that represent more fine-grained operations than the corresponding parent span, and these child spans can in turn have child spans that represent more fine-grained operations than the first child span. A series of spans originating from a single parent can be considered a trace. A span includes metadata about the operation being measured, along with some identifying information. In the case of an application that has an operation that makes an external process call (e.g., a client application that makes a call to a REST service), the span context can be propagated with the outgoing request (e.g., in the form of a special HTTP header). The receiving application or server can extract the span context and use it to create a child span of the parent span on the client. The tracing client API has the ability to output span information (one each at the start and end of the span) to various backend servers in the form of log messages.

[0049] An exemplary 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 call an event handler. The event handler issues a REST (defined) request that is processed by a REST service. The REST service returns a response to update the user interface of the application. This example is shown in Figure 4.

[0050] Figure 4 shows an example of a span hierarchy according to one aspect of the present disclosure. Figure 4 shows a span hierarchy 410 and a span timeline 430. Both the span hierarchy 410 and the span timeline 430 describe the relationships between various spans within the span context. In the span hierarchy 410 or the span timeline 430, a parent span and a child span are related. As shown, 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, the web browser 132 receives a user click 412. The user click 412 causes the creation of span A 424. In response, the web browser 132 starts the event represented by the user click action and triggers the operation of the event handler 414. The web browser 132 can use the event handler 414 to determine one or more actions to take in response to the event detected based on the received user click. The instantiation of the event handler 414 generates span B 434, which is a child span of span A 424.

[0052] Continuing with this example, the event handler 414 generates a REST request 416 and a processing response 418. Since the response processing of the REST request is performed 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. The processing of the REST response updates the user interface (UI). Thus, as shown, the REST request 416 causes the server to process the request and update the UI 422. Since the UI is not updated until the server processes the request, span D 440 (corresponding to the server processing request) starts and completes before span F 442 (corresponding to the UI update). Thus, span D 440 represents the processing of the request by the server.

[0053] As can be seen from the drawings, span D440 is generated between spans C436, and span F442 is generated between spans E438. Span E438 represents the browser processing of the response from the server (corresponding to the REST request from the browser). Span F442 represents the browser updating the user interface based on the processing of the response from the server. Spans C436 and 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] The span context as described with respect to FIG. 4 is managed by an instrumentation library, and this instrumentation library is added to the custom enterprise application by a software development tool (e.g., developer IDE112).

[0055] FIG. 5 shows a tracing component of an instrumentation application used to generate span contexts and logs according to a particular aspect of the present disclosure. In the example shown in FIG. 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 a developer IDE112 or may be customer-developed software. Code for supporting instrumentation is automatically added by the developer IDE112.

[0056] The end - user computing device 520 includes one or more modules, such as a web application 522 (or any other consumer client), a tracing module 524, a tracing interface 526, a span interface 528, a tracer 530, a span 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 the active span to the span stack 536. The server 560 includes one or more modules, such as a trace collection servlet 562.

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

[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 the application context and returns a Tracer options object. The API call activeTracer returns the global tracer object. For example, the API call inject() inserts a span into a request (e.g., to the server). A span can be extracted using the returned API call extract().

[0059] A plurality of spans can be generated. For example, the tracer 530 can create a span representing an event or thread of the web application 522. The tracer 530 can create child spans as needed (e.g., as described with respect to FIG. 4) based on the specific operation where the tracer creates the span. As further discussed herein, the instrumented application can obtain information from different servers that service requests triggered by events of different threads and / or applications.

[0060] The web application 522 can control the tracer or receive an injection for a span using the tracing interface 526. Also, the tracer can monitor, write to, or read from a span stack 536 that can cache or utilize one or more spans to monitor a parent span, or can insert a span context into a newly created span, such as span 532. The web application 522 can utilize the span interface 528 to send span-related information to the span recording library 534. The compression layer 544 can compress to minimize the span-related information before sending it to the trace collection servlet 562. Exemplary compression techniques used by the 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. Next, the server 560 can stream the span logs on the end-user computing device 520 and execute a trace collection servlet 562 that collects traces from the sender task 548.

[0061] Span Priority Aspects of the present disclosure relate to the instrumentation of web applications. In some cases, it can be difficult to manage or prioritize a large number of spans due to many events, calls that resulted in spans and / or child spans. In such cases, certain aspects provide a function for reducing the payload of spans for the purpose of reducing the capacity of span logs and streamlining telemetry data.

[0062] In the default mode, instrumentation can capture all spans and send messages to the browser console and any service based on all spans. However, in some cases, there may be an unmanageable number of span messages, obscuring the relevant telemetry data of interest. Therefore, spans can be filtered based on one or more criteria.

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

[0064] FIG. 6 is a diagram showing an example of a tracing architecture used to manage backpressure caused by instrumenting a span according to a particular aspect of the present disclosure. FIG. 6 shows a tracing architecture 600 that includes 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, the span controller 606 manages and prioritizes spans based on one or more parameters. The application runtime 602 is similar to the telemetry runtime 320 described with respect to FIG. 3 and can perform operations similar to those of the telemetry runtime 320.

[0065] In a first example, the tracer implementation 604 starts a span of the application runtime 602. The tracer implementation 604 can communicate span monitoring data to the browser span recording library 634 while executing the span. The browser span recording library 634 outputs span log data to the console stream 610. These span log data may be displayed on the browser of the end-user device. Also, the browser span recording library 634 can output the span log data to the CLS stream 612. The CLS stream 612 may be a stream of log data that is transmitted to the client recording service 614. The client recording service 614 can store the log data for additional processing.

[0066] In another example, the tracer implementation 604 receives a span created by the span controller 606. Also, the tracer implementation 604 can return (e.g., end) the span when the event that generated the span is complete. Further, the tracer implementation 604 can receive a command from the application runtime 602 to end the span. 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 indicating the spans to 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, the data for that span and related child spans is not returned.

[0067] In yet another example, the tracing architecture 600 generates an initial set of spans, as described, for example, 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 or may not be measured, or pruned to a subset, based on programmer or user input. For example, a threshold priority can be set. At runtime, any span with a priority greater than the threshold priority is converted to a proxy span and not measured.

[0068] The proxy span maintains a span tree indicating the relationship between the parent span and child spans. However, since the proxy span is not measured, the span controller 606 does not obtain runtime instrumentation measurements for the proxy span, but does obtain measurements for any child spans that are not proxy spans. The proxy span preserves the relationship between the parent span and child spans, so the tree structure is maintained even if a particular proxy span in the tree does not have instrumented data. Thus, in this way, the span tree can be pruned to maintain span data that is interesting to the developer. FIG. 7 provides an example of using a proxy span.

[0069] FIG. 7 is a diagram showing an example of a span hierarchy without priorities and a span hierarchy with priorities according to a specific aspect of the present disclosure. Specifically, FIG. 7 shows a span hierarchy 700 that does not use priorities and a span hierarchy 730 that uses priorities.

[0070] In the span hierarchy 700, span A702 is the parent span of span B704. Also, span B704 is the parent span of span C706, span D708, and span E710. In the span hierarchy 700, data for all spans, that is, span A702, span B704, span C706, span D708, and span E710, is collected.

[0071] In contrast, the span hierarchy 730 shows a span hierarchy with priorities. The span hierarchy 730 includes span A732 and span proxy B734 which is a child span of span A732. Span A732 has a priority of 1. Span proxy B734 has a priority of 2 which is greater than the priority of span A732. In this example, the default priority is set to 1. Since the instrumented data from span B is not required as indicated by the priority of span B being 2 which is greater than the default priority, span proxy B734 is converted from the original span B.

[0072] As a result, span C736, span D738, and span E740 all have a priority of 1 and are not pruned, but since the original parent span, span B, is a proxy, they are marked as having the parent span A732. Thus, at runtime, the instrumented data of span A732, span proxy B734, span D738, and span E740 is collected.

[0073] From an implementation perspective, the SpanOptions object used to create a span includes a priority field. In some cases, when the priority of a span is not specified, 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 successfully. When a span is proxied, a SpanProxy object is generated instead. Similar to any other span object, the SpanProxy object can interact, but the fields and methods of the SpanProxy delegate to the active span. For example, in the above example, SpanProxy B734 corresponds to the SpanProxy object, and its methods and fields default to corresponding to the object of span A732. Thus, since the applications involved always receive a span, there is no need to adjust the application runtime environment.

[0074] In some implementation forms, the priority value is represented by a positive number, and a higher value indicates a 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 form, any span with a priority higher than the threshold priority is converted to a proxy span. However, different ranking methods are also possible. For example, a higher value indicates a higher priority. In some cases, the priority may be represented as an alias. For example, "Critical" may be assigned to level 0, "High" may be assigned to level 1, "Medium" may be assigned to level 2, and "Low" may be assigned to level 3. By default, the root span may have a priority of 1, and child spans may have a priority of 2.

[0075] In some cases, the priority threshold may be modified by a fleetwide sampling algorithm. This algorithm requires assigning a percentage and a random number selected to fall within that percentage to each priority. Typically, a higher percentage will be assigned to higher priorities in order to ensure that most application users send a minimal amount of telemetry (for capacity and performance reasons). A smaller percentage 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 can 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 occur when a span is found to have interesting instrumented data. For example, priority boosting can be performed when the duration is too long, the span has no child spans that form a majority of the span's duration, or an error has occurred.

[0077] The tracing 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 "ingest service backpressure"). For example, the ingest 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 an excessive request and "413" indicates that the payload is too large). Thus, the system can respond by dynamically changing the priority threshold so that subsequent requests send fewer logs.

[0078] The following table shows exemplary priorities for spans of different events.

[0079]

Table 1

[0080] Figure 8 shows an example of a process 800 for ranking spans according to a particular aspect of the present disclosure. The process 800 may be executed by one or more of the developer computing device 110 and the servers 140a - n.

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

[0082] In block 804, the process 800 includes associating the event with a first span. The developer IDE 112 configures a tracer to record trace information based on the execution of a first set of operations caused by (i.e., corresponding to the execution of) the event. The tracer is configured to obtain a first performance measurement of the first span. This span refers to the first set of operations. Examples of performance measurements include cycles, processing time, memory usage, latency, etc.

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

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

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

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

[0087] In 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 instrumented 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 thread Conventionally, web-based applications can use the main browser thread to perform user interface operations. For example, with improvements in asynchronous JavaScript programming, the main browser thread can create responsive applications. However, in certain long-running background processes, application developers can choose to use the Web Worker API that enables creating actual native threads for executing application logic.

[0089] However, in a standard distributed tracing application, a separate thread (e.g., a thread via a worker API) is considered to be outside of the process or at least in a different scope than the tracer running on the main thread. Therefore, it is necessary to configure the tracer within the code to operate on the worker thread.

[0090] In contrast, certain aspects can automatically instrument threads. For example, a tracing worker class abstracts the task of configuring the tracer within the application code by encapsulating the tracer into a subclass of a 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. This application code is automatically made telemetry - compliant. Subsequently, the tracing worker can be configured to override the native web worker API as needed. This causes the application to become a tracing worker that wraps the standard worker functionality when creating the worker thread.

[0091] The advantages of this approach include clear behavior for developers and users and enabling telemetry of code outside of threads while maintaining the span hierarchy between threads. Further, since the configuration data of each thread automatically inherits the configuration of the main thread, there is no need to duplicate the configuration data.

[0092] FIG. 9 is a diagram showing an example of a distributed tracing environment including a tracing worker client according to a particular aspect of the present disclosure. FIG. 9 shows a main browser thread 910 and a worker thread 920. In the example shown in FIG. 9, the main browser thread 910 calls the worker thread 920, and the worker thread 920 returns the instrumented data to the main browser thread 910.

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

[0094] The worker thread 920 can run in an environment different from the main browser operations such as a browser window. In this way, for example, if the tasks executed by the worker thread 920 are time-consuming or complex, a more responsive user interface can be maintained.

[0095] The tracing worker client 917 can manage threads such as the worker thread 920, for example, by configuring the worker thread 920 using the tracing worker sim code 922. Adding the tracing worker sim code 922 facilitates obtaining the span context and the tracing context. The wrapper constructor is wrapped with a child span of the context of the current span, if applicable. The worker thread is initialized with an application script to execute when created and has a communication port.

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

[0097] If successful, the tracing worker client 917 acquires the active span context and tracer configuration and sends them to the SIM. The SIM receives the tracer configuration, initializes the tracer, and creates a child span of the received span context. The SIM then inserts the application worker code and removes the message handler. Next, the application thread and the worker thread perform various operations.

[0098] Once created, the worker thread 920 can create a tracer and copy one or more configuration parameters from the worker thread 920 to the tracer 925. Also, the worker thread 920 can extract the span context associated with the span created by the main application 912. The worker thread 920 can create a child span of the span created by the main application 912 and containing the span context. During the execution of the application worker script 924 by the worker thread 920, the child span may be created and captured by the tracer 925 for further processing. The worker thread 920 can communicate to the tracing worker client 917 that the application worker script 924 has completed successfully. The tracing worker client 917 can then communicate to the main application 912 that the worker thread has been successful. The main application 912 can communicate to the tracer 914 that the span has been completed and can end the span.

[0099] In one example, data may be sent between a worker thread and a main application via a message system where both sides send messages. The messages may be sent using a method such as postMessage(), and the response to the received message may be communicated using an onmessage event handler such that the message is included in the data property of the message event. In this particular configuration, rather than being shared, the message data is copied between the main application and the worker thread. The worker thread can generate a helper worker (e.g., a helper thread) where the worker is hosted within the same origin as the parent page.

[0100] The following exemplary code shows how a developer can use a tracing worker thread.

[0101]

Number

[0102] FIG. 10 shows an example of a process 1000 for instrumenting a thread, in accordance with a particular aspect of the present disclosure. Process 1000 may be executed by one or more of a developer computing device 110 and servers 140a - n.

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

[0104] In block 1004, process 1000 includes creating a global tracer configured to record trace data of the web page application from the web page application. Similar to that described with respect to block 206 of process 200, a global tracer is created.

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

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

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

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

[0109] Instrumentation of the span of the entire server call FIG. 11 shows an example of a process 1100 for propagating tracing throughout a distributed software application, according to a particular aspect of the present disclosure. Process 1100 may be implemented by a computing system such as an end-user computing device 140 and may be part of a tracing application 136. Process 1100 includes creating an appropriate request to a remote server to obtain a resource (e.g., a web page, an image, or a file). The request may be a Hypertext Transfer Protocol (HTTP). For illustrative purposes, process 1100 is described in conjunction with FIG. 12.

[0110] FIG. 12 is a diagram showing an example for propagating a span context across the entirety of services of a distributed system according to a particular aspect of the present disclosure. Examples of services include REST calls to a server. For example, rendering a particular web page may require multiple REST calls each having a particular purpose. A first REST call may cause a web browser to render the page, a second REST call may be located on a server (REST endpoint) and obtain an image to be displayed on the page, or a third REST call may be a database query for obtaining information such as the name of an employee's manager. Also, 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 request information from a server other than the original server (e.g., a server providing a 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 executed after determining that a request from the original server for a web page requires a request to an external server located outside the domain of the original server. The determination may be compatible with cross-origin resource sharing (CORS).

[0112] Figure 12 includes service 1210 and service 1220. Service 1210 can execute a browser, and service 1220 executes on a server specified by a REST endpoint. Service 1210 includes a parent span 1212, a child span 1214, and a child span 1216. Service 1220 includes a child span 1222 after a REST call. In one example, child spans 1214 and 1216 represent processing that needs to be done before the REST call. The context of child span 1222 is sent to the server via the network. Next, the server can propagate that span context to another server that made such a request. Each server collects its own traces and sends them to an appropriate location.

[0113] As described, a span context includes a root span or a trace identifier, and the root span or trace identifier indicates the overall purpose to be achieved (e.g., load a page). A complete span context typically includes a trace identifier (ID) which is 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 each respective parent.

[0114] Returning to Figure 11, in block 1101, process 1100 is started. The tracing application 136 can record the tracing data of the web page from the original server. The tracing data can include previous requests, successes and failures of these requests. The tracing application 136 can form a rejection list including destination servers that reject requests including tracing headers and / or an approval list including destination servers that approve requests including tracing headers from the tracing data. Optionally, process 1100 is executed when an inter-domain request is detected.

[0115] Instrumentation can be achieved by inserting a tracing header into the server request to request a resource (e.g., as part of loading a web page). However, tracing headers are often rejected, for example, for security reasons. Thus, process 1100 includes avoiding such security measures to facilitate telemetry. For example, considering FIG. 12, service 1210 runs on the original server and service 1220 runs on an external server. Thus, the parent span 1212 (e.g., of the first process) runs on the original server. Tracing application 136 can analyze not only the parent span 1212 but also the child spans 1214 and 1216 derived from the child span 1214 using the techniques disclosed herein. However, as shown, the parent span 1212 is also related to the child span 1222 that runs on service 1220 (and thus on an external server). Since process 1100 can propagate the span context from the parent span 1212 to the child span 1222, instrumentation can be facilitated.

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

[0117] In block 1103, process 1100 includes determining whether a request for a resource is idempotent. Being idempotent means that the intended effect of multiple identical requests to the server by that method is the same as the effect of a single such request. Thus, if the intended effect of a server 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] In block 1104, process 1100 includes determining whether the destination of the request is a server on the rejection list. For example, tracking application 136 determines whether an external server rejects a tracking header for a request from the original server by searching the rejection list. The server rejection list includes servers identified as rejecting (e.g., created by a request identified in block 1112 of process 1100) extra headers. The rejection server list is useful because when choosing between a REST call failing and simply having no telemetry information, it is preferred to simply have no telemetry information.

[0119] If a request to a service does not support propagation headers, this request is added to the rejection list, preventing further automatic attempts to insert the context of this user session, and the request is executed without the inserted headers. In one aspect, the rejection list is not cached in local storage so that an incomplete configuration does not cause future requests to be blocked. The destination may be present in both the permission list and the rejection list, but in this case, the rejection list takes precedence.

[0120] To improve search time, the allow list and deny list are implemented as associative arrays. The lists are encrypted either by the URL origin (without parameters) of the failed request or by the individual service. This may be determined by the request settings. The value of the map may be zero, but can later contain other metadata regarding the actual failure or reason added to the list.

[0121] Examples of calls include the following.

[0122] [Number]

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

[0124] In block 1105, process 1100 includes determining whether the destination of the request is a server in the allow list. For example, the tracking application 136 determines whether an external server permits a tracking header for a request from the original server by searching the allow list. The allow list includes servers identified as accepting requests that include an extra header (e.g., created by the request identified by block 1112 of process 1100).

[0125] If it is determined that propagation headers are supported, the specific destination is added to the allow list. The allow list can be cached in local storage so that no additional optional calls need to be made. This approach eliminates the need to support a user interface for explicitly permitting 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] In block 1106, process 1100 includes executing an HTTP options call. The options call requests permitted communication options from the server. In the CORS protocol, since a preflight request is sent with the OPTIONS method, the server can respond as to whether to send the request. The options call determines whether to permit inserting a tracking header. Optionally, in block 1106, process 1100 includes executing a preflight request before the browser automatically performs such a check. Process 1100 proceeds to block 1107.

[0127] In block 1107, process 1100 includes determining from the result of the options call whether the tracking header is supported by the server. Optionally, the options call can return a list of permitted (or acceptable) headers. If the tracking header is supported, process 1100 proceeds to block 1108 and inserts the header. If the tracking header is not supported, process 1100 proceeds to block 1113 and adds the server to the server rejection list.

[0128] The following shows some exemplary options requests / responses (some headers are omitted for brevity). For example, the following shows an options request for detecting propagation.

[0129]

Number

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

[0131]

Number

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

[0133]

Number

[0134] In block 1108, process 1100 includes inserting a header into the request. Inserting a tracing header into the request is based on a determination that the external server permits the tracing header for the request. As an example, the content of the tracing header includes a span context.

[0135] As an example, Zipkin and / or ECID (Execution Context) are used to insert two sets of headers into the outgoing request. These protocols provide coverage for maintaining context with minimal effort on the service developer side.

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

[0137]

Number

[0138] The TraceId is a unique 32-character UUID string, the SpanId is a unique 16-string surrounding the span, the ParentSpanId is the unique ID of the parent span (if applicable), and Sampled is a flag indicating whether to report span telemetry.

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

[0140]

Number

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

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

[0143] FIG. 13 is a diagram showing an example of a header according to a particular aspect of the present disclosure. FIG. 13 shows a header 1310 which is an HTTP header without instrumentation and a header 1320 which is the same HTTP header as header 1310 but with additional instrumentation (shown in bold text).

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

[0145] In 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 and ends the process. If the request was not successful, process 1100 proceeds to block 1112.

[0146] In block 1111, process 1100 includes ending the process for making the request. In block 1111, the extra header is successfully sent to the server, as a result, the span context is propagated to the destination server and the destination server assists with instrumentation.

[0147] In block 1112, process 1100 includes determining whether the failure identified in block 1110 is due to the header, as opposed to some other error. If the failure was not due to the header, process 1100 proceeds to block 1116 and can execute normal failover / retry procedures. If the failure was due to the header, process 1100 proceeds to block 1113 and adds the server to the server rejection list.

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

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

[0150] In block 1115, process 1100 includes determining whether the request is within a cached request list. To improve performance and reduce failures, requests can be cached. 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 can include a span context.

[0151] In block 1116, process 1100 includes executing a failover process or retrying a request. In this case, considering that it is not an optimal user experience for the page load or completion to fail, process 1100 includes retrying the failed operation in block 1116 to ensure that the attempt to insert the tracking header does not cause a failure. In some cases, developers may not have added sufficient error checking or a graceful exit. Therefore, in this regard, block 1116 helps to ensure that the custom application does not fail due to remote measurement. A request can include a span context.

[0152] In block 1117, process 1100 includes proceeding with a cached response. The cached response is used to process the request. A request can include a span context. As described with respect to FIGS. 4 and 5, spans and logs are sent to the span recording library.

[0153] FIG. 14 is a schematic diagram showing a distributed system 1400 for implementing one of the aspects. In the illustrated aspect, the distributed system 1400 includes one or more client computing devices 1402, 1404, 1406, and 1408 configured to execute and operate a client application such as a web browser or a dedicated client (e.g., an Oracle form) via one or more networks 1410. The server 1412 may be communicatively connected to the remote client computing devices 1402, 1404, 1406, and 1408 via the network 1410.

[0154] In various aspects, server 1412 may be configured to execute one or more services or one or more software applications provided by one or more components of the system. The services or software applications can include non-virtual environments and virtual environments. The virtual environments can include virtual events, exhibitions, simulation devices, classrooms, shopping exchanges, and those used for enterprises, two-dimensional or three-dimensional (4D) representations, page-based logical environments, etc. In certain aspects, these services may be provided to users of client computing devices 1402, 1404, 1406, and / or 1408 as web services or cloud services, or based on the SaaS (Software as a Service) model. Thus, users operating client computing devices 1402, 1404, 1406, and / or 1408 can utilize the services provided by these components by exchanging information with server 1412 using one or more client applications.

[0155] In the illustrated configuration, software elements 1418, 1420, and 1422 of system 1400 are implemented on server 1412. In other aspects, one or more components of system 1400 and / or the services provided by these components may be realized by one or more client computing devices 1402, 1404, 1406, and / or 1408. Users operating client computing devices can utilize the services provided by these components using one or more client applications. These components may be realized 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 aspect is an example of a distributed system for realizing an aspect of the system and is not intended to be limiting.

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

[0157] The distributed system 1400 is shown as including four client computing devices, but can support any number of client computing devices. Other devices, such as devices having sensors, can exchange information with the server 1412.

[0158] The network 1410 of the distributed system 1400 can support data communication using any of a variety of commercially available protocols including, but not limited to, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (System Network Architecture), IPX (Internet Packet Exchange), Apple® Talk, etc., and can be any type of network well known to those skilled in the art. By way of example only, the network 1410 may be a local area network (LAN) based on Ethernet®, Token Ring, and / or others. The network 1410 may be a wide area network or the Internet. The network 1410 can include virtual networks including, but not limited to, virtual private networks (VPNs), intranets, extranets, public switched telephone networks (PSTNs), infrared networks, wireless networks (e.g., networks operating under the IEEE (Institute of Electrical and Electronic Engineers) 802.14 protocol suite, Bluetooth®, and / or any other wireless protocol), and / or combinations of these networks with other networks.

[0159] Server 1412 may be composed of one or more general-purpose computers, dedicated server computers (including, by way of example, PC (personal computer) servers, UNIX (registered trademark) servers, midrange servers, mainframe computers, rack-mounted servers), server farms, server clusters, or any other suitable configuration and / or combination. Server 1412 may include one or more virtual machines that execute a virtual operating system, or other computing architectures that require virtualization. One or more flexible pools of logical storage devices can be virtualized to maintain the virtual storage device of the server. Server 1412 can control virtual networks using software-defined networking. In various aspects, Server 1412 can be configured to run one or more of the services or software applications described in the foregoing disclosure. For example, Server 1412 can correspond to a server for executing the processes described above in accordance with an embodiment of the present disclosure.

[0160] Server 1412 can run an operating system that includes any of those described above, and any commercially available server operating system. Further, Server 1412 can run any of various additional server applications and / or middleware applications including, for example, an HTTP (Hypertext Transfer Protocol) server, an FTP (File Transfer Protocol) server, a CGI (Common Gateway Interface) server, a Java (registered trademark) server, a database server, etc. Exemplary database servers include, but are not limited to, those commercially available from companies such as Oracle (registered trademark), Microsoft (registered trademark), Sybase (registered trademark), IBM (registered trademark).

[0161] In some implementations, server 1412 may include one or more applications that analyze and integrate data feeds and / or event updates received from users of client computing devices 1402, 1404, 1406, and 1408. By way of example, data feeds and / or event updates may include, but are not limited to, Twitter™ feeds, Facebook™ updates or real-time updates received from one or more third-party information sources and continuous data streams. Real-time updates can include real-time events related to sensor data applications, financial market displays, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring devices, and the like. Further, server 1412 may also include one or more applications for displaying data feeds and / or real-time events via one or more display devices of client computing devices 1402, 1404, 1406, and 1408.

[0162] Additionally, the distributed system 1400 can also include one or more databases 1414 and 1416. The databases 1414 and 1416 can reside in various locations. By way of example, the one or more databases 1414 and 1416 can reside on a non-transitory storage medium near (and / or within) the server 1412. Alternatively, the databases 1414 and 1416 are remote from the server 1412 and communicate with the server 1412 via a network-based connection or a dedicated connection. In a set of aspects, the databases 1414 and 1416 can reside in a storage area network (SAN). Similarly, any necessary files for performing functions contributed to the server 1412 may be stored on and / or away from the server 1412 as needed. In a set of aspects, the databases 1414 and 1416 can include, for example, relational databases such as databases provided by Oracle. These relational databases are configured to retrieve, store, and update data in response to SQL format instructions.

[0163] FIG. 15 is a simplified block diagram showing one or more components of a system environment 1500 according to an aspect of the present disclosure. Services provided by one or more components of the system according to the aspect can be provided as cloud services. In the illustrated aspect, the system environment 1500 includes one or more client devices 1504, 1506, and 1508. A user can exchange information with a cloud infrastructure system 1502 that provides cloud services using a client computing device. The client computing device can be configured to operate a client application such as a web browser, a dedicated client application (e.g., Oracle Forms), or other applications. The user can utilize the services provided by the cloud infrastructure system 1502 by exchanging information 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 illustrated. Further, the illustrated aspect is merely an example of a cloud infrastructure system that can incorporate aspects of the present invention. In some other aspects, the cloud infrastructure system 1502 may have more or fewer components than illustrated, may combine two or more components, or may have components with 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] The exemplary system environment 1500 is shown to include three client computing devices, but can support any number of client computing devices. Other devices, such as devices having sensors, can exchange information with the cloud infrastructure system 1502.

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

[0168] The cloud infrastructure system 1502 can include one or more computers and / or servers that can include the components described above with respect to server 1412.

[0169] In certain aspects, the 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, manageable technical support services, etc., that can be provided to users from the cloud infrastructure system as needed. The services provided by the cloud infrastructure system can be dynamically scaled to meet the needs of users. Specific examples of services provided by the cloud infrastructure system are referred to herein as "service instances". Generally, any service that can be provided to a user from a system of a cloud service provider via a communication 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 an application, and the user can order and use the application via a communication network such as the Internet as needed.

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

[0171] In certain aspects, the cloud infrastructure system 1502 can include a set of application, middleware, and database services that can be provided to customers in a way that has flexible scalability, reliability, high availability, and security based on a self-service subscription. An example of such a cloud infrastructure system is the Oracle Public Cloud provided by the assignee of the present application.

[0172] Large amounts of data, sometimes referred to as big data, may be hosted and / or manipulated at many levels and different scales by infrastructure systems. Such data can include data sets that are so large and complex that they may be difficult to process using typical database management tools or conventional data processing applications. For example, terabytes of data may be difficult to store, retrieve, and process using personal computers or their rack-mounted counterparts. Data of this size may be difficult to process using state-of-the-art relational database management systems, desktop statistical data, and visualization packages. To acquire, collate, manage, and process data of this size within an acceptable elapsed time generally requires massively parallel processing software that runs on thousands of server computers, which is not feasible with the structure of commonly used software tools.

[0173] Analysts or researchers can visualize large amounts of data, detect trends, and / or otherwise interact with such data by storing and manipulating extremely large data sets. To present such data, or to simulate external forces on or by what such data represents, dozens, hundreds, or thousands of processors linked in parallel can act on such data. These data sets can include structured data organized in databases or structured data organized according to a structured model, and / or unstructured data (e.g., e-mails, images, data blobs (Binary Large Objects), web pages, complex event processing). By leveraging the ability to more quickly focus more (or fewer) computing resources towards a goal, cloud infrastructure systems may be more available for performing tasks on large data sets based on requests from corporations, government agencies, research institutions, private individuals, groups or organizations of like-minded individuals, or other entities.

[0174] In various aspects, the cloud infrastructure system 1502 can be configured to automatically provide, manage, and track the services of the cloud infrastructure system 1502 subscribed by a customer. The cloud infrastructure system 1502 can provide cloud services via various deployment models. For example, the service can be provided in a public cloud model having a cloud infrastructure system 1502 owned by an organization that sells cloud services (e.g., owned by Oracle) and can be used by the general public or enterprises in different industries. As another example, the service can be provided in a private cloud model having a cloud infrastructure system 1502 dedicated to a single organization and can be used by one or more entities within the organization. Also, the cloud service may be provided in a community cloud model. Thus, the cloud infrastructure system 1502 and the services provided by the cloud infrastructure system 1502 are shared by multiple organizations within the relevant community. Also, the cloud service may 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 can include one or more services provided in accordance with services in the SaaS (Software as a Service) category, PaaS (Platform as a Service) category, IaaS (Infrastructure as a Service) category, or other categories including hybrid services. A customer can order one or more services provided by the cloud infrastructure system 1502 by submitting a subscription application. In response, the cloud infrastructure system 1502 performs a process of providing the services included in the customer's subscription application.

[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, the 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 can function to build and provide a suite of on-demand applications on an integrated development and deployment platform. The SaaS platform can 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 that operate on the cloud infrastructure system. Customers can obtain application services without having to purchase separate licenses and support. A variety of different SaaS services can be provided. By way of illustration, but not limitation, the services include sales performance management, enterprise integration, and services that provide solutions for business agility in large organizations.

[0177] In certain embodiments, the platform service may be provided by a cloud infrastructure system via a PaaS platform. The PaaS platform may be configured to provide cloud services compliant with the PaaS category. Examples of platform services include, but are not limited to, services that give an organization (e.g., Oracle) the ability to integrate existing applications on a shared common architecture and the ability to build new applications that utilize shared services provided by the platform. The PaaS platform can manage and control the underlying software and infrastructure to provide 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 can be provided. Examples of platform services include, but are not limited to, oracle Java cloud service (JCS), Oracle database cloud service (DBCS), and others.

[0178] By using the services provided by the PaaS platform, customers can utilize the programming languages and tools supported by the cloud infrastructure system and control the deployed services. In certain aspects, 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, the database cloud service can support a shared service deployment model that can give an organization the ability to accumulate database resources and provide DBaaS (Database as a Service) to customers as a cloud database. The middleware cloud service can provide customers with a platform for developing and deploying various business applications on the cloud infrastructure system, and the Java cloud service can provide customers with a platform for deploying Java applications on the cloud infrastructure system.

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

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

[0181] In certain embodiments, the resources within the cloud infrastructure system 1502 can be shared among multiple users and dynamically reallocated according to each user's requirements. Also, the resources can be allocated to users in different time zones. For example, the cloud infrastructure system 1530 can make the resources of the cloud infrastructure system available to a first group of users during a specified time period, and then reallocate the same resources to another group of users in a different time period, maximizing the utilization of the resources.

[0182] In certain embodiments, a plurality of internal shared services 1532 are provided and can be shared among different components or modules of the cloud infrastructure system 1502 and among the services provided by the 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, and file transfer services.

[0183] In certain aspects, the cloud infrastructure system 1502 can provide a function for comprehensively managing cloud services (such as SaaS services, PaaS services, and IaaS services) within the cloud infrastructure system. In one aspect, the cloud management function may include functions for providing, managing, and tracking customer subscriptions received by the cloud infrastructure system 1502 or the like.

[0184] In one aspect, as shown in the figure, the cloud management function 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 ID management module 1528. These modules may include one or more computers and / or servers and may be formed using these. 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 exemplary operation 1534, a customer can exchange information with cloud infrastructure system 1502 by using a client device, such as client devices 1504, 1506, or 1508, to request and order one or more services provided by cloud infrastructure system 1502. In certain embodiments, the customer can access cloud user interfaces (UIs), cloud UIs 1512, 1514, and / or 1516, and order subscriptions through these UIs. Order information received by cloud infrastructure system 1502 in response to a customer's order can include information identifying the customer and one or more services provided by cloud infrastructure system 1502 that the customer is attempting to subscribe to.

[0186] After the customer places an order, the order information is received via cloud UIs 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 operated in conjunction with other system elements.

[0188] In operation 1538, the order information is transferred to order management module 1520. In some examples, order management module 1520 may be configured to perform billing and accounting functions related to the order, such as order confirmation and post-confirmation order entry.

[0189] In 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 for the provision of the 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 for the provision of resources to support the ordered services.

[0190] In certain embodiments, the order orchestration module 1522 can manage the business processes associated with each order and can determine whether to pay for an order by applying business logic. In operation 1542, upon receiving an order for a new subscription, the order orchestration module 1522 allocates resources and sends a request to the order fulfillment module 1524 to configure the resources necessary 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 an abstraction level between the cloud services provided by the system environment 1500 and the physical implementation layer used to supply the resources for providing the requested services. In this way, the order orchestration module 1522 can be isolated from implementation details such as whether to provision services and resources on - the - fly or in advance, and whether to allocate / give in response to requests.

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

[0192] In operation 1546, the order management and monitoring module 1526 can manage and track customer subscription orders. In some examples, the order management and monitoring module 1526 can be configured to collect usage statistics of services within a subscription order, such as storage usage, data transfer volume, number of users, system startup time, and system shutdown time.

[0193] In certain aspects, the cloud infrastructure system 1500 can include an ID management module 1528. The ID management module 1528 can be configured to provide identification services to the cloud infrastructure system 1500, such as access management and authorization services. In certain aspects, the ID management module 1528 can control information regarding customers who want to utilize services provided by the cloud infrastructure system 1502. Such information can include information for approving a customer's ID and information describing the customer's execution permissions granted for various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). The ID management module 1528 can include descriptive information regarding each customer, ways to access and modify the descriptive information, and management of customers who access and modify the descriptive information.

[0194] FIG. 16 is a diagram showing an example of a computer system 1600 that can implement various aspects of the present invention. Using the computer system 1600, any of the computer systems described above can be implemented. As shown, the computer system 1600 includes a processing unit 1604 that communicates with a plurality of peripheral subsystems via a bus subsystem 1602. The peripheral subsystems can include a processing acceleration unit 1606, an I / O subsystem 1608, a memory subsystem 1618, and a communication subsystem 1624. The memory subsystem 1618 includes a tangible computer-readable storage medium 1622 and a system memory 1610.

[0195] The bus subsystem 1602 forms a mechanism for the various components and subsystems of the computer system 1600 to communicate with each other as needed. In the illustration, the bus subsystem 1602 is schematically shown as a single bus, but in alternative embodiments, the bus subsystem may utilize multiple buses. The 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 that uses any of various bus architectures. For example, such architectures can include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Extended ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus. These buses can be implemented as a mezzanine bus manufactured in accordance with the IEEE P1686.1 standard.

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

[0197] In various aspects, processing unit 1604 can execute various programs according to program code and can execute multiple programs or processes simultaneously. At any given time, some or all of the program code being executed can reside in processing unit 1604 and / or memory subsystem 1618. With appropriate programming, processing unit 1604 can provide the various functions described above. Computer system 1600 may further include a processing acceleration unit 1606 that can include, for example, a digital signal processor (DSP) and a dedicated processor.

[0198] The I / O subsystem 1608 can include a user interface input device and a user interface output device. The user interface input device may include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touch screen incorporated in a display, a scroll wheel, a click wheel, a dial, buttons, switches, a keypad, a voice input device with a voice command recognition system, a microphone, and other types of input devices. Also, the user interface input device may include, for example, a motion detection and / or gesture recognition device such as a Microsoft Kinect® motion sensor. The Microsoft Kinect® motion sensor can control and interact with an input device such as a Microsoft Xbox® 460 game controller via a natural user interface (NUI) that utilizes gestures and voice commands. Further, the user interface input device can include an eye gesture recognition device such as a Google Glass® blink detector. The Google Glass® blink detector detects the user's eye movements (e.g., "blinks" when taking a photo and / or selecting a menu) and converts the eye movements into an input that is input to an input device (e.g., Google Glass®). Additionally, the user interface input device may include a voice recognition detection device that enables interaction between the user and a voice recognition system (e.g., a Siri® navigator) via voice commands.

[0199] In addition, the user interface input device includes, but is not limited to, a three-dimensional (4D) mouse, a joystick or a pointing stick, a game pad, a graphic tablet, an audio / visual device such as a speaker, a digital camera, a digital video camera, a portable media player, a web camera, an image scanner, a fingerprint scanner, a barcode reader, a 4D scanner, a 4D printer, a laser distance meter, and a gaze tracking device. Further, the user interface input device may include a medical image input device such as, for example, a computed tomography device, a magnetic resonance imaging device, an ultrasonic computed tomography device, and a medical ultrasonic device. Also, the user interface input device may include an audio input device such as, for example, a MIDI keyboard and an electronic musical instrument.

[0200] The user interface output device may include a non-visual display such as a display subsystem, an indicator light, or an audio output device. The display subsystem may be, for example, a flat panel device using a cathode ray tube (CRT), a liquid crystal display (LCD), or a plasma display, a projection device, or a touch screen. Generally, when using the term "output device", it is intended to include all possible types of devices and mechanisms for outputting information from the computer system 1600 to the user or another computer. For example, the user interface output device includes, but is not limited to, various display devices that visually transmit text, images, and audio / video information, such as a monitor, a printer, a speaker, headphones, a car navigation system, a plotter, an audio output device, and a modem.

[0201] The computer system 1600 can include a memory subsystem 1618. The memory subsystem 1618 comprises software elements, which in the illustration are located within the system memory 1610. The system memory 1610 can store program instructions loadable and executable by the processing unit 1604, and data generated by the execution of these programs.

[0202] Depending on the configuration and type of the computer system 1600, the system memory 1610 may be a volatile memory (e.g., random access memory (RAM)), and / or a non-volatile memory (e.g., read-only memory (ROM), flash memory). Generally, RAM houses data and / or program modules that are immediately accessible by the processing unit 1604, and / or data and / or program modules that are currently being operated on and executed by the processing unit 1604. In some implementations, the system memory 1610 may include multiple different types of memory such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS) that includes basic routines to assist in transferring information between elements within the computer system 1600, such as during startup, may generally be stored in the ROM. By way of example and not limitation, the system memory 1610 also shows an application program 1612 that may include a client application, a web browser, a middle-tier application, a relational database management system (RDBMS), etc., program data 1614, and an operating system 1616.As an example, the operating system 1616 can include various versions of Microsoft Windows (registered trademark), Apple Macintosh (registered trademark) and / or Linux (registered trademark) operating systems, various commercially available UNIX (registered trademark) or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome (registered trademark) OS, etc.), and / or mobile operating systems such as iOS, Windows (registered trademark) Phone, Android (registered trademark) OS, BlackBerry (registered trademark) 15 OS and Palm (registered trademark) OS operating systems.

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

[0204] Also, the memory subsystem 1610 can include a computer-readable storage medium reader 1620 that is further connectable to a computer-readable storage medium 1642. The computer-readable storage medium 1642, together with or in combination with the system memory 1610 as needed, can comprehensively represent a remote storage device, a local storage device, a fixed storage device and / or a removable storage device in addition to a storage medium for temporarily and / or permanently accommodating, storing, transmitting and searching computer-readable information.

[0205] In addition, a computer-readable storage medium 1642 that includes code or a portion of code can include any suitable medium known or used in the art, and the medium can be a volatile and non-volatile, removable and non-removable medium implemented in any method or technology for storing and / or transmitting information, including, but not limited to, storage media and communication media. This can include tangible non-transitory computer-readable storage media such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD), or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, or other tangible computer-readable media. Additionally, if specified, this can include intangible transient computer-readable media such as data signals, data transmissions, or other media that can be used to transmit desired information and are accessible by computer system 1600.

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

[0207] The communication subsystem 1624 provides an interface to other computer systems and networks. The communication 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 communication subsystem 1624 can enable the computer system 1600 to connect to one or more devices via the Internet. In certain embodiments, the communication subsystem 1624 can include radio frequency (RF) transceiver components for accessing wireless voice and / or data networks (e.g., using cellular phone technologies such as 4G, 4G or EDGE (enhanced data rates for global evolution), advanced data network technologies), WiFi (IEEE802.28 family standards or other mobile communication technologies or any combination thereof), global positioning system (GPS) receiver components, and / or other components. In certain embodiments, the communication subsystem 1624 can provide a wired network connection (e.g., Ethernet) in addition to, or instead of, a wireless interface.

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

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

[0210] Also, the communication 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 and / or event updates 1630 that may be continuous or may have no boundaries in a state without an essentially distinct end. Examples of applications that generate continuous data can include, for example, sensor data applications, financial tickers, network performance measurement tools (such as network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, etc.

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

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

[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 with more or fewer components than the system shown in the figures. For example, customized hardware may also be used, and / or specific elements may be implemented, in hardware, firmware, software (including applets), or combinations thereof. 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 understand other means and / or methods for implementing the various aspects.

[0214] In the foregoing specification, aspects of the invention have been described with reference to specific embodiments thereof, but one of ordinary skill in the art will recognize that the invention is not limited thereto. The various features and aspects of the above-described invention may be used individually or in combination. Additionally, aspects 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 as illustrative rather than restrictive.

Claims

1. A method for propagating a trace throughout a distributed software application, comprising: recording trace data of a web page from an original server, the web page being executed by a web browser on a client device; 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; searching a rejection list on the web browser indicating whether the external server rejects tracking headers in a request from the original server; searching a permission list on the web browser indicating whether the external server is permitted to track headers in a request from the original server; including determining, by querying the external server, whether the external server is permitted to track headers in a request, the query being based on a negative result of the search of the rejection list or the permission list; updating the permission list on the web browser to indicate that the external server is permitted to track headers in a request from the original server; inserting a tracking header into the request based on the result of the query; including sending the request including the tracking header from the web browser to the external server, the external server being configured to record trace 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 a cache includes an entry corresponding to the external server; The method according to claim 1, further comprising obtaining a response corresponding to the entry from the cache and providing the response to the additional request.

3. The method according to claim 1 or 2, further comprising inserting the tracking header into the request and sending the request including the tracking header in response to a determination that the original server is not executing CORS (Cross-Origin Resource Sharing).

4. The method according to any one of claims 1 to 3, wherein the request is a Hypertext Transfer Protocol (HTTP) request.

5. The method further includes receiving, from the external server, a performance measurement value of a span, wherein the span includes operations executed to service the request, and the performance measurement value includes one or more of (i) the number of processing cycles corresponding to the execution of the operations or (ii) the execution time of the operations, the method according to any one of claims 1 to 4.

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

7. receiving, from the external server, a notification that the request has been rejected; adding the external server to the rejection list on the web browser; and resending the request without the tracking header from the web browser to the external server, the method according to any one of claims 1 to 6.

8. A system comprising: a non-transitory computer-readable medium for storing computer-executable instructions; and at least one processor communicatively connected to the non-transitory computer-readable medium for executing the computer-executable instructions, wherein the computer-executable instructions include: instructions for recording tracking data of a web page from an original server, the web page being executed by a web browser on a client device; instructions for determining that the web page from the original server requires a request to an external server located outside the domain of the original server; instructions for searching a permission list indicating whether the external server is permitted to track headers in a request 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, the external server being configured to record tracking data based on the tracking header.

9. The computer-executable instructions include: instructions for receiving, from the external server, a notification that the request has been rejected; Instructions for adding the external server to a rejection list on the web browser, The system according to claim 8, further comprising instructions for sending the request without the tracking header from the web browser to the external server.

10. The system according to claim 8 or 9, wherein the request is a Hypertext Transfer Protocol (HTTP) request.

11. The computer-executable instructions further comprise instructions for receiving, from the external server, performance measurement values of a span, The span includes operations executed to provide service to the request, The system according to any one of claims 8 to 10, wherein the performance measurement values include one or more of (i) the number of processing cycles corresponding to the execution of the operations or (ii) the execution time of the operations.

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

13. The computer-executable instructions are Instructions for receiving, from the external server, a notification that the request has been rejected, Instructions for adding the external server to a rejection list, The system according to claim 8, further comprising instructions for resending the request without the tracking header to the external server.

14. A program for causing a system to execute the method according to any one of claims 1 to 7.

Images