Additional polling engines, how do we love thee? Let me count the ways.
When you have a multi-product environment (NPM, SAM, NTA) buying an additional polling engine can be an excellent financial proposition as opposed to spinning up another Orion server for module and a SQL DB. However, if you stretch that polling engine across a high-latency link (which is >200ms as per Solarwinds documentation) suddenly writing data from that polling engine to database is not feasible and you are forced into a new NPM/SAM/NTA instance and SQL DB plus, if you are using the web UI for alert response, monitoring, etc. then you also need an Enterprise Operations Console to roll up your entire environment into a single pane of glass.
I suggest that additional pollers have an option to write either directly to the DB (where the latency is low enough) or forward collected data to another collector (perhaps using MSMQ or another asynchronous queuing technology) to help manage the latency impact.
Yes, I know that there are some challenges with timely alerts if data streams into a DB at a delayed rate. Perhaps alert processing could be outsourced to pollers on high latency links or some other fancy processing. Just throwing the idea out there.
Whatcha think?
