New for NPM 11.0 is the exciting Quality of Experience (QoE) dashboard. The QoE dashboard uses deep packet inspection to provide the ability to easily determine whether a performance issue stems from application server slowness, or an issue with the underlying network. The two key metrics we surface in QoE to help determine this are: Application Response Time (ART) and Network Response Time (NRT).
NRT (or TCP 3-way handshake) provides a relative metric for the quality of the network connection at a given point in time, where ART (or time to first byte) reflect how long the application server took to respond to the request. Individually the statistics are interesting, but together they allow you say fairly definitively whether an issue is a network problem, or if it's time to call the application / systems team.
So how do we collect data?
NPM 11 collects packet data via new software-based sensors, the Network Packet Analysis Sensor and Server Packet Analysis Sensor.
Out of the box, NPM comes licensed for (1) Network Packet Analysis Sensor (NPAS) and (10) Server Packet Analysis Sensors (SPAS).
Network Packet Analysis Sensors are installed on a dedicated 64-bit Windows server (physical or VM) with a dedicated interface to be attached to a SPAN / mirror / tap / etc.
NPAS's can be deployed at any layer of your network to provide visibility into response time across your network. Any aggregation point for which you would want to collect data would be a good candidate for a NPAS, from a remote access-layer switch to a core datacenter chassis. For example, by collecting access layer data, you may want to focus your monitoring of remote-site client endpoints, versus monitoring centralized servers at your core.
To deploy a sensor to a dedicated host, simply go to Settings->QoE Settings->Manage QoE Packet Analysis Sensors
From there, click Add Packet Analysis Sensor and select the dedicated host to deploy to:
Once the sensor is successfully deployed, you edit the sensor to choose the assigned interface, or add managed nodes for which the sensor will be seeing traffic:
Applications to filter for can then be added on a per-node basis via the "pencil" icon:
Server Packet Analysis Sensors (SPAS) function almost identically to NPAS, with the exception that a SPAS is designed to collect information only for the system it is installed on. For example, if you were a server administrator interested in collecting Exchange response time data, you would deploy a SPAS to each of your Exchange servers:
By default, the sensor will be limited to a single core and 1Gb of memory. It may be desirable to adjust these settings based on amount of traffic, and resources available to the system:
If the nodes are assigned to an additional poller in the environment, the sensor data will report back in through the assigned poller.
Remote Site Considerations
Your level of data granularity will vary dependent upon where the sensors are deployed. For example:
Sensors deployed in a central location - Provides aggregate data for servers in the central site
NPAS deployed to remote sites - Remote client endpoints can be added to the NPAS to provide a per-client view
SPAS deployed to remote endpoints - SPAS can be deployed to some or all remote endpoints to provide comprehensive or sampled endpoint data
The table below should help decide where to deploy:
Whichever deployment method you choose, the sensor installation process should only take a matter of minutes, and begin to immediately report data.
NPAS and SPAS can be mixed in the environment, so for example if you wanted to monitor your core datacenter switch with an NPAS, but wanted to deploy several SPAS to remote-site servers, this would be a valid configuration.
With both a dedicated NPAS and SPAS option, you have the flexibility to quickly and easily gather data in a way that best suits your environment. Licenses are included out-of-the-box with your NPM installation, so give it a try today!
For more information and deployment considerations, please check out the deployment guide.