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: 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: 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 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, 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 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: 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.

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: In one aspect, the performance of a network within the context of an application using that network is determined for a distributed business transaction. Network data is collected and correlated with a business transaction along with an application that uses the network and implements the distributed business transaction. 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 distributed business transaction. In this manner, specific network performance and architecture data associated with the distributed business transaction is reported along with application context information.

Abstract: A system monitors applications as well as the network flows used during the business transaction, identifies network flows associate with a particular distributed business transaction, and reports the specific network flow data. A network flow associated with a business transaction is monitored by a network agent. The network agent may capture packets, and analyze the packets. Upon request by a user, packet capture can be performed for the specific data flows associated with a distributed business transaction. 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 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 may identify issues in network architectures, such as load balancers operating between machines that process a distributed business transaction, and automatically generate and apply policy updates to such machines. The present system monitors a distributed application through the applications processing the transaction as well as the network flows over which the machines communicate while processing the transaction. By monitoring the network flow and application, the system can tell when an anomaly is caused not by an application but by the network infrastructure itself. Portions of the network infrastructure, such as load balancers, may be singled out as a point of failure and automatically corrected. The failure may be a general degradation of performance or associated with the processing of a particular business transaction.

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 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: Data access optimization features the innovative use of a writer-present flag when acquiring read-locks and write-locks. Setting a writer-present flag indicates that a writer desires to modify a particular data. This serves as an indicator to readers and writers waiting to acquire read-locks or write-locks not to acquire a lock, but rather to continue waiting (i.e., spinning) until the write-present flag is cleared. As opposed to conventional techniques in which readers and writers are not locked out until the writer acquires the write-lock, the writer-present flag locks out other readers and writers once a writer begins waiting for a write-lock (that is, sets a writer-present flag). This feature allows a write-lock method to acquire a write-lock without having to contend with waiting readers and writers trying to obtain read-locks and write-locks, such as when using conventional spinlock implementations.

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: 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.