Actions83
- Bills Actions
- Alerts Actions
- Alert Rules Actions
- ARP Actions
- Devices Actions
- Device Groups Actions
- Inventory Actions
- Locations Actions
- Logs Actions
- Poller Groups Actions
- Ports Actions
- Port Groups Actions
- Routing Actions
- Services Actions
- Switching Actions
Overview
This node operation updates an existing alert rule in the LibreNMS network monitoring system. Alert rules define conditions under which alerts are triggered based on device statuses or other monitored parameters. Updating an alert rule allows users to modify its criteria, severity, targeted devices, and notification behavior without creating a new rule from scratch.
Common scenarios for this operation include:
- Changing the devices or groups of devices that an alert rule applies to.
- Adjusting the severity level of an alert to better reflect its importance.
- Modifying the logical conditions that trigger the alert.
- Enabling or disabling the alert rule temporarily.
- Adding notes or muting notifications while keeping the alert visible in the UI.
Practical example: A network administrator wants to update an alert rule that monitors device status to include additional devices and change the severity from "Warning" to "Critical". They also want to add a delay before the alert triggers to avoid false positives during maintenance windows.
Properties
| Name | Meaning |
|---|---|
| Rule Name | The name of the alert rule being updated. |
| Devices | Device IDs the rule applies to, specified as a comma-separated list, or -1 to indicate a global rule applying to all devices. |
| Rule Builder | JSON object defining the logical condition(s) for triggering the alert. It includes fields like condition type (e.g., AND), rules array with field names, operators, and values. |
| Severity | The severity level of the alert. Options are: OK, Warning, Critical. |
| Rule ID | The unique identifier of the alert rule to update. |
| Additional Options | Collection of optional settings: - Disabled: Boolean to disable the rule. - Count: Number of polling runs before alert triggers. - Delay: Time delay before alerting (e.g., "5 m", "1 h"). - Interval: Frequency to re-issue notifications. - Mute: If true, alert shows in UI but no notifications sent. - Invert: Inverts the rule check logic. - Notes: Text notes about the rule. |
Output
The node outputs JSON data representing the updated alert rule as returned by the LibreNMS API. This typically includes the updated properties such as rule ID, name, devices, severity, conditions, and any metadata related to the alert rule.
If the node supports binary output (not indicated here), it would represent associated files or attachments related to the alert rule, but this is not applicable for this operation.
Dependencies
- Requires connection to a LibreNMS instance via its REST API.
- Needs an API key credential configured in n8n for authentication.
- The base URL and SSL certificate validation options must be set correctly in the node credentials.
- The node depends on the LibreNMS API endpoint
/api/v0/alert-rules/{rule_id}for updating alert rules.
Troubleshooting
- Invalid Rule ID: If the provided Rule ID does not exist, the API will return an error indicating the rule was not found. Verify the Rule ID is correct.
- Malformed Rule Builder JSON: The rule builder property must be valid JSON matching the expected schema. Invalid JSON or incorrect structure will cause errors.
- Permission Denied: Insufficient API permissions or invalid API key can result in authorization errors. Ensure the API key has rights to update alert rules.
- Device IDs Format: Providing device IDs in an incorrect format (not comma-separated or invalid IDs) may cause the update to fail.
- Delay and Interval Format: These time strings must follow accepted formats (e.g., "5 m" for 5 minutes). Incorrect formatting can lead to errors.
- Network Issues: Connectivity problems to the LibreNMS server will prevent the update operation.
Links and References
- LibreNMS API Documentation
- LibreNMS Alert Rules Guide
- n8n Documentation on HTTP Request Node (for understanding API calls)