Abstract: A system uses agents to monitor a distributed business transaction as well as monitor changes in software configuration. An agent may detect a file load, such a class load, obtain portions of the file such as functions, and perform a hash on the byte code functions. A hash tree may then be constructed and compared to previous states of the system. The hash tree may be generated, for example, at each file loading detected, so that system states can be compared. Differences in hash trees are detected and the changes are reported to an administrator of the system that provides the distrusted business transaction.

Abstract: An application which utilizes a single thread is monitored and context for the individual requests and business transactions operating on that platform are provided. A wrapper is placed is around an object that calls a request. The wrapper renames a request object. Request objects are renamed with a unique name when they are called. When a call stack is sampled, the sampler will retrieve the unique name. Performance data associated with the unique name may be correlated to a business transaction and particular request as metrics are subsequently analyzed. For subsequent reporting, such as call graph reporting, the report or call graph will have requests in the context of a particular business transaction and a particular request instance. This provides more context in reporting of an business application request for frameworks that utilize as single request for multiple threads.

Abstract: An interface for communicating the status of a distributed business transaction using widgets is provided. The widgets may be dynamically identified and automatically created such that they are useful and of interest to a user of the dashboard. The location of the widgets within the dashboard may be dynamically positioned such that the most important widgets are provided to preferred locations for particular user.

Abstract: The present technology adds code to a top level build configuration file of a configuration program that will gather metrics for each invocation of a build. These metrics are sent to a commonly accessible metric server for future analysis. The metrics are collected for a distributed engineering team over several machines. Compilation time metrics may then be collected for each compilation event and those metrics are analyzed by a common aggregator.

Abstract: Asynchronous handoffs between threads and other software components may be automatically detected, and the corresponding working objects may be tracked. The system may report monitoring information for an overall transaction that includes the original request and corresponding asynchronous requests. Automatically detecting asynchronous requests may include instrumenting a virtual machine, such as a Java Virtual Machine (JVM), to detect the creation of thread handoff objects and the object and/or thread execution. Thread handoff objects may automatically tracked, tracked based on data learned over time, tracked based on user input, and otherwise configured. In some embodiments, after detecting the creation of a thread handoff object, an identification of the object of the call may be identified as being tracked in another server or application.

Abstract: A transmitted transport communication protocol (TCP) packet in an established TCP connection is intercepted and resent with a modified IP layer to determine network nodes within a network path. No new connection is required, and the data may be transmitted to its intended location as part of the existing connection, bypassing firewalls and other obstacles commonly affecting ping commands. The change to the IP layer may include a modified TTL value. Address location and response time may be determined for each node in a network path.

Abstract: A system determines the performance of a network within the context of an application using that network. Network data is collected and correlated with an application that uses the network as well as a distributed transaction implemented by the application. The collected network data is culled, and the remaining data is rolled up into one or more metrics. The metrics, selected network data, and other data are reported in the context of the application that implements part of the distributed transaction. In this manner, specific network performance and architecture data is reported along with application context information.

Abstract: The present technology utilizes agents to monitor and report data from Java virtual machines (JVM) to a controller as part of application performance monitoring. When a JVM is loaded, code defining an interface for agents is loaded as well. A determination may be made as to whether the loaded agent implements the interface defined at the JVM. If the loaded agent does not implement the interface, for example if it is missing one or more methods defined by the interface, the agent class may be modified to define the missing methods. The modification to the agent class may be made after compilation but before the class is loaded into the JVM.

Abstract: Asynchronous operations associated with a request such as synchronous threads, runnable elements, callable elements, and other invokable objects are tracked to determine the metrics about the request and operations. The present technology tracks the start and end of each asynchronous operation and maintains a counter which tracks the currently executing asynchronous operations. By monitoring the request, the start and end of each asynchronous operation associated with the request, and the number of asynchronous operations currently executing, the present technology may identify the end of a request by identifying when the last asynchronous operation associated with the request ends. In some instances, the present technology identifies the end of a request when a counter which tracks the number of asynchronous operations executing reaches a value of zero after the first asynchronous operation has already begun.

Abstract: A dynamic service module is embedded in an agent and able to add functionality to the agent. The service module may manage .jar files for execution by the agent. The service module may receive the .jar files, provide them to an agent for execution, and may perform other functions. The agent may perform obfuscation in order to translate the .jar files into a modified version which may be more compatible with a particular agent. Once execution of the .jar file is complete, the agent may remove the .jar file as well as all trace of the .jar file. For example, the agent may remove byte code instrumentation that was installed as a result of the .jar file.

Abstract: Business transactions and the nodes processing the transactions may be monitored. Actions may be applied to one or more nodes when a performance issue is detected. A performance issue may relate to a metric associated with a transaction or node that processes the transaction. If a performance metric does not satisfy a health rule, the policy determines which action should be performed to correct the performance of the node. The corrective action may be applied to a node other than the node at which the performance metric is associated with. For example, if a performance metric for a first node does not satisfy a threshold, the corrective action may be applied to a second node. When a solution applied to a second node is found to correct the problem in first node, the solution may be applied to the other nodes experiencing the same problem.

Abstract: Application performance data and machine health are collected by a system. The system correlates the two data types to provide context as to how machine health affects the performance of an application. Performance data for an application, for example an application executing as part of a distributed business transaction, and health data for a machine which hosts the application are collected. The performance data and machine health data may be correlated for a particular period of time. The correlation may then be reported to a user. By viewing the correlation, a user may see when machine health was good and bad, and may identify the effects of the machine health on the performance of an application.

Abstract: An interface is provided for a user to create a custom dashboard for providing application performance data. The dashboard may be created from one or more widgets, such as graphs, charts, and other display components, and each widget may be individually configured with parameters. The dashboard may be configured to display data for one or more particular transactions, transaction types, or transactions that meet specified criteria. Once created, the dashboard may be shared through a website URL, e-mail, or other method.

Abstract: A system monitors applications and network flows used during the business transaction to determine distributed business transaction anomalies caused at least in part by network performance issues. A network flow associated with a business transaction is monitored by a network agent. The network agent may capture packets, analyze the packets and other network data to determine one or more baselines, and dynamically compare subsequent network flow performance to those baselines to determine an anomaly. When an anomaly in a network flow is detected, this information may be provided to a user along with other data regarding a business transaction that is utilizing the network flow. Concurrently with the network agent monitoring, application agents may monitor one or more applications performing the business transaction. The present system reports performance data for a business transaction in terms of application performance and network performance, all in the context of a distributed business transaction.

Abstract: A dynamic monitoring process begins with configuring a start and end method to be monitored. The dynamic monitoring process may intercept both the start and end methods as and when the loader is initiated or at runtime to dynamically attach and detach the instrumentation. A loader may then be modified to call a library method upon detection of the start method. The library method may serve as a notification to the start of the method and causes a reflector to retrieve information from the incoming request. The incoming information may include data from which a business transaction name may be determined. The business transaction name is then associated with the monitoring of the particular request. When an exit call is detected, a call may be made to the library for a method which invokes a decorator. The decorator may insert business transaction name and other data into the outgoing call.

Abstract: The present technology adds code to a top level build configuration file of a configuration program that will gather metrics for each invocation of a build. These metrics are sent to a commonly accessible metric server for future analysis. The metrics are collected for a distributed engineering team over several machines. Compilation time metrics may then be collected for each compilation event and those metrics are analyzed by a common aggregator.

Abstract: A transmitted transport communication protocol (TCP) packet in an established TCP connection is intercepted and resent with a modified IP layer to determine network nodes within a network path. No new connection is required, and the data may be transmitted to its intended location as part of the existing connection, bypassing firewalls and other obstacles commonly affecting ping commands. The change to the IP layer may include a modified TTL value. Address location and response time may be determined for each node in a network path.

Abstract: A system monitors a network or web application provided by one or more distributed applications and provides data for each and every method instance in an efficient low-cost manner. Agents may monitor the performance of the distributed application by the web services and report monitoring data as runtime data to the remote server, for example a controller. The controller may analyze the data to identify one or more performance issues or “hot spot” methods based on current or past performance, functionality, content, or business relevancy. Instructions and/or configuration information may be transmitted by the controller to the agents that correspond to a particular business transaction portion associated with a hot spot. The portions are then monitored to collect data associated with the hot spot and the hot spot data is reported back to the controller.

Abstract: A system determines the performance of a network within the context of an application using that network. Network data is collected and correlated with an application that uses the network as well as a distributed transaction implemented by the application. The collected network data is culled, and the remaining data is rolled up into one or more metrics. The metrics, selected network data, and other data are reported in the context of the application that implements part of the distributed transaction. In this manner, specific network performance and architecture data is reported along with application context information.

Abstract: An application which utilizes a single thread is monitored and context for the individual requests and business transactions operating on that platform are provided. A wrapper is placed is around an object that calls a request. The wrapper renames a request object. Request objects are renamed with a unique name when they are called. When a call stack is sampled, the sampler will retrieve the unique name. Performance data associated with the unique name may be correlated to a business transaction and particular request as metrics are subsequently analyzed. For subsequent reporting, such as call graph reporting, the report or call graph will have requests in the context of a particular business transaction and a particular request instance. This provides more context in reporting of an business application request for frameworks that utilize as single request for multiple threads.