Showing results for 
Search instead for 
Did you mean: 

NPM 11 - Packet Analysis Sensor Deployment Considerations

Level 17


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.

7-15-2014 3-53-55 PM.png7-16-2014 1-43-18 PM.png

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.

For example:

7-15-2014 4-14-13 PM.png

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:

7-15-2014 4-19-58 PM.png

7-15-2014 4-29-24 PM.png

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:

7-15-2014 4-37-31 PM.png

Applications to filter for can then be added on a per-node basis via the "pencil" icon:

7-15-2014 4-44-02 PM.png


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:

7-15-2014 5-51-28 PM.png

7-15-2014 5-50-34 PM.png

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:

7-15-2014 5-57-07 PM.png

7-15-2014 5-54-53 PM.png

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:

8-20-2014 6-25-54 PM.png


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.

Level 7

This look to be a very great addition to the product !

Can you contrast the use of this approach versus say a Netflow based one ?  Where one would use one versus the other.  Benefits of each ?

Level 11

is there a release date yet?

Level 11

This is looking great, hoping to have an NPAS up and running early next week, do you get any extra NPAS & SPAS licenses with additional pollers? I take it pricing for both will be coming on the release of the GA for 11.0?

Level 15

jeremydr wrote:

is there a release date yet?

We can't give out release dates, but the fact that it's in RC3 should be a good indication of when you should expect to see GA bits.

Level 15

jmiddleton wrote:

This is looking great, hoping to have an NPAS up and running early next week, do you get any extra NPAS & SPAS licenses with additional pollers? I take it pricing for both will be coming on the release of the GA for 11.0?

You don't get extra sensors with Additional Polling Engines, but you can purchase packs of Server & Network Sensors.  I can provide you pricing if you want to DM me.

Level 11

Thanks for the info.

Pricing would be great, however I can't seem to dm you as we are not connected. Friend request has been sent.


Level 11

Likewise - I'm really looking forward to this feature.

Level 9

The basic difference is that Netflow (NTA) stores all inbound/outbound flows on the network (much larger / more intense data storage) for analyzing all traffic at the network level while QoE Packet Analysis Sensors grabs data only for very specific packet types that you want to keep tabs on and stores an aggregate total of key metrics (much easier on the database but you must tell it exactly which type of packets to monitor).

Level 8

Hi all,

What are the thoughts on putting the network sensor for QOE onto an additional poller machine with a spare NIC card?


Level 17

Provided the system has sufficient CPU / memory resources to handle the additional load, there would not be a technical restriction.

Level 9

I have to buy and install a copy of Windows for each of the 11 switches I want to take SPAN data from? HELLO???

Can you say Linux?

Level 9

Adding jkuvlesk​ to see if we can get the correct link.

Man, I tagged everyone UX and I forgot I meant to tag jkuvlesk​ in the first place major whoops. lol.

Level 14
About the Author
Former SolarWinds IT Former SolarWinds PM Current Director of PM @ Vyopta