Dependencies or Parent/Child Relationships

Agree - this has taken way too long to get into the product officially. (It is in the works, but as Mike said, is at least 6 months away. We're working on improving our processes and efficiencies, too...)

In the interim, these two datasources available from the registry with these locators can achieve dependencies on a device level.  Feedback appreciated!

SDT_Dependent_Devices: locator 24KKNG

SDT_Assign_Primary_For_Dependencies: locator NFTHXG

Creating Device Dependencies 

With these two datasources, LogicMonitor supports device dependencies in order to help reduce alert noise.

Dependent devices have a primary device. When the primary device reports a specific kind of alert (by default, a ping alert, but this is configurable), then the dependent devices are placed in scheduled downtime. This means that if the dependent devices report alerts, they will not be escalated.

Dependent devices will be placed in Scheduled Downtime for 30 minutes at a time. If the primary device is still in alert, the Scheduled Downtime will be refreshed for another 30 minutes, before the existing Scheduled Downtime period expires. Note: when the alerts clear on the primary device, the dependent devices will remain in Scheduled Downtime for the remainder of the existing 30 minute period - this is to allow circuits to re-establish, and alerts to clear, etc. 

 Configuring Device Dependencies

Ensure your account has the SDT_Dependent_Devices and SDT_Assign_Primary_For_Dependencies datasources. Import them from the registry using the above locators if necessary.

You will need a LogicMonitor API token for a user that has rights to manage the primary and dependent devices. Create two properties on the root level of your LogicMonitor account: logicmonitor.access.id and logicmonitor.access.key, and set their values to the API token’s ID and Key, respectively.

To create a dependency on device A, so that devices B and C will be automatically placed in scheduled downtime when device A is in alert:

Navigate to device A, and determine the device’s displayname as entered in LogicMonitor. Note: this is not the IP/DNS  name, but the value of the  name field when managing the device.

e.g. in the below screen shot, the relevant name is ESXi1 - Dell iDRAC8

Now simply navigate to devices B and C in LogicMonitor, and add the property depends_on to each device, and set it to the value of the displayName of device A.

That’s it.

Within 30 minutes of the first device set to have device A as a primary device, LogicMonitor will configure itself so that if device A has an alert on the ping datasource, it will place all dependent devices into scheduled downtime for 30 minutes, as described above. (Note: You can cause the reconfiguration to happen immediately if you run Poll Now for the SDT_Assign_Primary_For_Dependencies datasource on one of the dependent devices.)

Once the primary device is in an alert that matches the alert conditions (any Ping alert, by default), it will SDT the dependent devices. You will see a property created on the primary device: dependents_sdtd  - that contains a list of the devices that were most recently placed in SDT by the dependency action. There will also be another property, dependents_sdt_until that contains the epoch time in which the last set SDT will expire. If the alert condition still exists 5 minutes before the expiration of the SDT, a new SDT will be created.

Note that devices that are primary for one set of devices can themselves be dependent on other devices. ( e.g. a remote server can be dependent on a brach office router, but that router may be dependent on a VPN router.)

If a dependent device has a depends_on property that is set to a device that does not exist, a warning alert will be raised on that dependent device. (Similarly, there will be warning if the authentication credentials are not set correctly.)

Optional - changing the alert conditions for the primary device to trigger dependencies

By default, primary devices will trigger SDT for dependent devices if the primary device is in any ping alert (either packet loss or latency) of any level. You can change the conditions that trigger the dependency action by setting the property primaryalert on the primary device.
This property can be set to any valid filter supported by the LogicMonitor REST API call that returns alerts for a device.
The property is appended to the API query filter=resourceTemplateName:
Thus the simple case is to simply set the property primaryalert to another datasource's Displayed As field (not name), to act on alerts about that datasource.

For details of alert fields that can be used in filtering, see https://www.logicmonitor.com/support/rest-api-developers-guide/alerts/about-the-alerts-resource/

Removing Dependencies

The dependency configuration will be automatically removed once there are no devices that have the depends_on property pointing at a primary device - but not until the primary device alerts next. (You can manually remove the properties is_primary_device, dependents_sdt_until and dependents_sdtd to immediately remove the dependency datasource).

Feedback appreciated.

This will surely help a lot of customers, thank you for that.   You cannot add this at the moment - the import throws an error - any idea when it will be available (or similar functionality)?

503 : This LogicModule is currently undergoing security review. It will be available for import only after our engineers have validated the scripted elements.

Huh - thought I put that through the review already... Let me fix that today..

Fixed -these are now importable.

(Note that the locators changed - I edited the article above to the current ones. There was a slight improvement to using the globally unique displayname as the host reference in the depends_on property - the above article also reflects that...)

No, not so much (same error) - unless I need to logout/login

That looks like you are using the old locator code (as the new one is not v1.0.0).

Can you try with locator JZ62NH?

That should be what the above article shows -maybe there was some caching....

That was it - I have added both datasources (I did refresh this page).     Thanks Steve!

Safe to assume this stitched relationship would also trickle into putting a node into SDT and having their uplinks (if switches...) also inherit SDT from parent?

Yes - it puts the whole device into SDT - so all interfaces, etc.

On 2/9/2018 at 6:14 PM, Steve Francis said:

Yes - it puts the whole device into SDT - so all interfaces, etc.

Great.  Not sure if assumed, but if we put node A into SDT, then the connecting interfaces NOT on this device, but connected to, would also go into SDT?