You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem
In our current tool (Cacti) for trending SNMP metric data every device has a connectivity check that also stores the latency between the system and the polled device.
I'm currently missing that functionality SC4SNMP.
Latency is an important metric for us, but also a good first indicator that if no connectivity exists then thats the reason for failing SNMP polls.
It's also easier in Splunk to raise an alert for a event that fails with a message than a search that evaluates if data is missing.
Wanted feature
Be able to poll host using either PING or SNMP connect and store the latency to Splunk
Perhaps this could also be used to prime the poller - i.e Do not attempt a poll/walk if connectivity test fails.
The text was updated successfully, but these errors were encountered:
How would you calculate latency based on UDP?
Currently I get 9 hits on Splunkbase if I search for PING - perhaps one of them would suit your need.
Also realise that PING is a totally different protocol (ICMP) and actually only tells you that power is on the NIC. It says nothing about the services behind. If you need a check on that, I'd suggest doing synthetic checks every X seconds/minutes.
Problem
In our current tool (Cacti) for trending SNMP metric data every device has a connectivity check that also stores the latency between the system and the polled device.
I'm currently missing that functionality SC4SNMP.
Latency is an important metric for us, but also a good first indicator that if no connectivity exists then thats the reason for failing SNMP polls.
It's also easier in Splunk to raise an alert for a event that fails with a message than a search that evaluates if data is missing.
Wanted feature
Be able to poll host using either PING or SNMP connect and store the latency to Splunk
Perhaps this could also be used to prime the poller - i.e Do not attempt a poll/walk if connectivity test fails.
The text was updated successfully, but these errors were encountered: