Forum Discussion

DX11's avatar
5 years ago

PingMulti Datasource customization

Hello,

I recently setup some monitoring using the PingMulti datasource after researching online and its working good. I would like to customize aspects like ping intervals between each ping & number of pings sent. I'm unable to see this in the GUI. By default, it looks like 10 pings are sent at every 1 minute interval. Please advise

Regards
DX11

  • You can change the frequency of the ping check by modifying the Collect Every field for the PingMulti- DataSource, if you want to change it globally.

    I don't believe you can change the number of pings without switching to scripts. I believe it's hardcoded to send 10 pings (unless it's in some collector config somewhere). You would want to send multiple pings like that though so you get a more precise packet loss datapoint though.

  • You can change the frequency of the ping check by modifying the Collect Every field for the PingMulti- DataSource, if you want to change it globally.

    I don't believe you can change the number of pings without switching to scripts. I believe it's hardcoded to send 10 pings (unless it's in some collector config somewhere). You would want to send multiple pings like that though so you get a more precise packet loss datapoint though.

  • Hi All - Old thread that I am picking up on.

    Has anybody attempted to find a custom way to achieve the above? I am looking at using ping multi to send 60 packets per minute and then measure and express availability, latency and loss this through an SLA widget to my client. Currently, 10 pings is just not sensitive enough and will report 10% packet loss when 1 packet it lost.

    Using internal web pings does support changing this to 50 packets (which is good enough) but a) requires a license and b) does not have proper support in the SLA widget as it combines all websites in a group into a single SLA and and only reports on availability.


    Regards,

    Kris

  • I assume you would need to write a DataSource script to implement that. Also I think reports can break out SLA per site but perhaps not dashboard widgets or perhaps create separate widget per site?

    Keep in mind that your pings would likely not fully spread out smooth over the 60 seconds. For example I assume that website checks might send 50 packets but all at once. So 50 packets in a couple of seconds then ~1min wait, then another 50 packets then ~1min wait, etc and not a smooth 1 packet per second. Even if the DataSource was written to send 1 packet per second and run for 1 minute, LM runs with a queuing system so it might be delays between runs. But that might be ok if you are looking for better SLA numbers.

     

  • Ping multi does everything I need except for the packet limitation to 10.

    Website SLA is in reporting or dashboard is insufficient as it only measures availability and does not cover loss, latency even-though those are measured in the raw data.

    Good point on the frequency, but I will be happy with 50 packets per minute, regardless of frequency.

    Looks like a new datasource/script is required here. Its a pity we can't copy/modify the ping multi one.

  • Anonymous's avatar
    Anonymous
    On 12/22/2021 at 8:56 AM, Kris said:

    Looks like a new datasource/script is required here

    Yep. 

    Curious why not exploring the idea of IPSLA?

  • Are you referring to setting up IP SLA responders on the routers and then monitoring the output via SNMP?

    If so, I looked at this some time ago but I recall the raw data returned had some issues. I think data came back in microseconds or something. Maybe time to relook at this again.

    Are you using this effectively?

    Regards,

    Kris

  • Anonymous's avatar
    Anonymous

    Yes. I've used IPSLA on and off over the last 15 years mostly with success. The failures we had resulted from trying to manually deploy vs using a deployment wizard. Otherwise, the difficulties we had came from management trying to use only IPSLA to verify path availability, which it doesn't do a very good job of because network path diversity.