|By Sebastian Kruk||
|August 30, 2014 01:00 PM EDT||
Modern Application Performance Management (APM) solutions can be tremendously helpful in delivering end-to-end visibility into the application delivery chain: across all tiers and network sections, all the way to the end user. In previous blog posts we showed how to narrow down to various root causes of the problems that the end users might experience. Those issues ranged from infrastructure through application and network, and through the end-user client application or inefficient use of the software. When the problem comes from the end user application, e.g., a Web 2.0 Web site, user experience management (UEM) solutions can offer broad analysis of possible root causes. Similarly, when an APM fault domain algorithm points to the application, the DevOps team can go deep into the actually executed code and database queries to identify the root cause of the problem.
But what do you do when your APM tool points to the network as the fault domain? How do you identify the real cause behind the network problems? Most of the APM tools stop there, forcing the network team to use separate solutions to monitor the actual network packets.
In this article we show how an Application-Aware Network Performance Management (AANPM) suite can be used to not only zero in on the network problems as the fault domain, but also dive deeper to show the actual trace of network packets in the selected context, captured back at the time when the problem happened.
Isolating Fault Domain to the Network
In one of our blog posts we wrote how Fonterra used our APM tools to identify the problem with SAP application used in the milk churn scanning process. The operations team could easily isolate the fault domain to network problems (see Figure 1); they required, however, further analysis to identify the root cause behind that network problem.
Figure 1: The performance report indicates network problems as the fault domain
In some cases information about loss rate or zero window events is enough to successfully find and resolve the problem. In general, finding the root cause may require you to analyze more detailed, packet level views in order to see exactly what is causing this network performance problem. These details can not only help to determine why we experienced packet loss or zero window events, but also whether the problem was gradually ramping up or if there was a sudden flow control blockage, which would indicate congestion.
For example, a number of users start to experience performance degradation of the service and APM points to the network as the fault domain. The detailed, packet-level analysis can show that the whole service delivery process was blocked by failed initial name resolution.
What Really Happened in the Network?
Why is detailed packet-level analysis so important when our AANPM points to the network?
Let's first consider what happens when we determine fault domain with one of the application delivery tiers. The engineers responsible for that application can start analyzing logs or, better, drill down to single transaction execution steps and often isolate the problem to the actual line of code that was causing the whole performance degradation of the whole application.
However, when our AANPM tells us it is the network, there are no logs or code execution steps to drill down to. Unless we can deliver conclusive and actionable evidence in the form of detailed, packet-level analysis, the network team might have a problem determining the root cause and may remain skeptical whether the network is at fault at all.
This is exactly what happened to one of our customers. An APM solution had correctly identified that there was a performance problem with the web server. The reports showed who was affected and where the users affected by that problem were located when the problem was occurring. The system also pointed toward the network as the primary fault domain.
The network team tried to determine the root cause of the problem. They needed packet level data for that. But, capturing all traffic with a network protocol analyzer after the incident happened not only overloaded the IT team with unnecessary data, but eventually turned out to be a hit and miss.
What the team needed were the network packets at the time the problem occurred, and only those few packets that related to the actual communication realizing affected transactions.
Figure 2: You can drill down to analyze captured network packets in the context of given user operations
For Figure 3, and further insight, click here for the full article.
Apr. 30, 2016 12:30 PM EDT Reads: 415
Apr. 30, 2016 12:00 PM EDT Reads: 2,258
Apr. 30, 2016 11:30 AM EDT Reads: 1,435
Apr. 30, 2016 11:15 AM EDT Reads: 868
Apr. 30, 2016 11:00 AM EDT Reads: 837
Apr. 30, 2016 11:00 AM EDT Reads: 824
Apr. 30, 2016 11:00 AM EDT Reads: 890
Apr. 30, 2016 10:00 AM EDT Reads: 670
Apr. 30, 2016 09:45 AM EDT Reads: 645
Apr. 30, 2016 09:45 AM EDT Reads: 2,539
Apr. 30, 2016 09:45 AM EDT Reads: 927
Apr. 30, 2016 09:30 AM EDT Reads: 938
Apr. 30, 2016 06:00 AM EDT Reads: 2,450
Apr. 29, 2016 09:00 PM EDT Reads: 1,558
Apr. 29, 2016 04:30 PM EDT Reads: 1,794
Apr. 29, 2016 03:45 PM EDT Reads: 1,648
Apr. 29, 2016 03:30 PM EDT Reads: 1,682
Apr. 29, 2016 02:30 PM EDT Reads: 1,432
Apr. 29, 2016 02:00 PM EDT Reads: 991
Apr. 29, 2016 02:00 PM EDT Reads: 1,558