Forum Discussion
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.
Setting property primaryalert to this value
|
will suppress dependent devices’ alerts when the primary has this alert: |
HTTPS- |
any alerts about the HTTPS- datasource. |
HTTPS-,instanceName:HTTPS-443 |
alerts on the 443 instance of the HTTPS- datasource |
HTTPS-,instanceName:HTTPS-443,dataPointName:CantConnect |
alerts on the datapoint CantConnect, on the 443 instance of the HTTPS- datasource. |
HTTPS-,instanceName:HTTPS-443,dataPointName:CantConnect,severity:4|3 |
also require that the alerts are of level Error (3) or Critical (4). |
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.
Related Content
- 6 years ago
- 6 years ago