We've got a server in our DMZ that we switched to using the agent (v 1.1.726) to monitor, instead of just snmp. Latency reported for the node is now crazily high. NPM reports that the average response time for the node is around 200-300ms. Just pinging the box, responses come back in 1ms with the occasional bump up to 2 or even (*gasp*) 3ms. Anyone know what it is about the agent that makes the response time look so bad when the actual response time for snmp and the website on this server is much much lower?
This is a known issue related specifically to passive agent mode (tracked internally under FB403838) and is slated to be addressed in a forthcoming Service Release.
Was this resolved in the subsequent service releases? I have a Client that is still seeing this issue running Orion 2015.1.0 and want to make sure it is fixed prior to upgrading.
Yes, this issue was resolved in SAM 6.2.1.
Hi there - I'm experiencing this on a SAM 6.2.1 release - however the service teams manually installed the agent, and I'm wondering if they used a previous version. What version of the agent should be expected ?
The Agent automatically updates itself from the server it's associated with, so you shouldn't need to be concerned about running an older/outdated version. It's important to note however that agent response time will always be a little higher than ICMP since it's using a different protocol and completely encrypted. It should not however be orders of magnitude different however, so if your 'ping' response time is sub-1ms and the agent is reporting 300ms, then something is definitely wrong.
If the agent is pingable from the Orion server, you can always change how status and response time information is collected via 'List Resources' as shown below.
Unfortunately no ping access, as services are located in a locked down DMZ for payment services (hence the use of agent as opposed to snmp / WMI).
Latency being reported is 180ms where it should really be a few ms as in the same DC as the poller. I'm guessing further investigations needed - struggling to find any reference docs to assist with troubleshooting, so I'll get the service teams to raise a support ticket.
Many thanks for the prompt response however !
A customer had similar issues with their agents (400+ agents being polled in 400 remote sites). Also an issue if the agent service crashed, it reported a lot of nodes as being down. The workaround was to swap all of the agent polled nodes to ICMP polling for status and response time. Even if the agent failed, the device would still report as being up. Still investigating how to alert when the agent fails.
Agents have their own status separate from Node status, since not all agents are nodes. Below is an example of some of the alerting properties for the agent.
Cheers aLTeReGo. The issue we're working through support with is the agent says status Running but no data is being collected (CPU/memory/applications/etc).
Thanks aLTeReGo for the reminder. Since ours are agent initiated the bulk of them all appear as up/avail although the actual application status is unknown.
I've set the report up this was to be able to see who falls out - hopefully this will work in the meantime correctly.
Is there a way to do this same change in Bulk, lets say we deployed agent more than 100 servers and we want Status & Response time to be monitored using ICMP instead of agent how do we do for all 100+ servers.
Going to each node doing list resources and selecting ICMP would be very tedious task.
Go to [Settings -> All Settings -> Manage Pollers] Select 'Status & Response Time ICMP' from the list and click 'Assign'.
Choose the nodes you want to enable ICMP Status Polling for and click 'Enable Poller'.