Quantcast
Channel: THWACK: All Content - Network Performance Monitor
Viewing all articles
Browse latest Browse all 21870

SNMP vs WMI polling - pros and cons

$
0
0

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?


Viewing all articles
Browse latest Browse all 21870

Trending Articles