Submit a ticketCall us

Looking to compare latest NPM features with previous versions of NPM?
The NPM new feature summary offers a comparison of new features and improvements offered with this release.

 

Home > Success Center > Network Performance Monitor (NPM) > SNMP vs WMI polling

SNMP vs WMI polling

Created by John Salvani, last modified by MindTouch on Jun 23, 2016

Views: 585 Votes: 6 Revisions: 5

Overview

 

A relatively new technique for 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 plus a SAM template has no effect whatsoever on RAM or CPU, compared to simple ping monitoring. However, it represents an average increase of 12 Kbps.

 

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

 

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

  • 6% increase in average CPU utilization
  • 4% increase in average RAM usage
  • 4 Mbps increase in incoming bandwidth

 

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

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

 

If 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?

 

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

Environment

NPM 11.5 and earlier

Detail

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:

SNMP polling (as compared to WMI)

Pros:

  • Fewer ports for enterprise firewall rules
  • No single point of failure for access
  • Extremely efficient use of CPU, RAM and bandwidth (on both target and poller)

Cons:

  • Cannot monitor Windows Volume Mount points
  • Challenges with earlier versions of Windows (NT, W2k)
  • Requires additional non-standard configuration actions (enabling SNMP agent, etc)
  • Changing SNMP string requires enterprise-wide changes
  • Uses SNMP service start time for uptime metrics
    Work-around: set up UnDP for hrSystemUptime

WMI polling (as compared to SNMP)

Pros:

  • Settings used by SAM automatically
  • Uses REAL reboot time for uptime metrics

Cons:

  • 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)
  • Significantly more firewall ports required
    Work around: per-server config can nail down WMI to just a couple of ports
  • Will not work across a NAT-ed WAN connection (VPN, etc)
  • One password change in AD can cripple monitoring
  • Cannot monitor topology
  • Less efficient (vis a vis SNMP) use of CPU, RAM and bandwidth on both target and poller
Last modified
23:35, 22 Jun 2016

Tags

Classifications

Public