Patent Publication Number: US-2018052754-A1

Title: Performance metric contextualization in a distributed computing environment

Description:
CLAIM FOR PRIORITY 
     The present application is a continuation of U.S. application Ser. No. 15/242,270, filed Aug. 19, 2016, which is hereby incorporated herein by reference in its entirety. 
    
    
     BACKGROUND 
     The disclosure generally relates to the field of data processing, and more particularly to performance metric contextualization in distributed computing environments. 
     The growing presence of the Internet as well as other computer networks, such as intranets and extranets, has brought many new applications in e-commerce, education and other areas. Organizations increasingly rely on such applications to carry out their business or other objectives. Such organizations also typically devote considerable resources to ensuring that the applications perform as expected. To this end, various application monitoring techniques have been developed. 
     One approach involves monitoring the infrastructure of the application by collecting application runtime data regarding the individual components that are invoked in the application. This approach can use agents that essentially live in the system being monitored. For example, using instrumentation of the software, a thread or process can be traced to identify each application component that is invoked, as well as to obtain runtime data, such as the execution time of each application component. Tracing refers to obtaining a detailed record, or “trace,” of the operations a computer program executes. Traces can be used as an aid in debugging or production performance monitoring. 
     However, as application complexity increases, diagnosis of problems continues to be difficult and time-consuming (especially when problems span multiple processes and runtimes). When a distributed transaction or application is failing or regressing, what is going wrong, why the failure is occurring, etc., needs to be determined as quickly as possible to minimize business impact. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Embodiments of the disclosure may be better understood by referencing the accompanying drawings. 
         FIG. 1  depicts a system architecture at runtime for performance metric contextualization, according to some embodiments. 
         FIGS. 2-4  depict example processing of a request to determine a performance metric based on a calling context, according to some embodiments. 
         FIG. 5  depicts two examples of the number of accumulators created based on the number possible values of the selected attributes (and number of host devices), according to some embodiments. 
         FIGS. 6-7  depict flowcharts that includes performance metric contextualization based on a calling context, according to some embodiments. 
         FIG. 8  depicts an example computer device, according to some embodiments. 
     
    
    
     DESCRIPTION 
     The description that follows includes example systems, methods, techniques, and program flows that embody aspects of the disclosure. However, it is understood that this disclosure may be practiced without these specific details. For instance, this disclosure refers to monitoring application(s) for different business transactions. But aspects of this disclosure can be applied to many other types of applications. In other instances, well-known instruction instances, protocols, structures and techniques have not been shown in detail in order not to obfuscate the description. 
     Overview 
     Embodiments relate to collecting performance metrics of different services, operations, etc. performed by application components and invoked as part of transactions (e.g., business transaction) in a distributed computing environment. Examples of performance metrics include execution time, error rates, etc. In some embodiments, in response to a request to perform a transaction, multiple application components are executed to perform different application services, operations, etc. For example, an application stack having multiple application components can process a transaction. For instance, an application stack can include a first application component, a second application component, a third application component, etc. In this instance, a first application component can invoke execution of a second application component, which invokes, a third application component, etc. In some embodiments, the different application components can run on different host devices and/or in different runtime environments. 
     An application component can be any type of logical grouping of functionality, storage used, databases being accessed, etc. For instance, an application component can be utilized for operations to provide for a user login and authentication into a website. Or, an application component can be a queue or a database that is accessed during execution of the application(s). Also, the application components can be in a same or different host devices. For example, the application components can execute in different host devices in a distributed computing environment 
     Some embodiments provide contextualization for collecting performance metrics of various application components based on values of attributes of an incoming request (a calling context). This contextualization is not limited to the highest level of the application stack. Rather, this contextualization based on attributes&#39; values of an incoming request can be carried down through the application stack. In other words, performance metrics can be separated based on the calling context at different levels of the application stack. Accordingly, the calling context includes a value of at least one attribute of the incoming request and a path from a top of the application stack to a location of the application component being executed. 
     An example attribute of a request includes a type of transaction (e.g., checkout). Another example attribute is a geographic origin of the request. For instance, if the transaction originates from a user whose device is located in Europe, the geographic origin is Europe. The geographic origin can be based on continent, country, state, city, etc. Accordingly, a performance metric such as error rate can be specific to a value of one or more attributes of the request. For instance, a first average error rate can be determined for a first request that is a checkout of item X from North America, and a second average error rate can be determined for a second request that is a checkout of item Y from Asia. Additionally, separation of performance metrics is not limited to values of attributes of the request being received at the top of the application stack. In some embodiments, performance metrics can also be separated based on identification (ID) of host device in which the application component is executing. 
     Terminology 
     This description uses the term “application component” to refer to any logical partition of functionality, hardware used to execute portions of the application (e.g., processor), data storage used during execution of the application (e.g., queues, databases, etc.), or any other components usable within the application. For instance, an application component can be operations (e.g., a servlet) to provide for a user login and authentication into a website. In another instance, an application component can be operations to allow a user to access their account balance from an account balance database. An application component can also be a database from which data is accessed during execution of the application. Additionally, an application component can be some type of queues or other data structures used during execution of the application. 
     This description uses the term “application stack” to refer to an ordered collection or set of application components that are executed to complete a particular task, service, etc. In some embodiments, the application components are in a distributed computing environment, such that at least some of the application components are executing in different host devices (and possibly running different types of runtimes and operating systems). The application components in an application stack can be ordered from top to bottom. For example, assume the application component includes application component A, application component B, application component C, etc. Also, assume that application component A is at the top of the application stack, application component B is below application component A, application component C is below application component B, etc. In this example, some type of request, instruction, call, etc. can be received by application component A. For example, application component A can receive a request from a user to purchase an item from an online website. During its execution, application component A calls application component B to perform a service, determine a result, provide data, etc. In turn, during its execution, application component B calls application component C to perform a service, determine a result, provide data, etc. This traversal through the application stack can continue until the application component at the bottom of the application stack is executed. After the application component at the bottom of the application stack has been executed, the thread of execution can move back up the application stack. For example, after application component C has completed execution, application component B can complete execution. In turn, application component C can then complete execution. 
     Example System Architecture 
       FIG. 1  depicts a system architecture at runtime for performance metric contextualization, according to some embodiments.  FIG. 1  depicts a system  100  that include host devices  102 - 104  communicatively coupled to a management server  150 . In this example, the system  100  includes two host devices. However, the system  100  can include one or more host devices. An example of a system having five host devices is depicted in  FIGS. 2-4 , which are described in more detail below. Examples of the host devices  102 - 104  may include application servers or any other type of computing device having a processor for executing code to achieve a desired functionality. The host devices  102 - 104  can be located remotely from one another or co-located. The management server  150  includes a performance manager  152  and a storage device  153 . The performance manager  152  can be hardware, software, firmware, or a combination thereof. The performance manager  152  can access the storage device  153  to store data received from the host devices  102 - 104  and to provide to the host devices  102 - 104 . 
     The host device  102  includes an instance of a Java Virtual Machine (JVM)  106  running on an operating system  110 . Similarly, the host device  104  includes an instance of a Java Virtual Machine (JVM)  107  running on an operating system  112 . An agent can be load into the JVMs as part of the initialization to create the instance of the JVM. In this example, an agent  160  is loaded into the JVM  106 , and an agent  161  is loaded into the JVM  107 . 
     The JVM  106  can also include various application components (e.g., servlets) for execution therein. In this example, in response to loading an application X, an application component  170  and an application component  188  are instantiated in the JVM  106  for execution therein. In this instance, the application component  188  can be a database utility configured to interface with a database  189  to access data therein. For example, the application X can be functionality for a business transaction for shipping a product. The application component  170  can provide part of this functionality. For example, the application component  170  can retrieve an address to where a product is to be shipped. Similarly, in response to loading an application Y, an application component  172  is instantiated in the JVM  106  for execution therein. Similar applications being loaded can cause the application components  174 - 175  to be instantiated in the JVM  107 . In this instance, the application component  174  can be a database utility configured to interface with a database  155  to access data therein. 
     Also, as part of instantiation, the agents in the host device insert one or more probes to at least some of the application components. In this example, the agent  160  inserts probes  140 - 141  into the application component  170 . The agent  160  also inserts probes  142 - 143  into the application component  171 . The agent  161  inserts probes  144 - 145  into the application component  174 . The agent  160  also inserts probes  146 - 147  into the application component  175 . The agents along with the probes monitor execution of the application components to determine various performance metrics of the application components. For example, the probes can include byte code instrumentation. 
     The probes can collect information as defined by a directives file. For example, the information from the probes may indicate start and stop times of a transaction or other execution flow, or of individual components within a transaction/execution flow. This information can be compared to pre-established criteria to determine if the information is within bounds. If the information is not within bounds, the agent can report this fact to the performance manager (triggering an event) so that appropriate troubleshooting can be performed. 
     The probes can report a standard set of metrics which include: Common Object Request Broker Architecture (CORBA) method timers, Remote Method Invocation (RMI) method timers, thread counters, network bandwidth, Java Database Connectivity (JDBC) update and query timers, servlet timers, Java Server Pages (JSP) timers, system logs, file system input and output bandwidth meters, available and used memory and EJB (Enterprise JavaBean) timers. A metric can be defined as a measurement of a specific application activity in a given time interval. 
     Therefore, the probes can monitor for specific events during execution of the application components to determine various performance metrics such as execution time, error rate, etc. For example, in response to the application component  170  receiving a checkout request  120 , one of the probes  140 - 141  can record that a request is received, the type of request, attributes or parameters provided with the requests, etc. In another example, in response to the application component  172  receiving a product details request  122 , one of the probes  142 - 143  can also record that a request is received, the type of request, attributes or parameters provided with the requests, etc. 
     The probes can then forward the data collected regarding the various events occurring in the application components to their associated agent. In this example, the probes  140 - 143  forward their collected data to the agent  160 , and the probes  144 - 147  forward their collected data to the agent  161 . In turn, the agents  160 - 161  forwards the collected data to the performance manager  152 . The agents thus collect and summarize information received from the probes. 
     The performance manager  152  can access a storage device  153  to store the data received from the agents. In some applications, some large organizations employ a central network operations center where one or more performance managers obtain data from a number of distributed agents at different geographic locations. To illustrate, a web-based e-commerce enterprise might obtain agent data from servers at different geographic locations that receive customer orders, from servers that process payments, from servers at warehouses for tracking inventory and conveying orders, and so forth. The performance manager  120  and a user interface might be provided at a corporate headquarters location. Other applications which are not necessarily web-based or involve retail or other sales, similarly employ agents and performance managers for managing their systems. For example, a bank may use an application for processing checks and credit accounts. Moreover, in addition to the multi-computing device arrangements mentioned, a single computing device can be monitored as well with one or more agents. 
       FIG. 1  also depicts processing of the requests  120 - 122  after initialization (e.g., instantiation the agents and the application components, insertion of probes, etc.). The request  120  is received by the application component  170 . As part of its execution, the application component  170  calls the application component  188 , which executes to access data from the database  189 . Also as part of its execution, the application component  170  calls the application component  174  in the host device  104 . As further described below, the call includes a calling context, which includes values of one or more selected attributes and a path from the top of the application stack to the application component  174 . As part of its execution, the application component  174  calls the application component  175 , which executes to access data from the database  155 . After completing its execution, the application component  175  returns control to the application component  174  to allow for its completion of execution. After completing its execution, the application component  174  returns control to the application component  170  to allow for its completion of execution. After completing its execution, the application component  170  returns a result to the request  120 . 
     The request  122  is similarly processed. However, a different calling context is generated to include with the call to execute by the application component  172  to the application component  174 . The request  122  is received by the application component  172 . In this example, the application component  172  receives the request  122  because a different set of application components is needed to process the request  122  in comparison to the set of application components needed to process the request  121 . 
     As part of its execution, the application component  172  calls the application component  174  in the host device  104 . As further described below, the call includes a calling context, which includes values of one or more selected attributes and a path from the top of the application stack to the application component  174 . In this instance, the calling context is different from the calling context provided by the application component  170  because the path from the top of the application stack to the application component  174  is different. Additionally, the attributes selected from the request  122  may be different than the attributes selected from the request  120 , which would further differ the two calling contexts. As part of its execution, the application component  174  calls the application component  175 , which executes to access data from the database  155 . After completing its execution, the application component  175  returns control to the application component  174  to allow for its completion of execution. After completing its execution, the application component  174  returns control to the application component  172  to allow for its completion of execution. After completing its execution, the application component  172  returns a result to the request  122 . 
     Performance Metric Monitoring Example Based on a Calling Context 
       FIGS. 2-4  are now described. In particular,  FIGS. 2-4  depict an example of determining a performance metric based on a calling context, according to some embodiments.  FIG. 2  depicts an example  200 . 
     The example  200  includes five host devices—host devices  204 - 212 . The host devices  204 - 212  can be configured similar to the host devices  102 - 104  of  FIG. 1 . For example, each of the host devices  204 - 212  can include its own agent, wherein one or more probes are attached to some or all of the application components for communication with the agent regarding data used to determine calling context, performance metrics, etc. 
     The host device  204  includes a transaction  219 , an application component # 1   225 , and an application component # 2   223 . The transaction  219  is a type of application component that is configured to receive a request. For example, the request can be various requests to perform different types of business transactions. For instance, the transaction  219  can be a servlet to receive a request to checkout in order to purchase an item from a website. In another instance, the transaction  219  can be a request to provide product details for a selected item, product, service, etc. The application component # 1   225  and the application component # 2   223  can be application components called by the transaction  219  to perform part of a service, generate a result, provide data, etc. as part of processing the request. 
     The application components in the host device  206  are a replica of the application components in the host device  204  to provide a same functionality. The host device  206  includes a transaction  221 , an application component # 1   229 , and an application component # 2   227 . The transaction  221  is a type of application component that is configured to receive a request. For example, the request can be various requests to perform different types of business transactions. The application component # 1   229  and the application component # 2   227  can be application components called by the transaction  221  to perform part of a service, generate a result, provide data, etc. as part of processing the request. While the example  200  depicts one replica, there can a larger number of replicas to allow for the processing of requests from numerous users. 
     The host device  208  includes an application component # 2   231  and an application component  235 . The host device  210  includes an application component # 1   233 , an application component # 3   237 , and an application component  239 . The host device  212  includes an application component # 3   241 , an application component  243 , and an application component  245 . 
     In this example, a request  202  is received by both the transaction  219  and the transaction  221  for processing to help illustrate the different calling contexts at different points in the application stack (as further described below). The request  202  includes four attributes. A first attribute is the type of transaction. The type of transaction can be one of five values (denoted by the five in parenthesis). In this example, the type of transaction of the request  202  is a checkout. A second attribute is a geographic origin of the request. The geographic origin can be one of three values (denoted by the three in parenthesis). For example, the request can provide identification of a source address from which the request originated. The source longitude and latitude can be translated into a geographic origin of the request. The geographic origin can be based on continent, country, state, city, etc. In this example, the geographic origin of the request  202  is Asia. 
     A third attribute of the request  202  is a user group. The user group can be one of two values (denoted by the two in parenthesis). For example, a group can be put into different categories based on various criteria. For instance, a user can be in a highest level group based on exceeding a highest threshold for money spent on the website. In another instance, a user can pay for being in a higher level user group. In this example, the user group of the request  202  is gold. A fourth attribute of the request  202  is a platform of the device from which the request originated. The platform can be one of three values (denoted by the three in parenthesis). For example, the platform can define what web browser, operating system, etc. executing on the device from which the request originated. For instance, a user device executing web browser N can transmit the request  202  to be received by the host devices  204 - 206 . In this instance, value of the fourth attribute is N. 
     Some of the application components have been numbered (# 1 -# 3 ) to define a relationship between application components executing in different host devices. For example, the application component # 1   235  in the host device  204  and the application component # 1   229  in the host device  206  call the application component # 1   233  in the host device  210 . 
     In response to receipt of the request  202 , the transaction  219  initiates execution. As part of its execution, the transaction  219  invokes execution of the application component # 1   225  and the application component # 2   223 . Execution of the application component # 1   225  and the application component # 2   223  may be performed at least partially in parallel. As part of its execution, the application component # 1   225  invokes execution of the application component # 1   233 . As part of its execution, the application component # 2   223  invokes execution of the application component # 2   231 . 
     As part of its execution, the application component # 2   231  invokes execution of the application component  235 . As part of its execution, the application component # 1   233  invokes execution of the application component # 3   237  and the application component  239 . Execution of the application component # 3   237  and the application component  229  may be performed at least partially in parallel. As part of its execution, the application component # 3   237  invokes execution of the application component # 3   241 . 
     As part of its execution, the application component # 3   241  invokes execution of the application component  243  and the application component  245 . Execution of the application component  243  and the application component  245  may be performed at least partially in parallel. 
     In the example  200 , the transaction  219  and the transaction  221  are at the top of the application stack. The application components  243 . the application component  245 , the application component  235 , and the application component  239  are at the bottom of the application stack. As application components at the bottom of the application stack complete execution, these application components can return results, data, etc. back to the application components that invoked their execution. In turn, these application components can complete execution and can return results, data, etc. back to the application components that invoked their execution. Accordingly, execution of the application components can move back up the application stack as application component complete execution. 
     For example, after completing execution, the application component  243  and the application component  245  can return control to the application component  241 . The application component  241  can then complete its execution. After completing execution, the application component  241  can return control to the application component # 3   237 . The application component # 3   237  can then complete its execution. After completing execution, the application component # 3   237  and the application component  239  can return control to the application component # 1   233 . After completing execution, the application component # 1   233  can return control to the application component # 1   229  and the application component # 1   225 . 
     After completing execution, the application component  235  can return control to the application component # 2   231 . After completing execution, the application component # 2   231  can return control to the application component # 2   223  and the application component # 2   227 . After completing execution, the application component # 1   225  and the application component # 2   223  can return control to the transaction  219 . The transaction  219  can then return its results to the device that issued the request  202 . After completing execution, the application component # 1   229  and the application component # 2   227  can return control to the transaction  221 . The transaction  221  can then return its results to the device that issued the request  202 . 
       FIG. 3  depicts the example  200  of  FIG. 2  and depicts additional details of the calling context being carried down through the application stack. In  FIG. 3 , an example  300  includes the addition of context cache to each of the host devices. The context cache can be a machine-readable media that stores data related to a context of requests being received and processed by application components in the associated host device. The host device  204  includes a context cache  352 . The host device  206  includes a context cache  350 . The host device  208  includes a context cache  356 . The host device  210  includes a context cache  354 . The host device  212  includes a context cache  358 . 
     A performance manager  302  has also been added to the example  300  of  FIG. 3 . The performance manager  302  can represent the performance manager  152  executing in the management server  150  of  FIG. 1 . The performance manager  302  is depicted as two different blocks in the example  300 . Depiction as two different blocks was included in  FIG. 3  for sake of clarity. However, in some embodiments, multiple instances of the performance manager  302  can be created. 
     The performance manager  302  is communicatively coupled to each of the host devices  204 - 212 . As further described below, the performance manager  302  is configured to communicate with the agent in each of the host devices  204 - 212  to receive and process calling contexts as application components are executed in the application stack. The performance manager  302  returns to the agent a unique identifier for a given calling context based on a value of one or more attributes of the request and a path from the top of the application stack to a current location in the application stack. The agent can store the unique identifier in its associated context cache. As further described below, this unique identifier is also used to communicate the calling context to an application component further down the application stack. 
     The example  300  of  FIG. 3  also includes one or more accumulators added to each of the host devices  204 - 212 . In particular, the host device  204  includes an accumulator(s)  371 . The host device  206  includes an accumulator(s)  370 . The host device  208  includes an accumulator(s)  373 . The host device  210  includes an accumulator(s)  372 . The host device  212  includes an accumulator(s)  374 . For example, the accumulators can be some type of register, storage, etc. in a machine-readable media in the host device. 
     The agent in the host device can create an accumulator for each unique value combination for the attributes that have been selected to be monitored. The attributes that are selected can be a configurable parameter selectable by an administrator, developer, user, etc. that is monitoring performance metrics of the application components. For example, the request  202  includes five attributes. Assume that the selected attributes include transaction and user group. In this example, there are five possible values for transaction and two possible values for user group. There are 10 (5×2) possible combinations of values for the selected attributes. Accordingly, the agent can create 10 accumulators in its host device (one accumulator for each possible combination of values for the selected attributes). In some embodiments, the agent creates an accumulator as a unique value combination of the selected attributes is first received. For example, in response to receiving a request for the first time having a transaction of checkout and a user group of gold, the agent would create an accumulator for this unique combination. Then in response to receiving a request for the first time having a transaction of product details and a user group of gold, the agent would create a second accumulator for this unique combination. This creation of an accumulator continues each time a unique combination of the values of the selected attribute(s) are received. 
     As further described below, each accumulator stores an accumulated value that comprises an aggregated value for a given performance metric of an application component in the host device. For instance, if the given performance metric is execution time, each time an execution time is determined this value is added to the current accumulated value for the unique combination. For example, assume that an execution time for a particular application component at one of the levels of the application stack for a first request having a transaction of checkout and a user group of gold is 500 milliseconds. The accumulated value for this accumulator is 500 milliseconds. Then, assume that a next execution time for the same application component for a second request having the same values for the selected attributes is 300 milliseconds. The accumulated value for this accumulator is 500 milliseconds plus 300 milliseconds→800 milliseconds. Over time, an average value for this performance metric for this particular application component can be determined by dividing the accumulated value by the number of accumulated values stored in the accumulator. 
     Accordingly, performance metrics at any level of the application stack can be determined for the different application components based on the specific values of the selected attributes for the original request received at the top of the application stack. In other words, performance metrics can be separated based on the calling context from the top of the application stack at different levels of the application stack. 
     The example  300  of  FIG. 3  also depicts how the calling context of the request is provided to the different levels of the application stack. In particular, in response to the request  202  being received, the agents in the host device  204  and  206  forward a context  301  that includes values of the different attributes of the request  200  (transaction: checkout, origin geography: Asia, user group: gold, and platform: chrome). In this example, the performance manager  302  has been configured to select attributes of the request  200  relative to the performance metric being monitored. For this example, an administrator may have configured the performance manager  302  to select the attributes transaction and user group. Also in this example, the performance metric of the transaction  219  in the host device  204  is being monitored. Similarly, the performance metric of the transaction  221  in the host device  206  is being monitored. 
     In response to receiving the context  301 , the performance manager  302  assigns a unique identifier ( 42 ) for a request having a transaction of checkout and a user group of gold. As shown, the performance manager  302  then transmits the context  303  having the unique identifier ( 42 ) back to the host devices  204 - 206 . The agents in the host devices  204 - 206  store the unique identifier ( 42 ) in the context cache  352  and the context cache  350 , respectively, for this unique combination for these particular values of the two selected attributes (checkout and gold). Additionally, the agent in the host device  204  creates an accumulator  371  for this unique identifier ( 42 ) (assuming the accumulator for this unique identifier has not yet been created). The accumulator  371  is for storage of a performance metric (e.g., execution time, error rate, etc.) of the transaction  219 . For instance, the accumulator  371  can store an accumulated value of the execution time of the transaction  219  across multiple requests being processed. For example, assume that an execution time of the transaction  219  to a first request is 200 milliseconds. The accumulator  371  stores a value of 200. Then, an execution time of the transaction  219  to a second request is 250 milliseconds. The accumulator  371  stores a value of 200+250→450 milliseconds. An average execution time can then be determined by dividing the accumulated value by the number of requests processed. 
     Similarly, the agent in the host device  206  creates an accumulator  370  for this unique combination (assuming the accumulator for this unique combination has not yet been created). The accumulator  370  is for storage of a performance metric (e.g., execution time, error rate, etc.) of the transaction  221 . Also, the agent in the host device  206  can create an accumulator for each unique combination of values (as described above). 
     The unique identifier ( 42 ) is then used to provide a context to the application components further down the application stack. For example, as part of the application component # 2   223  requesting execution by the application component # 2   231 , the application component # 2   223  includes a context  381  that augments a path from the top of the application stack. The path includes the unique identifier ( 42 ) and the application component # 2 → 42 /AC# 2 . Similarly, as part of the application component # 1   225  requesting execution by the application component # 1   233 , the application component # 1   225  includes a context  383  that includes a path from the top of the application stack. The path includes the unique identifier ( 42 ) and the application component # 1 → 42 /AC# 1 . 
     As part of the application component # 2   227  requesting execution by the application component # 2   231 , the application component # 2   227  includes the context  381  that includes a path from the top of the application stack. The path includes the unique identifier ( 42 ) and the application component # 2 → 42 /AC# 2 . As part of the application component # 1   229  requesting execution by the application component # 1   233 , the application component # 1   229  includes the context  383  that includes a path from the top of the application stack. The path includes the unique identifier ( 42 ) and the application component # 1   42 /AC# 1 . 
     The example  300  of  FIG. 3  also depicts how the calling context of the request is provided to the next level the application stack (applications components in the host devices  208 - 210 ). In particular, as part of execution of the application component # 2   223  and  227 , the application components # 2   223  and  227  transmit a call to the application component # 2   231  for its execution. The call includes the context  381 . In response to receiving the call, the agent in the host device  208  forwards the context  381  to the performance manager  302 . In this example, the performance metric of the application component # 2   231  in the host device  208  is being monitored. 
     In response to receiving the context  381 , the performance manager  302  assigns a unique identifier ( 45 ) for a context  315 . As shown, the performance manager  302  then transmits the context  381  having the unique identifier ( 45 ) back to the host device  208 . The agent in the host device  208  stores the unique identifier ( 45 ) in the context cache  356  for this unique combination for these particular values of the two selected attributes (checkout and gold) along this path through the application stack. Additionally, the agent in the host device  208  creates an accumulator  373  for this unique identifier ( 45 ) (assuming the accumulator for this unique identifier has not yet been created). The unique identifier ( 45 ) could then be used to provide a context to the application components further down the application stack. However, in this example, the application stack along this path is at the bottom in the host device  208 . Also, the agent in the host device  208  can create an accumulator for each unique combination of values of the attributes of the request being monitored (as described above). 
     As part of execution of the application components # 1   225  and  229 , the application components # 1   225  and  229  transmit a call to the application component # 1   233  for its execution. The call includes the context  383 . In response to receiving the call, the agent in the host device  210  forwards the context  383  to the performance manager  302 . In this example, the performance metric of the application component # 1   233  in the host device  210  is being monitored. 
     In response to receiving the context  383 , the performance manager  302  assigns a unique identifier ( 43 ) for a context  307 . As shown, the performance manager  302  then transmits the context  307  having the unique identifier ( 43 ) back to the host device  210 . The agent in the host device  210  stores the unique identifier ( 43 ) in the context cache  354  for this unique combination for these particular values of the two selected attributes (checkout and gold) along this path through the application stack. Additionally, the agent in the host device  210  creates an accumulator  372  for this unique identifier ( 43 ) (assuming the accumulator for this unique identifier has not yet been created). The unique identifier ( 43 ) could then be used to provide a context to the application components further down the application stack (see context  389  below). Also, the agent in the host device  210  can create an accumulator for each unique combination of values of the attributes of the request being monitored (as described above). 
     As part of execution of the application component # 3   237 , the application component # 3   237  transmits a call to the application component # 3   241  for its execution. The call includes the context  389 . In response to receiving the call, the agent in the host device  212  forwards the context  389  to the performance manager  302 . In this example, the performance metric of the application component # 3   241  in the host device  212  is being monitored. 
     In response to receiving the context  389 , the performance manager  302  assigns a unique identifier ( 44 ) for a context  311 . As shown, the performance manager  302  then transmits the context  311  having the unique identifier ( 44 ) back to the host device  212 . The agent in the host device  212  stores the unique identifier ( 44 ) in the context cache  358  for this unique combination for these particular values of the two selected attributes (checkout and gold) along this path through the application stack. Additionally, the agent in the host device  212  creates an accumulator  374  for this unique identifier ( 44 ) (assuming the accumulator for this unique identifier has not yet been created). The unique identifier ( 44 ) could then be used to provide a context to the application components further down the application stack. However, in this example, the application stack along this path is at the bottom in the host device  212 . Also, the agent in the host device  212  can create an accumulator for each unique combination of values of the attributes of the request being monitored (as described above). 
     Similar to  FIG. 3 ,  FIG. 4  also includes additional details of the calling context being carried down through the application stack. In contrast to  FIG. 3 ,  FIG. 4  depicts some embodiments that add additional data to the calling context. In an example  400 , the additional data includes identification of the current host device (host ID). An example  400  of  FIG. 4  also includes the context cache  350 - 356  (as depicted in the example  300  of  FIG. 3 ). 
     Also similar to  FIG. 3 ,  FIG. 4  depicts creating of accumulators by agents in the host device. However, in contrast to  FIG. 3 , the example  400  of  FIG. 4  includes host ID as part of each unique value combination. Accordingly, in addition to unique values of selected attributes of the request, identifier ( 44 ) is also included to create each unique value combination. 
     Similar to  FIG. 3 ,  FIG. 4  includes selected attributes of the request to be monitored. Assume that the selected attributes include transaction and user group. In this example, there are five possible values for transaction and two possible values for user group. There are five possible values for identification of the host device ( 204 ,  206 ,  208 ,  210 , and  212 ). In this example, there are 50 (5×2×5) possible combinations of values for the selected attributes and host ID. Accordingly, each agent can create 50 accumulators in its host device (one accumulator for each possible combination of values for the selected attributes and identifier ( 44 )). 
     As described above, each accumulator stores an accumulated value that comprises a combined value for a given performance metric of an application component in the host device. For instance, if the given performance metric is execution time, each time an execution time is determined this value is added to the current accumulated value for the unique combination. For example, assume that an execution time for a particular application component at one of the levels of the application stack for a first request having a transaction of checkout and a user group of gold and a host ID of AA is 500 milliseconds. The accumulated value for this accumulator is 400 milliseconds. Then, assume that a next execution time for the same application component for a second request having the same values for the selected attributes is 200 milliseconds. The accumulated value for this accumulator is 400 milliseconds plus 200 milliseconds→600 milliseconds. Over time, an average value for this performance metric for this particular application component can be determined by dividing the accumulated value by the number of accumulated values stored in the accumulator. 
     Accordingly, performance metrics at any level of the application stack can be determined for the different application components based on the specific values of the selected attributes for the original request received at the top of the application stack and the host ID. Also, performance metrics can be separated based on the calling context from the top of the application stack at different levels of the application stack. 
     The example  400  of  FIG. 4  also depicts how the calling context of the request is provided to the different levels of the application stack. In particular, in response to the request  202  being received, the agents in the host devices  204 - 206  forward the context  301  that includes values of the different attributes of the request  200  (transaction: checkout, origin geography: Asia, user group: gold, and platform: chrome). In this example, the performance manager  302  has been configured to select attributes of the request  200  relative to the performance metric being monitored. For this example, an administrator may have configured the performance manager  302  to select the attributes, transaction and user group. Also in this example, the performance metric of the transaction  219  in the host device  204  is being monitored. Similarly, the performance metric of the transaction  221  in the host device  206  is being monitored. 
     In response to the request  202 , the agent in the host device  204  forwards the context  301  to the performance manager  302 . In response to receiving the context  301 , the performance manager  302  assigns a unique identifier ( 52 ) for a request having a transaction of checkout, a user group of gold and a host ID of  204 . As shown, the performance manager  302  then transmits the context  405  having the unique identifier ( 52 ) back to the host device  204 . The agent in the host device  204  stores the unique identifier ( 52 ) in the context cache  352  for this unique combination for these particular values of the two selected attributes (checkout and gold) and the host ID of  204 . Additionally, the agent in the host device  204  creates an accumulator  471  for this unique identifier ( 52 ) (assuming the accumulator for this unique identifier has not yet been created). The accumulator  471  is for storage of a performance metric (e.g., execution time, error rate, etc.) of the transaction  219 . For instance, the accumulator  471  can store an accumulated value of the execution time of the transaction  219  across multiple requests being processed. An average execution time can then be determined by dividing the accumulated value by the number of requests processed. 
     In response to the request  202 , the agent in the host device  206  forwards the context  301  to the performance manager  302 . In response to receiving the context  301 , the performance manager  302  assigns a unique identifier ( 72 ) for a request having a transaction of checkout, a user group of gold and a host ID of  206 . As shown, the performance manager  302  then transmits the context  403  having the unique identifier ( 72 ) back to the host device  206 . The agent in the host device  206  stores the unique identifier ( 72 ) in the context cache  350  for this unique combination for these particular values of the two selected attributes (checkout and gold) and the host ID of  206 . Additionally, the agent in the host device  206  creates an accumulator  470  for this unique identifier (assuming the accumulator for this unique identifier has not yet been created). The accumulator  470  is for storage of a performance metric (e.g., execution time, error rate, etc.) of the transaction  221 . For instance, the accumulator  470  can store an accumulated value of the execution time of the transaction  221  across multiple requests being processed. An average execution time can then be determined by dividing the accumulated value by the number of requests processed. 
     As shown in the example  400 , values of the selected attributes are the same for the request  202  being received. Therefore, if only the values of the selected attributes were used to monitor a performance metric, a same unique identifier could be used (see the unique identifier ( 42 ) provided in the context  303  in the example  300  of  FIG. 3 ). However, in the example  400  of  FIG. 4 , the host ID is also used as part of monitoring the performance metric. Specifically, the performance manager  302  assigns two different unique identifiers ( 52  and  72 ) in response to receiving the same context  301  from two different host devices ( 204  and  206 , respectively). 
     As described above, the agent in the host device  204  can create the accumulator  471  for each unique combination of values. Accordingly, assume there are two attributes of the request that are to be monitored. Also, assume the first attribute has five possible values and the second attribute has two possible values. Also, in this example, the host ID is also being used to differentiate requests for performance monitoring. For this instance, the host ID has five possible values ( 204 ,  206 ,  208 ,  210 , and  212 ). In this example, the agent in the host device  204  could create  50  possible accumulators to account for each of the possible value combinations of the attributes and host ID to be monitored. In some embodiments, the agent in the host device  204  creates the accumulator as the value combination is received in a request. 
     Similarly, the agent in the host device  206  creates the accumulator  470  for this unique identifier ( 72 ) (assuming the accumulator for this unique identifier has not yet been created). The accumulator  470  is for storage of a performance metric (e.g., execution time, error rate, etc.) of the transaction  221 . Also, the agent in the host device  206  can create an accumulator for each unique combination of values (as described above). 
     The unique identifier ( 52 ) is then used to provide a context to the application components further down the application stack. For example, as part of the application component # 2   223  requesting execution by the application component # 2   231 , the application component # 2   223  includes a context  417  that includes a path from the top of the application stack. The path includes the unique identifier ( 52 ) and the application component # 2 → 52 /AC# 2 . Similarly, as part of the application component # 1   225  requesting execution by the application component # 1   233 , the application component # 1   225  includes a context  415  that includes a path from the top of the application stack. The path includes the unique identifier ( 52 ) and the application component # 1 → 52 /AC# 1 . 
     As part of the application component # 2   227  requesting execution by the application component # 2   231 , the application component # 2   227  includes a context  413  that includes a path from the top of the application stack. The path includes the unique identifier ( 72 ) and the application component # 2 → 72 /AC# 2 . As part of the application component # 1   229  requesting execution by the application component # 1   233 , the application component # 1   229  includes a context  411  that includes a path from the top of the application stack. The path includes the unique identifier ( 72 ) and the application component # 1 → 72 /AC# 1 . 
     The example  400  of  FIG. 4  also depicts how the calling context of the request is provided to the next level the application stack (applications components in the host devices  208 - 210 ). In particular, as part of execution of the application component # 2   223  or  227 , the application component # 2   223  or  227  transmits a call to the application component # 2   231  for its execution. The call from the application component # 2   223  includes the context  417 . In response to receiving the call, the agent in the host device  208  forwards the context  417  to the performance manager  302 . In this example, the performance metric of the application component # 2   231  in the host device  208  is being monitored. Similarly, the call from the application component # 2   227  includes the context  413 . In response to receiving the call, the agent in the host device  208  forwards the context  413  to the performance manager  302 . In this example, the performance metric of the application component # 2   231  in the host device  208  is being monitored. 
     In response to receiving the context  417 , the performance manager  302  assigns a unique identifier ( 81 ) for a context  488 . As shown, the performance manager  302  then transmits the context  488  having the unique identifier ( 81 ) back to the host device  208 . The agent in the host device  208  stores the unique identifier ( 81 ) in the context cache  356  for this unique combination for these particular values of the two selected attributes (checkout and gold) and the host ID of  208  along this path through the application stack. Additionally, the agent in the host device  208  creates a first accumulator  473  for this unique identifier ( 81 ) (assuming the accumulator for this unique identifier has not yet been created). 
     Similarly, in response to receiving the context  413 , the performance manager  302  assigns a unique identifier ( 83 ) for a context  489 . As shown, the performance manager  302  then transmits the context  489  having the unique identifier ( 83 ) back to the host device  208 . The agent in the host device  208  stores the unique identifier ( 83 ) in the context cache  356  for this unique combination for these particular values of the two selected attributes (checkout and gold) and the host ID of  208  along this path through the application stack. Additionally, the agent in the host device  208  creates a second accumulator  473  for this unique identifier ( 83 ) (assuming the accumulator for this unique identifier has not yet been created). 
     The unique identifier ( 81  and  83 ) could then be used to provide a context to the application components further down the application stack. However, in this example, the application stack along this path is at the bottom in the host device  208 . Also, the agent in the host device  208  can create an accumulator for each unique combination of values of the attributes of the request being monitored and host ID (as described above). 
     As part of their execution, the application components # 1   225  and  229  transmits a call to the application component # 1   233  for its execution. The call from the application component # 1   225  includes the context  415 . In response to receiving the call, the agent in the host device  210  forwards the context  415  to the performance manager  302 . In this example, the performance metric of the application component # 1   233  in the host device  210  is being monitored. Similarly, the call from the application component # 1   229  includes the context  411 . In response to receiving the call, the agent in the host device  210  forwards the context  411  to the performance manager  302 . In this example, the performance metric of the application component # 1   233  in the host device  210  is being monitored. 
     In response to receiving the context  411 , the performance manager  302  assigns a unique identifier ( 73 ) for a context  419 . As shown, the performance manager  302  then transmits the context  419  having the unique identifier ( 73 ) back to the host device  210 . The agent in the host device  210  stores the unique identifier ( 73 ) in the context cache  354  for this unique combination for these particular values of the two selected attributes (checkout and gold) and host ID along this path through the application stack. Additionally, the agent in the host device  210  creates a first accumulator  472  for this unique identifier ( 73 ) (assuming the accumulator for this unique identifier has not yet been created). In response to receiving the context  415 , the performance manager  302  assigns a unique identifier ( 75 ) for a context  421 . As shown, the performance manager  302  then transmits the context  421  having the unique identifier ( 75 ) back to the host device  210 . The agent in the host device  210  stores the unique identifier ( 75 ) in the context cache  354  for this unique combination for these particular values of the two selected attributes (checkout and gold) and host ID along this path through the application stack. Additionally, the agent in the host device  210  creates a second accumulator  472  for this unique identifier (assuming the accumulator for this unique identifier has not yet been created). 
     The unique identifier ( 73 ) is then used to provide a context to the application components further down the application stack. For example, as part of the application component # 3   237  requesting execution by the application component # 3   241 , the application component # 3   237  can include a context  473  that includes a path from the top of the application stack. The path includes the unique identifier ( 73 ) and the application component # 3 → 73 /AC# 3 . Similarly, the unique identifier ( 75 ) is then used to provide a context to the application components further down the application stack. For example, as part of the application component # 3   237  requesting execution by the application component # 3   241 , the application component # 3   237  can include a context  471  that includes a path from the top of the application stack. The path includes the unique identifier ( 75 ) and the application component # 3 → 75 /AC# 3 . 
     In response to receiving the call having the context  471  or the context  473 , the agent in the host device  212  forwards the context  471  or the context  473  to the performance manager  302 . In this example, the performance metric of the application component # 3   241  in the host device  212  is being monitored. 
     In response to receiving the context  471 , the performance manager  302  assigns a unique identifier ( 98 ) for a context  475 . As shown, the performance manager  302  then transmits the context  475  having the unique identifier ( 98 ) back to the host device  212 . The agent in the host device  212  stores the unique identifier ( 98 ) in the context cache  358  for this unique combination for these particular values of the two selected attributes (checkout and gold) and host ID  212  along this path through the application stack. Additionally, the agent in the host device  212  creates a first accumulator  474  for this unique identifier ( 98 ) (assuming the accumulator for this unique identifier has not yet been created). The unique identifier ( 98 ) could then be used to provide a context to the application components further down the application stack. However, in this example, the application stack along this path is at the bottom in the host device  212 . 
     In response to receiving the context  473 , the performance manager  302  assigns a unique identifier ( 99 ) for a context  477 . As shown, the performance manager  302  then transmits the context  477  having the unique identifier ( 99 ) back to the host device  212 . The agent in the host device  212  stores the unique identifier ( 99 ) in the context cache  358  for this unique combination for these particular values of the two selected attributes (checkout and gold) and host ID  212  along this path through the application stack. Additionally, the agent in the host device  212  creates a second accumulator  474  for this unique identifier ( 99 ) (assuming the accumulator for this unique identifier has not yet been created). The unique identifier ( 99 ) could then be used to provide a context to the application components further down the application stack. However, in this example, the application stack along this path is at the bottom in the host device  212 . Also, the agent in the host device  212  can create an accumulator for each unique combination of values of the attributes of the request being monitored (as described above). 
       FIG. 5  depicts two examples of the number of accumulators created based on the number possible values of the selected attributes (and number of host devices), according to some embodiments.  FIG. 5  depicts three host devices  204 ,  206 , and  212 . However, for this example, assume there are five host devices  204 ,  206 ,  208 ,  210 , and  212  (similar to the examples depicted in  FIGS. 2-4 ).  FIG. 5  also depicts two contexts—a context  502  and a context  504 . 
     The context  502  is for two selected attributes—an attribute A and an attribute B. The attribute A has four possible values, and the attribute B has two possible values. Therefore, in this example, eight (4×2) accumulators can be created in each host device by an agent therein. 
     The context  504  is also for two selected attributes—the attribute B and an attribute D. The attribute B has two possible values, and the attribute D has two possible values. Unlike the context  502 , the context  504  is also based on identification of the host device. The host device ID has five possible values. Therefore, in this example, 20 (2×2×5) accumulators can be created in each host device by an agent therein. Also, each of the accumulators has an associated unique identifier provided by the performance manager  302  (as described above). 
     Example Operations 
       FIGS. 6-7  depict flowcharts that includes performance metric contextualization, according to some embodiments. A flowchart  600  of  FIG. 6  and a flowchart  700  of  FIG. 7  are described with reference to the example  300  of  FIG. 3 . Operations of the flowcharts  600 - 700  are also applicable to the example  400  of  FIG. 4 . Operations of the flowcharts  600 - 700  continue between each other through transition points A-C. Operations of the flowcharts  600 - 700  can be performed by software, firmware, hardware or a combination thereof. The operations of the flowchart  600  start at block  602 . 
     A request to perform a transaction is received at a top of an application stack ( 602 ). With reference to  FIG. 3 , the transaction  219  in the host device  204  or the transaction  221  in the host device  206  receive the request  202 . In this example, the transaction  219  or  221  would be considered the application component at the top of the application stack. 
     Execution of the application component is initiated ( 604 ). With reference to  FIG. 3 , the transaction  219  in the host device  204  or the transaction  221  in the host device  206  is the application component being executed. 
     A calling context defining a unique combination is determined ( 606 ). The unique combination includes a value of at least one selected attribute of the request and a path from the top of the application stack to the current application component being executed. With reference to  FIG. 3 , the selected attributes included the type of transaction and type of user group of the request. For this example, a value of the type of transaction is checkout, and a value of the type of user group is gold. In some embodiments, the agent executing in the host device  204  or  206  forwards the request  202  to the performance manager  302 . The attributes that are selected can be a configurable parameter selectable by an administrator, developer, user, etc. that is monitoring performance metrics of the application components. The performance manager  302  can use this selection to determine the values of the selected attributes. In some embodiments, the performance manager  302  can determine the values by extracting the values from cookies included with the request, data embedded in a HyperText Transfer Protocol (HTTP) request, data included in any query parameters, etc. Also, in some embodiments, ID of the host device is also part of the calling context (as described in reference to the example  400  of  FIG. 4 ). The performance manager  302  can determine ID of the host device based on a source address from which the context  301  is received. In this example, ID of the host device can be the ID for the host device  204  or  206 . 
     A determination is made of whether the unique combination for the calling context has already been assigned a unique identifier and an associated accumulator been created ( 608 ). With reference to  FIG. 3 , the performance manager  302  can make the determination of whether the unique combination for the calling context has already been assigned a unique identifier. For example, the performance manager  302  can perform a lookup into a table of unique combinations that have been assigned to a unique identifier. The agent for the host device having the application component that is being executed determines whether an associated accumulator has been created. With reference to the example  300  of  FIG. 3 , the agent executing in the host device  204  can determine whether an associated accumulator has been created within a storage in the host device (one of the accumulators  371  associated with the unique identifier). Accordingly, there is a one-to-one relationship between the number of accumulators in a host device and the unique identifiers provided to the host device by the performance manager  302 . If a unique identifier has already been assigned and an associated accumulator has been created, operations of the flowchart  600  continue at  612 . Otherwise, operations of the flowchart  600  continue at  610 . 
     A unique identifier is assigned and an associated accumulator is created for the unique combination of the calling context of the request ( 610 ). With reference to  FIG. 3 , the performance manager  302  can assign a unique identifier based on unique combination of the values of the selected attributes (and possibly the ID of the host device). For instance, a table can unique combinations for values of these selected attributes (and possibly the ID of the host device) across all the host devices having application components that are part of the application stack. Accordingly, an identifier assigned is unique across all of the host devices. For example, the performance manager  302  can assign unique identifiers in an ascending order starting at some initial value to ensure there is no duplication among assigned identifiers. With reference to the example  300  of  FIG. 3 , the agent executing in the host device  204  can create the accumulator for this unique combination in some type of machine-readable media (e.g., a hard disk, a random access memory (RAM), a Flash memory, an optical storage device, a magnetic storage device, etc.) in the host device  204 . 
     The performance metric related to execution of the application component is monitored. With reference to  FIG. 3 , the agent can monitor the performance metric (e.g., execution time, error rate, etc.). For example, with reference to  FIG. 1 , the probes attached to the application component can provide various data (e.g., event notification, errors generated, etc.). Based on the data received from the probes, the agent can determine the performance metric. For instance, for the example  300  of  FIG. 3 , the agent in the host device  204  can monitor the execution time of the transaction  219 . In this instance, the execution time includes execution time of the application components called directly or indirectly further down in the application stack as part of the execution of the transaction  219 . For example, the execution time of the transaction  219  can include the time of execution of the application component # 2   223 , the application component # 2   231 , the application component  235 , the application component # 1   225 , the application component # 1   233 , the application component  239 , the application component # 3   237 , the application component # 3   241 , the application component  243 , and the application component  245 . 
     A determination is made of whether execution of the application component calls a next application component in the application stack ( 614 ). With reference to  FIG. 3 , the agent in the host device can make this determination. For the example  300  of  FIG. 3 , the agent in the host device  204  determines that the transaction  219  calls the application component # 2   223  and the application component # 1   225  as part of its execution. If a determination is made that execution of the application component calls a next application component in the application stack, operations of the flowchart  600  continue at transition point A, which continues at transition point A of the flowchart  700 . If a determination is made that execution of the application component does not call a next application component in the application stack, operations of the flowchart  600  continue at transition point B, which continues at transition point B of the flowchart  700 . 
     Operations of the flowchart  700  are now described. From transition point A, operations of the flowchart  700  continue at  702 . 
     A determination is made of whether the next application component to be executed is in a different host device ( 702 ). With reference to  FIG. 3 , the agent in the host device can make this determination. For example, a probe attached to the current application component can provide data that includes a destination address of the next application component that is called. Based on the destination address, the agent can determine whether the application component is in a different host device. If the next application component to be executed is in a different host device, operations of the flowchart  700  continue at  704 . Otherwise, operations of the flowchart  700  continue at transition point C, which continues at transition point C of the flowchart  600 . From the transition point C of the flowchart  600 , operations return to initiate execution of the next application component in the application stack. While described as calling one application component, in some embodiments, an application component can call more than one. Accordingly, there can be multiple application components executing at a same time. 
     A call (that includes the calling context&#39;s ID) is transmitted to the different host device to invoke execution of the next application component in the application stack ( 704 ). As an example with reference to  FIG. 3 , the application component # 2   223  in the host device  204  calls the application component # 2   231  in the host device  208 . As shown, the context  381  (the calling context) is included with the call. The context  381  includes a path that defines a path from the top to this point in the application stack. In this instance, the path includes the unique identifier  42  and identification the application component that made the call (AC# 2 ). Based on these two pieces of data, a path from the top of the application stack to the application component # 2   231  can be defined. As another example with reference to  FIG. 3 , the application component # 3   237  in the host device  210  calls the application component # 3   241  in the host device  212 . As shown, the context  389  (the calling context) is included with the call. The context  389  includes a path that defines a path from the top to this point in the application stack. In this instance, the path includes the unique identifier  43  and identification the application component that made the call (AC# 3 ). Based on these two pieces of data, a path from the top of the application stack to the application component # 3   241  can be defined. Operations of the flowchart  700  continue at transition point C, which continues at transition point C of the flowchart  600 . 
     From transition point B, operations of the flowchart  700  continue at  706 . Execution of the application components complete execution moving back up the application stack ( 706 ). Also, the associated accumulators are updated based on a performance metric as application components complete execution. For example, with reference to  FIG. 3 , the application component # 2   231  calls the application component  235  as part of its execution. After the application component  235  completes execution, control moves back up the application stack to the application component # 2   231 . The application component # 2   231  resumes and then completes execution. After its completion, the agent in the host device  208  updates the accumulator for this calling context. For instance, if the performance metric is execution time, the agents adds a value of time of execution completion to the accumulated value stored in the associated accumulator. Continuing up the application stack, after completion by the application component # 2   231  in the host device  208 , the application component # 2   223  can complete its execution. After both the application component # 2   223  and the application component # 1   225  complete execution, the transaction  219  can complete its execution. After the transaction  219  completes its execution, the agent in the host device  204  updates the accumulator for this calling context. As described above, the accumulator being updated is associated with a performance metric for the transaction  219 . For instance, if the performance metric is execution time, the agents adds a value of time of execution completion to the accumulated value stored in the associated accumulator. Operations of the flowcharts  600 - 700  are complete. 
     Example Computer Device 
       FIG. 8  depicts an example computer device, according to some embodiments. The computer device includes a processor  801  (possibly including multiple processors, multiple cores, multiple nodes, and/or implementing multi-threading, etc.). The computer device includes memory  807 . The memory  807  may be system memory (e.g., one or more of cache, SRAM, DRAM, zero capacitor RAM, Twin Transistor RAM, eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONOS, PRAM, etc.) or any one or more of the above already described possible realizations of machine-readable media. 
     The computer device also includes a persistent data storage  809 . The persistent data storage  809  can be a hard disk drive, such as magnetic storage device. The computer device also includes a bus  803  (e.g., PCI, ISA, PCI-Express, HyperTransport® bus, InfiniBand® bus, NuBus, etc.) and a network interface  805  (e.g., a Fiber Channel interface, an Ethernet interface, an interne small computer system interface, SONET interface, wireless interface, etc.). 
     The computer device also includes a performance manager  811 . The performance manager  811  can perform operations to track events during execution of application(s) and provide unique identifications for different contexts for monitoring performance metrics, as described above. Any one of the previously described functionalities may be partially (or entirely) implemented in hardware and/or on the processor  801 . For example, the functionality may be implemented with an application specific integrated circuit, in logic implemented in the processor  801 , in a co-processor on a peripheral device or card, etc. Further, realizations may include fewer or additional components not illustrated in  FIG. 8  (e.g., video cards, audio cards, additional network interfaces, peripheral devices, etc.). The processor  801 , the network interface  805 , and the persistent data storage  809  are coupled to the bus  803 . Although illustrated as being coupled to the bus  803 , the memory  807  may be coupled to the processor  801 . 
     Variations 
     The flowcharts are provided to aid in understanding the illustrations and are not to be used to limit scope of the claims. The flowcharts depict example operations that can vary within the scope of the claims. Additional operations may be performed; fewer operations may be performed; the operations may be performed in parallel; and the operations may be performed in a different order. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by program code. The program code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable machine or apparatus. 
     As will be appreciated, aspects of the disclosure may be embodied as a system, method or program code/instructions stored in one or more machine-readable media. Accordingly, aspects may take the form of hardware, software (including firmware, resident software, micro-code, etc.), or a combination of software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” The functionality presented as individual modules/units in the example illustrations can be organized differently in accordance with any one of platform (operating system and/or hardware), application ecosystem, interfaces, programmer preferences, programming language, administrator preferences, etc. 
     Any combination of one or more machine readable medium(s) may be utilized. The machine readable medium may be a machine readable signal medium or a machine readable storage medium. A machine readable storage medium may be, for example, but not limited to, a system, apparatus, or device, that employs any one of or combination of electronic, magnetic, optical, electromagnetic, infrared, or semiconductor technology to store program code. More specific examples (a non-exhaustive list) of the machine readable storage medium would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a machine readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine readable storage medium is not a machine readable signal medium. 
     A machine readable signal medium may include a propagated data signal with machine readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A machine readable signal medium may be any machine readable medium that is not a machine readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. 
     Program code embodied on a machine readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as the Java® programming language, C++ or the like; a dynamic programming language such as Python; a scripting language such as Perl programming language or PowerShell script language; and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on a stand-alone machine, may execute in a distributed manner across multiple machines, and may execute on one machine while providing results and or accepting input on another machine. 
     The program code/instructions may also be stored in a machine readable medium that can direct a machine to function in a particular manner, such that the instructions stored in the machine readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks. 
     While the aspects of the disclosure are described with reference to various implementations and exploitations, it will be understood that these aspects are illustrative and that the scope of the claims is not limited to them. In general, techniques for performing metric contextualization in distributed computing environments as described herein may be implemented with facilities consistent with any hardware system or hardware systems. Many variations, modifications, additions, and improvements are possible. 
     Plural instances may be provided for components, operations or structures described herein as a single instance. Finally, boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the disclosure. In general, structures and functionality presented as separate components in the example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the disclosure. 
     As used herein, the term “or” is inclusive unless otherwise explicitly noted. Thus, the phrase “at least one of A, B, or C” is satisfied by any element from the set {A, B, C} or any combination thereof, including multiples of any element.