Cisco Technology, Inc.

Appdynamics, Inc.

Harish Nataraj

Ajay Chandel

Prakash Kaligotla

Naveen Kondapalli

Walter Theodore Hulick, Jr

Jyoti Bansal

Bhaskar Sunkara

Nikhar Rakesh Saxena

Adam Leftik

Dhairyashil Dilip Padalkar

Payman Kamali

Divyanshu Mittal

Suneet Lawrence Saldanha

Zachary Julian Sherman

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.

Auto discovery of network proxies

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. As such, the resource allocation process can effectuate, based on the resource capacity model, a specific capacity of resources required for a particular time of operation of the applications at a particular service level.

AI-driven capacity forecasting and planning for microservices apps

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.

Dynamic socket QoS settings for web service connections

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.

Dynamic circuit breaker applications using a proxying agent

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. Specific layer-3 segments of the network path causing performance degradation of the transaction application are then identifiable.

Deep network path analysis for identifying network segments affecting application performance

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.

Correlate application performance with hardware performance via heatmap

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.

Isolation of network segments affecting application performance

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.

Application aware cluster monitoring

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.

Network visibility for cotenant processes

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.

Network aware distributed business transaction anomaly detection

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.

Growing community of inventors

Berkeley, CA, United States of America

Harish Nataraj