Version 1

    NOTE: The spreadsheet with the data behind this information appears as a separate upload. See here: SNMP_vs_WMI_20130410.xlsx


    SolarWinds’ (relatively) new technique of monitoring windows servers via WMI instead of SNMP represents a measurable - but manageable – impact on both the target and the polling engine.


    On a target server, monitoring with WMI + a SAM template had no effect whatsoever on RAM or CPU (compared to simple ping monitoring) although it did represent an average increase of 12Kbps.


    The difference between WMI and SNMP polling was even less noticeable, with a 4Kbps bandwidth bump being the only noticeable effect.


    On the polling engine the impact was more pronounced: monitoring 300 servers via WMI with a SAM template included (the most aggressive monitoring combination) resulted in the following increases compared to monitoring with simple “ping”:

    • a 16% increase in average CPU utilization
    • a 4% increase in average RAM usage
    • and a 4Mbps increase in incoming bandwidth.


    The difference between monitoring 300 machines with WMI vs. SNMP was even less of an impact on average:

    • 6% CPU
    • 2% RAM
    • 2.5Mbps bandwidth received.


    If (as the executive summary states), the difference between WMI and SNMP polling is (statistically) negligible, then why the need for additional hand-wringing? Why not just make the switch and go?


    The answer is that the choice of polling method has other impacts beyond the physical toll on the machines involved. Functionally, there are some pros and cons to be weighed:


    SNMP polling (as compared to WMI)

    • CON Cannot monitor Windows Volume Mount points
    • CON Challenges with earlier versions of Windows (NT, W2k)
    • CON Requires additional non-standard configuration actions (enabling snmp agent, etc)
    • PRO Fewer ports for enterprise firewall rules
    • 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
    • Work-around: set up UnDP for hrSystemUptime
    • PRO Extremely efficient use of CPU, RAM and bandwidth (on both target and poller)


    WMI polling (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 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 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