Our reseller Omicron AG from Switzerland has set up an installation of PRTG with 10,000 SNMP sensors for one of their customers, a multi-national company with almost 100,000 employees worldwide. For traffic monitoring, this setup consumes very little bandwidth only.
Omicron use two dedicated hardware servers running on Windows Server 2008 R2, one to host the PRTG core server and one for a PRTG remote probe. This probe runs all of the 10,000 sensors with an interval of 60 seconds. 99% of the sensors look at the traffic of switch ports of 270 SNMP enabled network switches.
After setting up all of those sensors, they were curious: How much additional traffic does PRTG actually create with this monitoring?
They did not need any additional software to find out: They simply set up PRTG's packet sniffer sensor on the remote probe machine which analyzes the network traffic on the probe system. And within minutes they could see that they are only generating 400 kbit/s of network traffic for 10,000 sensors with 1 minute interval (which is less than 3 kbit/s per switch)!
When we talk to PRTG customers who want to set up installations with several thousand sensors we always recommend to use SNMP anywhere they can, especially for bandwidth monitoring. The bandwidth-cost and CPU-cycle-cost for SNMP monitoring is—in most cases—the lowest you can get. All other bandwidth monitoring options, including WMI, NetFlow, sFlow, jFlow, and packet sniffing create either much more bandwidth usage for your network or more CPU usage on the switches and/or the probe systems.
Lesson learned: If you want to scale your monitoring, use SNMP (but avoid SNMP V3)!
