Forum Discussion

Javier's avatar
Javier
Icon for Neophyte rankNeophyte
10 months ago
Solved

"Virtual" device monitoring

I am preparing a set of datasources to monitor several aspects of a cloud provided service.

I can connect to that service using an URL and specific port, but cannot ping this service as it is blocked.

When defining a new device for this, I assigned the “NoPing”, “NoHTTP”, “NoHTTPs” system categories but I still get the dead device icon. My datasources alerts are not generated because of this dead status.

It looks like the device address is checked using ping anyway and is marked as dead.

Is there anyway to avoid this behaviour?

  • To pile on, host status is determined by the presence of any response to particular datasources. Any datasource that has to return a response from the device itself indicates that the device is up will prevent the device from being marked “dead”.. So ping, http, https, any of the SNMP datasources, etc. will work to keep the device from being “dead”. 

    I was going to look up the code Mike posted, but he beat me to it, haha. Although, it sort of cheats by essentially hard coding the device to be considered up. That snippet of code was designed to allow a scripted datasource to return data that causes the device to not appear dead. It’s original use was to only return that if the script ran successfully.

    Instead of just having the liveHostSet.flag method just run, I would suggest you tie that to some sort of conditional logic so that it only runs if the script knows the device is actually up.

    For example, if you were using the script to check a controller that the device is up, the device itself isn’t actually giving a response. LM can’t (and shouldn’t) just trust that the device is up just because LM can talk to the controller. It should use the response from the controller to determine if the device is up and only then run the liveHostSet.flag method.

2 Replies

  • Yeah, so LM does not include DataSources that use script or batchscript in the host status calculation. So you need something else like ping, http, wmi, snmp, etc to make it count. But there is a code snippet you can use that will tell the collector that the device is live:

    import com.santaba.agent.live.LiveHostSet

    // Update the liveHostSet to tell the collector we are happy (updates Host Status)
    hostId = hostProps.get("system.deviceId").toInteger()
    liveHostSet = LiveHostSet.getInstance()
    liveHostSet.flag(hostId)

    I found this code in some other datasources that LM has created, so I’m not sure how official it is. I did find that this only seems to work when used within a multi-instance datasource (likely due to getInstance).

  • To pile on, host status is determined by the presence of any response to particular datasources. Any datasource that has to return a response from the device itself indicates that the device is up will prevent the device from being marked “dead”.. So ping, http, https, any of the SNMP datasources, etc. will work to keep the device from being “dead”. 

    I was going to look up the code Mike posted, but he beat me to it, haha. Although, it sort of cheats by essentially hard coding the device to be considered up. That snippet of code was designed to allow a scripted datasource to return data that causes the device to not appear dead. It’s original use was to only return that if the script ran successfully.

    Instead of just having the liveHostSet.flag method just run, I would suggest you tie that to some sort of conditional logic so that it only runs if the script knows the device is actually up.

    For example, if you were using the script to check a controller that the device is up, the device itself isn’t actually giving a response. LM can’t (and shouldn’t) just trust that the device is up just because LM can talk to the controller. It should use the response from the controller to determine if the device is up and only then run the liveHostSet.flag method.