13 Replies Latest reply on Mar 26, 2018 4:20 PM by David Smith

    Set default polling engine?

      We currently have NPM 10.2.2 with an additional polling engine (and NTA 3.9, and NCM 7).


      The Orion web interface isn't exactly a speed demon as it is, so I want to offload as much of the polling burden as possible onto the secondary polling engine.  I guess I'm doing it backwards, but it makes more sense to me. When the secondary polling engine starts to reach near its capacity, I will start to bleed over onto the primary polling engine, that way the majority of the polling is offloaded to the other engine and not bogging down the Orion web interface.


      When nodes are added either manually or through a discovery, the main NPM server always shows up as the default polling engine.  I can choose the second polling engine when I add nodes or in discoveries, but I'm curious if there is a way to have NPM default to using the second polling engine?


      ** related feature request:  How about some kind of automated management/load balancing across polling engines, perhaps with an automated failover in the case that an engine fails?  The Orion Failover Engine is not exactly the same thing.  I'm talking about more of a cluster-style resource management.  Orion should be aware of its additional nodes, and can monitor the load on those nodes and adjust polling tasks across the nodes dynamically to give the best system utilization, efficiency, and ease of management (no longer having to manually do the polling engine load balancing dance).  This also relates to NTA.  As it is right now, if I have to move nodes to a different polling engine for performance or other reasons, I have to now spend a lot of time going into all of the devices that were moved and reconfigure them to send their sFlow/NetFlow to the other polling engine -- MANUALLY.  Yes, I can use NCM and do batch changes, scripts, etc., but it's still a tedious process and is prone to error (did I forget a switch or group of switches?  Did I accidentally send the changes to the wrong switches?).  Why not let NTA accept traffic on any/all polling engines for ANY managed nodes, not just nodes on THAT polling engine?  It all writes to the same database anyway.  I realize there would be an issue with duplicate records, but I'm sure the clever minds at SW can solve that without too much trouble.  Another possibility would be a virtual collector IP that the nodes can share, that would solve duplicate report packets.