Come join our live training webinar every other Wednesday at 11am PST and hear LogicMonitor experts explain best practices and answer common questions. We understand these are uncertain times, and we are here to help!
LogicMonitor can be made to work with most chat tools, ticketing systems and other services you may utilize internally. These alert integrations allow LogicMonitor to interact with your third-party collaboration tools, supporting activities such as opening, updating and closing incidents in these tools, based on LogicMonitor alerts.
Your LogicMonitor account comes pre-configured with the following out-of-the-box integrations:
In addition to numerous out-of-the-box integrations, LogicMonitor also supports the creation of custom integrations. Typically, these integrations are achieved using custom HTTP delivery (webhooks) or custom email delivery. LogicMonitor’s custom HTTP delivery routes alerts to external systems and tools via HTTP requests, and can retrieve ticket IDs or other unique identifiers from the response. Custom email delivery emails custom formatted alert notifications to external systems and tools in response to alerts that are triggered in your account. In other cases, custom integrations may utilize the LogicMonitor API or external alerting capabilities.
All new integration setups can be initiated via Settings | Integrations | Add, as shown next. For details on configuring an out-of-the-box alert integration (e.g. Autotask, Slack, etc.) or a common custom integration for which we provide documentation (e.g. Campfire, Zendesk, etc.), refer to that integration type’s individual support article. If no documentation exists for the alert integration you would like to create, review the instructions for creating custom alert integrations via either custom HTTP delivery (webhooks) or custom email delivery.
Alert rules are responsible for routing alert notifications to your third-party application for the purpose of opening, updating, and closing tickets. For this reason, it’s important that you understand how various alert rule configurations can impact your alert integrations. Next, we’ve documented some best practices when configuring alert rules for your alert integrations.
For more information on alert rules, see Alert Rules.
When associating alert rules with alert integrations, it’s important that a single alert rule maintains the entire lifecycle of the alert. Put another way, if an alert rule references delivery to an alert integration as part of its escalation chain, that rule should be configured to match all potential alert level severities. If it doesn’t, you risk:
Why? When LogicMonitor prepares to deliver alert information to a third-party integration, it looks to see if an external reference such as a ServiceNow ticket ID or PagerDuty reference ID is in place for that alert. These references are returned by the integration target in its response to LogicMonitor’s HTTP/S post. LogicMonitor captures this reference, associates it with the alert using a key that consists of the alert rule ID and integration ID, and then uses it to tie all future activity for that alert back to the original target integration object (e.g. ticket).
If an external reference is not found for an alert, a “create” payload is sent to the integration target that results in the creation of a new object. If the external reference is found, an “update” payload is sent to the integration target that serves to change the status of the existing object in some way (e.g. updates the alert severity status or indicates the alert has been cleared or acknowledged).
Because LogicMonitor associates the external reference with a combination of keys that include the alert rule ID, duplicate and/or orphaned tickets can result if multiple alert rules are involved, effectively breaking the connection with the external reference. For example, consider the following scenario:
An alert rule matches a critical alert and delivers it to a ServiceNow integration, resulting in the creation of a ticket. The alert is later de-escalated to a warning within LogicMonitor, which matches a different alert rule that also delivers to the same ServiceNow integration. However, because the second alert rule has no connection with the external ticket ID generated as a result of the first rule two tickets now exist in ServiceNow for the same issue (the first created as a result of the critical alert and the second as a result of the critical alert de-escalating to warning).
Note: The external reference can be exposed via the ##EXTERNALTICKETID## token.
To reduce the incidence of orphaned tickets in your third-party application, check the Send notification when alerts clear option for the alert rule. In addition to ensuring that any recipient that was delivered the initial alert notification will also receive an alert clear notification (assuming the alert type supports alert clear notifications), this option also ensures that this alert clear notification will be delivered, even if SDT (scheduled downtime) was subsequently activated. In other words, if your third-party application received an alert notification, it will also receive an alert clear notification, regardless of SDT status.
While SDT is designed to suppress alert routing, overriding SDT in this case is crucial for alert integrations that rely on routed alert clear notifications to close tickets in third-party applications. Please note that this SDT override behavior only applies to alerts triggered by DataSources. For more information on SDT, see SDT Tab.
In This Article