Currently polling a lot of internal servers using WMI and a couple of remote servers using the agent. So far, the agent is working great for the remote sites, but are there any performance gains for running the agent locally to collect information versus having WMI polling on a node straight from the Orion server?
From what I have read (SolarWinds Knowledge Base :: How do SNMP and WMI polling compare?), WMI takes 5 times longer to poll and likely uses up more resources on your pollers. I would expect that installing agents on your WMI nodes would reduce the polling load on your pollers, leaving them more resources to poll other things. It might also reduce the need to purchase an additional poller as you grow if your poller is just gathering data from your agents as opposed to actually performing the WMI polls itself for the Node (CPU, RAM, Disk) and any applications you define to poll via WMI (if you have SAM).
The following report also supports that WMI uses more resources on the poller than snmp: SNMP_vs_WMI_20130412.docx. This document suggests a 10% increase in CPU on the poller using WMI vs snmp against 300 nodes, 2% increase in RAM and 1.5 Kbps incoming bandwidth.
Based on this information I believe that using the agent could potentially save resources on your pollers and in the case of your pollers running low on resources, could save you from having to purchase an additional poller. Keep in mind that the Agent documentation says that a single poller only supports 1000 agents as of the initial release of the agent.
I read this as well about the maximum number of agents is 1000 per poller. Is this still the case?
If the agent is less of a use of resources what is the reason a poller can handle more WMI monitored nodes than Agent monitored nodes?
Yes, the recommended limit is 1000 agents per-poller. The reason why we recommend no more than 1000 agents per-poller is that unlike WMI, all agent communication are heavily encrypted and compressed, which can contribute to higher CPU utilization on the main poller or polling engine the agents are associated with.
Monitoring is far and away faster and more efficient locally. In most cases there is less communication overhead since there's no need to authenticate for most locally collected information. There is of course some small overhead associated with any agent, even if that agent is SNMP or WMI. The agent typically consumes under 1% CPU (0.24% on average) and between 10-100MB of RAM depending on the number and type of jobs being executed. Bandwidth consumption as rob.hock stated above, is ~80% less than that of a WMI managed node.
I've seen a definite improvement on resource usage on some of our older slower servers. There is a lot less consumption of resources by WMI. The one trade-off I've noted is that it can take a little space on the target with the install and logging created.
This is by design. All application templates by default utilize the agent unless no agent is installed; in which case agentless polling is used. This functions the same as the 64bit polling method when/if SAM is installed on a 32bit operating system. In that scenario it will automatically use 32bit polling. The option to override a template to use agentless polling when an agent is installed can be handy in the event you wanted to measure response time of user experience. You would likely get a far more accurate measurement polling from the Orion server than the Agent polling the localhost.
Thanks for the reply. So if I have say 1000 servers running a particular app monitor, and I have an agent on 10 of them, if the app template is set to use agent it will use the agent on those 10 and use (in my case) WMI for the other 990?
Hi @aLTeReGo, would you be able to share, when to use Agent based vs. Agentless polling method?
This is somewhat use case driven, and part personal preference. Some customers prefer to use Agents anywhere/everywhere possible because Agents don't require credentials with elevated permissions or specially created least privilege accounts to be created, updated, and maintained on the endpoints. Simply install the Agent and go. Agents also have store and forward capabilities, allowing them to continue polling, even when the poller they're associated with is unreachable. Once the poller is reachable again, all monitoring information collected by the Agent while the poller was inaccessible is automatically uploaded to the poller and written to the database. This helps with availability reporting and limiting any gaps in data.
Obviously, there are distinct advantages to agentless monitoring, so I'm not at all suggesting this is how agents should be used in every environment. These reasons really come down to a matter of personal preference.
There are certain use cases where the Agent is advantageous or possibly even required. For example, if monitoring nodes across high latency links (upwards of 500ms) and low bandwidth connections. Unlike protocols like WMI, the Agent communications protocol is extremely latency friendly and high compression is used to limit bandwidth to a tiny fraction of that of WMI or RPC.
Agents also run over a single TCP Port, compared to WMI which by default can use any random port greater than 1024. This, along with the ability to control directionality (push/pull) can be helpful in secure environments where access control lists, firewall policies, and even NAT present difficulties with monitoring. For example, most ISPs won't allow monitoring via WMI across the internet because it uses the RPC protocol. In these situations, an Agent may be required if a VPN tunnel isn't available. Similarly, secure environments that do not allow any listening ports to be running on the endpoint, even WMI or SNMP, the Agent allows for a 'push' method to the pollers (Agent initiated communications) whereby there is no need for any listening ports on the monitored endpoint's IP for monitoring.
So in short, it really depends on what you're wanting to accomplish, as well as how agent-friendly the environment is.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.