Agent - high latency

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.

aLTeReGo,

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.

Best Regards,

Derik Pfeffer

Loop1 Systems: SolarWinds Training and Professional Services

• LinkedIN: Loop1 Systems
• Facebook: Loop1 Systems
• Twitter: @Loop1Systems

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.