Forum Discussion

therealsle's avatar
11 months ago

How does Host Status idleInterval treat Ping Multi instances

@LogicMonitor Team:

By reverse engineering I discovered the following behavior:

  • If a Ping Multi instance ip address is also listed in the device property system.ips, the ICMP replies are also considered for Host Status idleInterval
  • If a Ping Multi instance ip address is not listed in the device property system.ips, the ICMP replies are not considered for Host Status idleInterval

It basically means that the Host Status may show a host unreachable even if a Ping Multi instance is still responding.

This behavior was also confirmed by a support engineer (by reverse engineering). 

Can you confirm this observed behavior? Please update the online documentation accordingly, since it already contains a note for scripted DataSources, but not for Ping Multi.

  • This sounds like expected behavior to me. In general, we avoid resetting host status idleInterval unless we can be fairly certain the data is coming from the device indicated by that resource.

    This is why script modules are ignored for idleInterval reset; we don’t know if that data is coming from the targeted resource, or some other resource. For built-in ping collector, we can be pretty sure.

    If you’ve got Resource A and it has an applied Ping_Multi DS with an instance representing Resource B, our assumption is that Resource B data shouldn’t be relevant for Resource A’s idleInterval (and thus Host Status). This gets complicated with private IP ranges, but the situation laid out here sounds like what I would expect.

  • Anonymous's avatar
    Anonymous

    Yeah, it’s working as designed. However, the ask is that the ping multi check the system.ips property to see if it matches “resource B”’s IP. If it does, you can be assured that the device it pinging itself from the current IP to one of it’s other IP addresses. This means that Resource B is Resource A and a response from it could be used to reset the idle interval.

  • This sounds like expected behavior to me. In general, we avoid resetting host status idleInterval unless we can be fairly certain the data is coming from the device indicated by that resource.

    This is why script modules are ignored for idleInterval reset; we don’t know if that data is coming from the targeted resource, or some other resource. For built-in ping collector, we can be pretty sure.

    If you’ve got Resource A and it has an applied Ping_Multi DS with an instance representing Resource B, our assumption is that Resource B data shouldn’t be relevant for Resource A’s idleInterval (and thus Host Status). This gets complicated with private IP ranges, but the situation laid out here sounds like what I would expect.

  • Anonymous's avatar
    Anonymous

    The people who need to know about this don’t regularly participate in the community. I’d bring this up with support so the proper back end ticket can be opened.