Search the Community
Showing results for tags 'ping'.
Found 4 results
We are a network MSP. We have several customers with a large number of ping only devices. LMs terms don't charge per device for ping only. However, there's a caveat to that. The ping function for a device must be nested under another device such as a Collector. Apparently the billing system doesn't have the ability to distinguish between an SNMP/WMI device and a ping only device. The problem with nesting under another device is that ping device is hidden several layers down making it difficult for a customer to find them. These ping only devices don't work well with the NOC widget. I wound up having to create a second NOC widget for just ping only devices to get visibility. What I'm proposing is the LM modify their billing device detection such that Ping only devices are input just like any other device and that the billing system scans device to determine if it's Ping only or not
Where there is only one checkpoint defined for a web service check, in particular for internal web service checks, please make it so that an overall failure alert also includes the ping and traceroute info in the tooltip, see attached. Currently this tool tip info is only available for individual checkpoint alerts. If there is only one checkpoint location, then the ping and traceroute info should be included in the overall alert too. This would be very useful in reducing alerts. At the moment where I have one checkpoint (because that is all that is needed) I have to generate two alerts for the same incident, one with the useful ping and traceroute and the overall one (which is redundant in a single checkpoint scenario).
Currently, LM has hard-coded the Ping dataSource to use 250ms ICMP Ping intervals. We need the flexibility to adjust the Ping interval (ms) in the DataSource (Either static or system property value). Background: We've seen at least one company "Mimosa" that has changed it's newest firmware to block ICMP messages if they are sent "too quickly". For Mimosa wireless gear, this is represented in LM as an 80% packetloss (2 pings permitted, 8 are then rejected). Mimosa does not want their hardware resources depleted by multiple, quick, Ping requests. The workaround currently is to alter the thresholds in LM to compensate for an 80% packetloss reading. By having the ability to adjust Ping Interval for these hosts in LM, we can have better visibility into network issues.
Jonny Murray posted a topic in Feature RequestsHi, I was wondering if a feature could be created that would allow me to monitor Response Time/Latency of multiple ping services that I have set up. At this moment in time, I can monitor one customer per widget; I would like to monitor more customers on the same widget showing the same datapoints. For example, in the uploaded image, this is showing the response time of an IP address from all of the checkpoints (Washington, Dublin etc). I would like to monitor the response time of all the customers I have, rather than checking multiple widgets. At the moment, there is a widget called "Service Status" which lets you monitor the overall status of services. I would like the same thing to be done but only for the ping service; so that on one widget I can see the latency of each customers IP address from Dublin. (excluding the others - added ability of choosing which checkpoint to use) Hope this makes sense; if not, I am an email away.