6 Things Network Performance Monitoring Can't Tell you

Years ago, I had an in-car GPS navigation system that had a traffic alert service. For a few dollars a month, you could subscribe to a service that would warn you when there was traffic ahead. More typically, it would blurt out “traffic ahead” when I was already sitting at a standstill on 101. It told you there was traffic, but not why, and never offered an alternate route. It also couldn’t traffic predict problems ahead of time. But at the time, it was a far better option than listening to sporadic traffic reports on the radio.

Network performance monitoring (NPM) has some similar challenges. It does an excellent job reporting and tracking network availability, response time, delays, and upload/download speeds. When it was initially developed, Network performance monitoring worked well in monolithic architectures on contained, well-understood and controlled data centers. 

Ten or twenty years ago, performance problems were almost always network-related. Anyone who worked in networking can tell you: it was no fun being the network administrator when things broke. Today, storage or the application itself are much more likely culprits. While once the primary tool for managing the end user experience, NPMs capabilities are diluted by increasingly complex data center architectures. NPM is often deployed at the edge, so it loses sight of what’s in the datacenter.

Network performance monitoring remains an essential tool for network and IT operations managers, but it’s no longer sufficient for modern IT infrastructure. The tools have evolved over time, and often have deep packet inspection (DPI) capability that scans and identifies application traffic, but still have gaps. Application performance management (APM) tools fill some holes, but as I wrote previously on the blog, also lack visibility into the infrastructure. I’ve worked in networking for most of my career, so I put together a list of six things NPM doesn’t give you:

 1.     Compute resource visibility. Network performance monitoring uses packet inspection as the primary basis for analyzing problems. NPM tools can’t see compute resources such as memory, CPU, or wait times for a host or virtual machines. 
2.     Storage resource visibility. Similarly, Network performance monitoring can’t see what’s happening at the storage layer. It may be able to monitor traffic to and from a storage array, but it can’t actually measure disk latency, throughput or other critical metrics at either the virtual machine or array. 
3.     Application server health visibility. NPM tools don’t have a way to talk to the application server, so they can’t tell you up/down status of the application. They also can’t see OS and process level information that can affect application performance. For example, if application response time is slow and due to an application server internal backup process that’s  consuming the majority of the CPU or memory resources. 
4.     Application transaction emulation. One way to verify problems is to emulate application transactions. Since NPM tools run passively through the switch, there’s no way for them to do this. NPM tools are passive. They analyze network packets. But what if there are no packets? You can’t tell if the server is dead, the application crashed, or something else happened. Emulating transactions at the client can identify potential problems that NPM tools can’t see.
5.     A complete view of the network. Modern networks are complex and dynamic. NPM probes can’t be deployed everywhere. And while “listeners” can see most traffic, that still leaves NPM tools blind to east-west traffic between VMs. Software Defined Networking such as VMware NSX have fully software-defined components -- a software defined firewall and router, vLAN, etc. The networking ecosystem is now moving into the virtualization layer, so in a software-defined data center, you need deep integration with the virtualization platforms. 
6.     The ability to identify root cause if it’s not the network. Even if Network performance monitoring reports a delay, it often can’t identify the underlying cause. Network performance monitoring tools are very good at detecting networking issues and can spot problems with specific applications by inspecting the packets, but what NPM usually won’t tell you is what’s causing the problem. These could be infrastructure-related problems such as memory or CPU utilization on a server, storage response time, or internal application problems such as code inefficiencies, memory leaks, failed transactions thread synchronization. Because NPM tools don’t have visibility into CPU, memory, storage, the application servers or other indicators of problems, it isn’t reliable for diagnosing problems that originate somewhere else in the infrastructure.

A lot has changed since Network performance monitoring first came to market. Network used to be the prime culprit when it comes to application performance issue.  Now storage systems and multi-tiered application complexity have taken over.  Modern data centers need to deliver application services. While the piece parts are important, what really matters is how they work together and how it impacts application performance. As Ethan Banks puts it on his PacketPushers blog post about Uila:

“If indeed the app is slow based on Uila’s presentation of your data center infrastructure’s metrics, you can find out exactly why.”

At Uila, we believe anything that impacts application performance should be managed, monitored and optimized for the environment. Network performance monitoring will diagnose a networking issue once you’ve detected a problem, but you need a much higher-level view of the data center to monitor everything effectively.

Please get in touch if you’d like to see a demo or run a complimentary trial of Uila’s solution - and fly overhead together!

# # #

Chia-Chee Kuan



Uila's CEO and co-founder, Chia-Chee Kuan, may be reached at: (408) 819-0777, or by email at: chia-chee.kuan@uila.com. Please also follow his and all of Uila's posts on social media: Twitter, LinkedIn, and Facebook.