Abstract: According to one or more embodiments of the disclosure, techniques herein provide for auto discovery of network proxies. In particular, in one embodiment, a controller in a computer network receives, from both source devices and destination devices, corresponding Transmission Control Protocol/Internet Protocol (TCP/IP) information and associated transaction identifiers (IDs) for packets sent by the source devices and for packets received at the destination devices. The controller may then correlate particular source TCP/IP information to particular destination TCP/IP information based on associated transaction IDs being the same, and can compare the correlated source TCP/IP information and destination TCP/IP information in order to determine whether a proxy device exists (e.g., and which particular type of proxy device exists) between the source device and the destination device.

Abstract: In one embodiment, a resource allocation process determines a plurality of service levels of applications (e.g., business transactions) during a monitored period, and examines infrastructure performance data (utilization of a plurality of resources and a plurality of performance metrics) of a plurality of services in a microservices architecture in relation to each of the plurality of service levels of the applications. Accordingly, a resource capacity model can be generated for the microservices architecture based on the service dependency and the infrastructure performance data across the plurality of service levels, the resource capacity model defining a required capacity of resources to satisfy specified performance metric constraints during operation of the applications at given service levels.

Abstract: In one embodiment, a process on a computer receives a callback in response to an intercepted outbound web service connection called by an application executing on the computer. The process extracts information from the callback, e.g., at least a URL for the outbound web service connection and a code location within the application from which the outbound web service connection was called. Additionally due to the callback, the process obtains access to a core TCP socket for the outbound web service connection. The process determines how to modify socket options of the core TCP socket based on selected criteria according to the extracted information from the callback, and may then modify the socket options of the core TCP socket according to the determining. The modified socket options thus cause downstream network devices to handle traffic on the outbound web service connection based on the modified socket options.

Abstract: According to one or more embodiments of the disclosure, techniques herein provide for auto discovery of network proxies. In particular, in one embodiment, a controller in a computer network receives, from both source devices and destination devices, corresponding Transmission Control Protocol/Internet Protocol (TCP/IP) information and associated transaction identifiers (IDs) for packets sent by the source devices and for packets received at the destination devices. The controller may then correlate particular source TCP/IP information to particular destination TCP/IP information based on associated transaction IDs being the same, and can compare the correlated source TCP/IP information and destination TCP/IP information in order to determine whether a proxy device exists (e.g., and which particular type of proxy device exists) between the source device and the destination device.

Abstract: In one embodiment, a proxying agent loaded at application startup loads a circuit breaker framework into a class loader, and also loads a circuit breaker proxy into an extension class loader seen by the proxying agent and by the application. The proxying agent may also instrument selected methods of the application, such that, when calling to run an instrumented method: an ID of the circuit breaker proxy is set to a trackable context, and the proxy execution may be held until exit of the run method (and if exit of the run method is due to a particular exception, an exception of the proxy may also be set to reflect the particular exception). The circuit breaker may then monitor the proxy for latency, exceptions, and circuit breaker trip criteria, and stops the run method in response to the latency, exceptions, or circuit breaker trip criteria surpassing a particular respective threshold.

Abstract: According to one or more embodiments of the disclosure, techniques herein provide for auto discovery of network proxies. In particular, in one embodiment, a controller in a computer network receives, from both source devices and destination devices, corresponding Transmission Control Protocol/Internet Protocol (TCP/IP) information and associated transaction identifiers (IDs) for packets sent by the source devices and for packets received at the destination devices. The controller may then correlate particular source TCP/IP information to particular destination TCP/IP information based on associated transaction IDs being the same, and can compare the correlated source TCP/IP information and destination TCP/IP information in order to determine whether a proxy device exists (e.g., and which particular type of proxy device exists) between the source device and the destination device.

Abstract: In one embodiment, a resource allocation process determines a plurality of service levels of applications (e.g., business transactions) during a monitored period, and examines infrastructure performance data (utilization of a plurality of resources and a plurality of performance metrics) of a plurality of services in a microservices architecture in relation to each of the plurality of service levels of the applications. Accordingly, a resource capacity model can be generated for the microservices architecture based on the service dependency and the infrastructure performance data across the plurality of service levels, the resource capacity model defining a required capacity of resources to satisfy specified performance metric constraints during operation of the applications at given service levels.

Abstract: In one embodiment, a proxying agent loaded at application startup loads a circuit breaker framework into a class loader, and also loads a circuit breaker proxy into an extension class loader seen by the proxying agent and by the application. The proxying agent may also instrument selected methods of the application, such that, when calling to run an instrumented method: an ID of the circuit breaker proxy is set to a trackable context, and the proxy execution may be held until exit of the run method (and if exit of the run method is due to a particular exception, an exception of the proxy may also be set to reflect the particular exception). The circuit breaker may then monitor the proxy for latency, exceptions, and circuit breaker trip criteria, and stops the run method in response to the latency, exceptions, or circuit breaker trip criteria surpassing a particular respective threshold.

Abstract: In one embodiment, a network analysis process initiates network path analysis for a transaction application operating over a logical transaction path having a first segment from a first set of transaction servers to a load balancer and a second segment then to a second set of transaction servers. The network path analysis, when for the second segment, comprises: selecting a receiving transaction server of the second set of transaction servers; identifying a TCP session associated with the transaction application already in progress to the receiving transaction server; initiating a TCP traceroute using ACK packets, whose signature matches the in-progress TCP session, from the receiving transaction server to the load balancer; and determining, in reverse, a network path of layer-3 segments and associated network metrics between the receiving transaction server and the load balancer.

Abstract: In one aspect, a system for correlating application performance data with hardware performance data via heat maps is disclosed. The system includes: a processor; a memory; and one or more modules stored in the memory and executable by a processor to perform operations. The operations include: receive data associated with monitored applications and hardware; identify application performance data and hardware performance data from the received data; generate interactive heat maps of the application performance data and interactive heat maps of the hardware performance data; provide a user interface for displaying the generated heat maps; and display, through the user interface, the generated heat maps of the application performance data and the generated heat maps of the hardware performance data using a common time scale.

Abstract: In one embodiment, a process on a computer receives a callback in response to an intercepted outbound web service connection called by an application executing on the computer. The process extracts information from the callback, e.g., at least a URL for the outbound web service connection and a code location within the application from which the outbound web service connection was called. Additionally due to the callback, the process obtains access to a core TCP socket for the outbound web service connection. The process determines how to modify socket options of the core TCP socket based on selected criteria according to the extracted information from the callback, and may then modify the socket options of the core TCP socket according to the determining. The modified socket options thus cause downstream network devices to handle traffic on the outbound web service connection based on the modified socket options.

Abstract: In one embodiment, a network analysis process initiates network path analysis for a transaction application operating over a logical transaction path having a first segment from a first set of transaction servers to a load balancer and a second segment then to a second set of transaction servers. The network path analysis, when for the second segment, comprises: selecting a receiving transaction server of the second set of transaction servers; identifying a TCP session associated with the transaction application already in progress to the receiving transaction server; initiating a TCP traceroute using ACK packets, whose signature matches the in-progress TCP session, from the receiving transaction server to the load balancer; and determining, in reverse, a network path of layer-3 segments and associated network metrics between the receiving transaction server and the load balancer.

Abstract: In one embodiment, an agent process produces synthetic packet traffic and iteratively performs a sub-process that determines isolated network segments of the communication channel between intermediate nodes and computes a set of network metrics for the isolated network segments based at least in part on incrementing TTL expiry error data points. The sub-process also encapsulates, for inclusion within the next packet to be sent, a list of intermediate node IDs along the communication channel up to a latest received node ID and computed sets of network metrics for respective network segments. The agent process may then generate, upon termination of the sub-process, a report, the report including the list of intermediate node IDs along the communication channel up to a latest received node ID and computed sets of network metrics for respective network segments.

Abstract: In one embodiment, a process on a computer receives a callback in response to an intercepted outbound web service connection called by an application executing on the computer. The process extracts information from the callback, e.g., at least a URL for the outbound web service connection and a code location within the application from which the outbound web service connection was called. Additionally due to the callback, the process obtains access to a core TCP socket for the outbound web service connection. The process determines how to modify socket options of the core TCP socket based on selected criteria according to the extracted information from the callback, and may then modify the socket options of the core TCP socket according to the determining. The modified socket options thus cause downstream network devices to handle traffic on the outbound web service connection based on the modified socket options.

Abstract: A cluster analysis feature is provided to monitor and troubleshoot infrastructure issues impacting a distributed business application. Performance trends of one or more tiers of applications may be monitored, analyzed, and reported. By monitoring and reporting performance issues for tiers of applications, valuable time is saved from to individually go through each application individually. Agents installed on individual applications may monitor the performance of applications, collect metrics, aggregate the metrics and report the metrics back to a server. Clustering algorithms may be used to cluster infrastructure metrics and then correlate those metrics with the application nodes using the same algorithms.

Abstract: In one embodiment, a network agent, associated with an operating system of a computing device, tracks socket connection calls made by a plurality of cotenant processes on the computing device that share a common network transport between the computing device and a remote computing device. The network agent may then extract a process identification (ID) for the socket connection calls, the process ID identifying which particular cotenant process of the plurality of cotenant processes is making each particular socket connection call. While monitoring network metrics of network traffic flows over socket connections between the computing device and the remote computing device, the network agent may attribute given network metrics from particular socket connections to a corresponding cotenant process based on the correlated process ID for the socket connection. As such, the network agent may then report the network metrics as attributed to the corresponding cotenant processes.

Abstract: In one embodiment, a process on a computer receives a callback in response to an intercepted outbound web service connection called by an application executing on the computer. The process extracts information from the callback, e.g., at least a URL for the outbound web service connection and a code location within the application from which the outbound web service connection was called. Additionally due to the callback, the process obtains access to a core TCP socket for the outbound web service connection. The process determines how to modify socket options of the core TCP socket based on selected criteria according to the extracted information from the callback, and may then modify the socket options of the core TCP socket according to the determining. The modified socket options thus cause downstream network devices to handle traffic on the outbound web service connection based on the modified socket options.

Abstract: According to one or more embodiments of the disclosure, techniques herein provide for auto discovery of network proxies. In particular, in one embodiment, a controller in a computer network receives, from both source devices and destination devices, corresponding Transmission Control Protocol/Internet Protocol (TCP/IP) information and associated transaction identifiers (IDs) for packets sent by the source devices and for packets received at the destination devices. The controller may then correlate particular source TCP/IP information to particular destination TCP/IP information based on associated transaction IDs being the same, and can compare the correlated source TCP/IP information and destination TCP/IP information in order to determine whether a proxy device exists (e.g., and which particular type of proxy device exists) between the source device and the destination device.

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: In one embodiment, techniques herein monitor activity of one or more applications in a computer network, and identify individual business transactions occurring within the one or more applications. Additionally, network traffic metrics within the computer network may be determined, and particular network traffic metrics can be correlated to each of the individual business transactions. By developing a baseline of network traffic metrics based on network traffic metrics of one or more individual business transactions, a trigger may be detected to perform root cause analysis on the activity of the one or more applications. As such, the techniques herein may initiate, in response to the trigger, root cause analysis on the activity of the one or more applications, where the root cause analysis leverages the correlation of anomalous network traffic metrics to particular business transactions.