Submit a ticketCall us

Bridging the ITSM Divide
Integrated help desk and remote support software for faster resolution

Join us on Wednesday, November 29, 2017 at 11 a.m. CT, as we discuss the benefits of effectively integrating your help desk software with remote support solutions to help increase the efficiency of IT administration, improve communication, and decrease mean time to resolution (MTTR) for IT issues of all sizes. This directly impacts end-user satisfaction and your business’ bottom line. Register Now.

Home > Success Center > Network Performance Monitor (NPM) > When to add polling engines - Video

When to add polling engines - Video

Created by Jennifer Kuvlesky, last modified by Lori Krell_ret on Jul 26, 2016

Views: 122 Votes: 1 Revisions: 4


This video (2:42) describes when to add polling engines and the options for deploying - distributed or centralized environments. 



  • Network Performance Monitor
  • Orion Core products

Video Transcription


Scalability is similar to adding “horsepower” to your Orion® deployment and come into play on larger Orion environments. Once an Orion server reaches around 10,000 elements, it is time to start looking at additional capacity.  In environments such as this, it is necessary to add additional polling engines to spread the load between multiple servers. This also allows a customer to scale up installed modules without the need for additional licenses for each module. Polling engines are machines dedicated strictly to gathering device statistics and can be deployed locally or remotely.  Since no two networks are the same, there are different architectures that cover both large and geographically disparate network deployments. 

The first architecture we will discuss is the centralized option. Each Orion instance can poll 10,000 elements without an additional polling engine.  By adding one additional polling engine, the “instance” of NPM can now handle roughly 20,000 elements, this is true for up to 100,000 total elements.  One of the main benefits of the centralized model is that as you add polling engines to scale up NPM, you are also able to increase capacity of the modules as well.  For instance, if you need additional capacity to monitor applications with Server & Application Monitor or SAM, adding a polling engine will increase the capacity of both NPM and SAM. 

The second option for scaling NPM is the distributed architecture.  This is typically done in larger, more geographically dispersed environments.  Deploying a distributed model is slightly more complex and requires additional planning, but in the end can provide a more fault tolerant, locally controlled monitoring solution.  This is accomplished by placing separate autonomous Orion servers at multiple locations and combining the monitored data into a single view with the Enterprise Operations Console.  

The Enterprise Operations Console (EOC) acts as a single pain of glass for multiple Orion instances. For example, if I have an Orion deployment in North America and another one in Europe, the EOC will show both instances including global alerts and events. Each instance is still separately maintained but rolls up information into a single unified interface. The administrator has the option to allow full local control over the monitoring environment yet maintain that enterprise-wide visibility.


Last modified