This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

SNMP vs WMI polling - pros and cons

I'm pulling together a (semi-comprehensive) comparison of the impact of monitoring via WMI versus SNMP.

The upshot for those who are impatient: WMI monitoring (whether WMI polling or WMI via SAM) has a measurable - but manageable - impact on both the target device and the poller.

That said, if you are considering converting your monitoring of Windows devices from SNMP to WMI, what are you gaining? What are you losing?

Here's the start of my list. Please add your own in the comments below. Note that this is an off-the-top-of-my-head list. Coherency comes later.

SNMP Monitoring (as compared to WMI)

  • CON Cannot monitor Windows Volume Mount points
  • CON Challenges configuring earlier versions of Windows (NT, W2k)
  • CON Requires additional non-default configuration actions (enabling snmp agent, setting RO string, etc)
  • PRO Fewer ports for enterprise firewall rules (translates to an easier time getting security to agree to variances)
  • PRO No single point of failure for access
  • CON Changing SNMP string requires enterprise-wide changes
  • CON Uses SNMP service start time for uptime metrics, rather than actual server reboot time
    • Work-around: set up UnDP for hrSystemUptime
  • PRO Extremely efficient use of CPU, RAM and bandwidth (on both target and poller)

WMI Monitoring (as compared to SNMP)

  • CON WMI-only devices cannot use custom pollers (UnDP).
    • Work-around: If the machine has EVER been an SNMP polled device, the snmp info is retained and custom pollers can be used (at least until the SNMP RO string changes)
  • PRO Account settings used by SAM automatically
  • CON significantly more firewall ports required
    • Work around: per-server config can nail down WMI to just a couple of ports
  • CON will not work across a NAT-ed WAN connection (VPN, etc)
  • CON one password change in AD can cripple monitoring
  • CON cannot monitor topology
  • PRO doesn't try to monitor RAM as a volume (why does NPM do that, anyway?!?)
  • PRO uses REAL reboot time for uptime metrics
  • CON less efficient (vis a vis SNMP) use of CPU, RAM and bandwidth on both target and poller

OK guys, there's the start of my list. What did I miss?

  • This is very timely for us.  We are actually putting together this discussion now with Server 2012 stating it will have degraded SNMP and I can only assume after 2012 it will only get worse.

    We are really having to dot our i's and cross our t's, because as I have stated in previous posts, our Data Security is run like the TSA and their concept of security is if you tell everyone "no" you have secured the environment.

  • WMI is much slower than SNMP.  With Server 2012 WMI is even slower than it used to be.  I generally always use SNMP when possible and use WMI as my 2nd option when necessary because of the speed.  Also, WMI tends to be more "buggy", I have never really had problems with SNMP as it's much more reliable.

    Nice list though, I look to what others have to say!

  • I concur with I prefer SNMP.  Now that being said I will make some nodes WMI based when I upgrade to 5.5 because of the ability to poll mount points.  It's really a shame however that there can't be a blended approach.  I mean it's completely possible to build a SAM poller for a WMI query on an SNMP node but if the node is WMI based it's not possible to do any SNMP monitoring unless like the other user said it used to be SNMP at one point.

  • This is something I ran into a while back in regards to WMI having an issue.  WMI utilizes reverse lookup for confirmation so an invalid reverse lookup can cause WMI to fail.

    http://thwack.solarwinds.com/message/161528#161528

  • I prefer SNMP and also wouldn't like to lose all of my historical data by converting a node from SNMP to WMI or vice versa.  Since most all of my nodes were setup via SNMP I will stay the course barring any tremendous WMI improvement gains that would peak my interest again.

  • Totally agree....  SNMP is faster and when you have 15,000 elements its much nicer to the CPU and polling intervals.

    We use WMI for our almost 700 applications and if there are alot of components it can sometimes timeout.

    I say use SNMP for basic monitoring and WMI for the detailed items like applications....


  • As a DoD admin SNMPv2 is now prohibited from being used.  We are being forced to use WMI to poll all our Windows servers.  Interface statistics are available via WMI directly.  Why can't NPM pull interface statistics using WMI?  Any hope for the capability to be added in the future?

  • From what I've seen, WMI *does* pull interface stats. However, I have both NPM and SAM and it's possible some of what I'm seeing is coming from SAM rather than native NPM.

  • Another PRO for WMI is that it grabs the "Avg. Disk sec/Transfer", "Disk queue length", "Total Disk IOPS", and "Disk Allocation Failures" for volumes - never seen anything in "Disk Allocation Failures", but that a good thing right?

    I am not sure what version added that, but I was messing around with adding the new graphs and saw them and played around till I found that they had data if the server was WMI.

  • I’d like to see the option to use both SNMP and WMI methods.

    I monitor using SNMP across the board, but I want some of the options that WMI monitoring offers such as an account associated with the node (for service control via Solarwinds etc.)  and Disk Performance stats without needing to install “SNMP Informant Standard” on all my servers, or add  additional monitors manually.

    I’m not saying that the same info should be gathered by both methods. I’m sure that the bods at Solarwinds know which data is best pulled from SNMP and which from WMI? If not, they could give the admin the choice of setting one as the primary method.