In today’s digital world, businesses expect their network infrastructure to deliver consistent service, reliable access, and complete protection. This helps ensure that they can deliver the best user experiences to their customers who expect high performance delivery. The network serves as the technology highway within this hyper-connected digital era. When users are impacted by a slow application, often the common perception is that the network is the source of performance problems. Having detailed visibility and control over network conditions and components can help remove the network from probable cause whenever application slowdowns, access restrictions, and threat conditions arise.
Not all application performance issues are network related. But when investigating an application outage, it’s good to know the network is not part of the problem. Similarly, not all network issues cause problems with application delivery. In that case, the network could be resilient and have enough redundancy to withstand the failure of a single router. Determining probable cause of a slowdown, can be a challenging task in large enterprise networks. How do we get to the root cause faster?
Traditional Methods for Application Monitoring – APM, Synthetic Monitoring and Probes
One approach is to check for application server issues first. An application performance monitoring solution, or APM tool like IBM Instana would alert you to issues with the application’s software stack or hardware, for example capacity overruns or software/hardware failures. However, these tools provide limited visibility into network performance. Also, not all IT environments have an APM but may still have a custom application monitoring tool. Note that used together the NPM and APM had the added advantage of providing full stack observability.
For SaaS applications delivered from the Internet there are tools that can detect outages in the SaaS service like Webex or Gmail. Synthetic monitoring is another option that requires special probes and beacons that simulate end user sessions collecting detailed metrics on UX, atency as well as path information and can provide additional insights into connectivity degradations in the Internet.
An alternative approach is a network probe solution that does packet capture and analysis. This will provide latency (RTT), loss, jitter of the application packets, breaking the latency into network delay and application delay on per session basis. Quite impressive but often expensive and intrusive. Cisco AVC and SDWAN device vendor implementations report these application metrics in Netflow records.
SevOne NPM: Searching for the culprit causing network degradations
Let’s look at an example. Consider a scenario where IT Operations observes issues in their network (congestion, latency, device issues). Which applications are impacted? Today, IBM SevOne NPM can provide insights allowing users to quickly pivot from a Performance Metric (PM) report to a Netflow (Flow) report for an overutilized link using a quick single click chaining workflow. For example, when observing bandwidth congestion or degradation in device performance at a branch office. The PM to Flow pivot helps quickly identify applications and end users consuming the most bandwidth. This is a popular and valuable workflow that speeds up troubleshooting and helps NetOps identify the root cause and remediate faster. IBM SevOne NPM leads the competition in this area because it collects large amounts of data both SNMP metric and flow then glues them together neatly for the user in one UI.
Metric to Flow Workflow
Let’s look at another scenario. User are complaining about application performance, poor quality or service timeouts, with Zoom conferencing or a custom enterprise application. Is there an issue with the application servers that reside in the data center or underlying network connectivity? How can we rule out the network? If it is a network issue, which part of the network is the culprit? It would help if we knew which network devices and interfaces are running the Zoom traffic. Are there underlying network devices experiencing performance issues like high CPU or interface drops or congestion that may be impacting application delivery resulting in poor end-user experience.
What if we could reverse the PM to Flow workflow? Let’s start with the application instead and explore the underlying network links. That workflow would help us here.
New in v6.6! Understanding the Impact of the Network on Apps – Flow to Metric Workflow
Netflow reporting enriched with SaaS application signatures answers the question, ‘What is happening on my network’ and allows you to start network analysis with the application. All you need is the application signature defined by IP, port, protocol and TOS to identify the application and perform drill-down exploration of the data. SevOne NPM automatically identifies applications for you with built-in database of SaaS and standard port based applications. This feature was introduced in NPM v6.6 visit this blog post by my colleague Rupert Gregory to learn more.
Application Centric reports with SaaS applications, ASN and Country enrichment
In NPM v6.6 we also introduced single click Flow to Metric workflow which includes chaining and report links to allow user to quickly pivot between Netflow and SNMP metrics to gain insights into the performance of the devices and interfaces carrying a specific application. Users can quickly identify network links carrying specific applications and easily gain insights into network impact on applications using this new workflow.
New - Flow to Metric Workflow