LogicMonitor seeks to disrupt AI landscape with $800M strategic investment at $2.4B valuation to revolutionize data centers.

Learn More

Custom HTTP Delivery

Last updated on 04 September, 2024

Custom HTTP Alert Delivery methods (that is, Webhooks) allow you to send alert notification data to an external system via HTTP GET or POST requests. Similar to Custom Email Alert Delivery, this can be advantageous if you’re sending alert notifications to a ticketing system. Custom HTTP alert delivery enables you to define the precise format of the alert notification data using tokens (variables), so that it can be easily parsed by the recipient system.

Typically custom HTTP delivery methods make an HTTP POST and deliver alert notification data in a request payload. However, in some cases, an HTTP GET request is sufficient because the request itself has form data appended to the URL (for example, https://www.example.com/api?param1=abc&m2=def), and no payload needs to be posted.

Simply defining a custom alert delivery method will not result in notifications being routed via the custom delivery method.  The custom delivery method must be included as the contact method for a recipient in an escalation chain, and that escalation chain must be referenced by an alert rule. When configuring these, there are a few guidelines to follow to ensure alert data is posted and updated as expected in the target integration. For more information, see Alert Rules.

Adding Custom HTTP Delivery Integration

  1. In LogicMonitor, navigate to Settings > Integrations.
  2. Select Add Integration.
  3. From the Add Integration page, under Workflow Integration, select Custom HTTP Delivery.
    add custom http page
  1. Enter a Name and Description for the custom HTTP delivery integration.
    The Name field is mandatory and the value you enter for name appears in the list of integrations.
  2. Select the Alert Notification option you want:
    • Use the same URL and data to notify on various alert activity – Sends HTTP requests for alert activity to the same URL that the initial HTTP requests for new alerts were sent.
    • Use different URL or data format to notify on various alert activity – Sends HTTP requests to different URLs based on the alert activity.
  3. Select any of the following Alert Statuses for which you want to send a notification. By default, requests are sent for New Alerts.
    • Acknowledged: This state is to process previously generated alerts that are acknowledged.
    • Cleared: This state is for the alerts that satisfy the alert threshold that triggered it.
    • Escalated/De-escalated: This state is for an active alert increasing or decreasing in alert severity. For example, an alert updating from warning to error, or critical to error will use this definition. If the escalated status is selected and a note is added to the alert, an update request is sent whether the alert is active/cleared. If the escalated status is not selected and a note is added to the alert, a request is not sent.

Note: Alert rules and escalation chains are used to deliver alert data to your custom HTTP integrations. When configuring these, there are a few guidelines to follow to ensure notifications are posted and updated as expected in the target integration. These guidelines are discussed in Alert Integrations Overview.

  1. If you want to add customer headers, toggle the Use Custom Headers switch, and then do the following:
    1. Select Add Record and then enter values for Key and Value.
    2. Select Apply.

Note: Custom headers are used to define your authentication credentials. For the Content-Type header key, you can add a charset value as null or a charset value with a valid MIME type. If you provide an invalid charset or MIME type, a valid MIME type with UTF-8 is added by default.

  1. In the HTTP Method field, select the method you want. You can select HTTP Post or HTTP Get method.
  2. In the URL field, provide an URL for the HTTP request.
  3. Provide Username and Password associated with the specified username.
  4. To authentic using Basic Authentication, enter Username and Password. HTTP Basic authentication passes the username and password as fields in an HTTP header.
  5. To authenticate using OAuth 2.0, select OAuth 2.0, select the Grant Type you want and provide the following information:
    • If you select Grant type as client_credentials, provide information for the following fields:
      • Access Token URL –  Authentication server endpoint that verifies credentials and returns an access token if clientId and clientSecret are valid.
      • Client ID – OAuth application client ID
      • Client Secret – OAuth application client secret
      • Scope – The scope of the access request
    • If you select Grant type as password, provide information for the following fields:
      • Client ID – OAuth application client ID
      • Client Secret – OAuth application client secret
      • Username and Password – The username and password associated with the specified username
      • Scope – The scope of the access request.
  6. From Alert Data, select key and value pairs or raw format to customize the alert message.
    • Select Key/Value Pairs, select Add Record, provide key Name and Value, and then select Apply.
    • Select Raw, select Insert Tokens, and theninclude the tokens you want for the alert message. The following tokens are available:
      • ##ADMIN## – The user the alert was escalated to.
      • ##ADMIN.PHONE## – The phone number of the admin.
      • ##ADMIN.EMAIL## – The email ID of the admin.
      • ##ADMIN.PAGER## – The pager number of the admin.
      • ##ALERTTYPE## – The type of alert (that is, alert, eventAlert, batchJobAlert, hostClusterAlert, websiteAlert, agentDownAlert, agentFailoverAlert, agentFailBackAlert, alertThrottledAlert).
      • ##ALERTSTATUS## – The status of the alert.
      • ##MESSAGE## – The rendered text of the alert message. This token will also pass all relevant acked information (for example, the user that acknowledged the alert, ack comments, and so on).
      • ##ALERTID## – The ID of the alert.
      • ##EXTERNALTICKETID## – This captures the external system’s identifier for the ticket that is being created by the integration so that LogicMonitor can refer to it in future actions on that ticket.
        For more information, see Tokens Available in LogicModule Alert Messages.

Note:

  • To customize an alert message using Key/Value Pairs option, only JSON format is available. But to customize an alert message using Raw option, you can use Form Data, JSON, Plain Text, URL-Encoded Form Data or XML format.
  • By default, as an example, some tokens are included in the Alert Data message section. You can edit this section by adding tokens using the Insert Token button.
  1. Togglethe Include an ID provided in HTTP response when updating alert status switch if you want LogicMonitor to find the ID (for example, ticket ID) returned in response to the HTTP request that is associated with a new alert. The response format can be in JSON, Regular expression or XML. LogicMonitor will use this ID in any subsequent requests for alerts that are acknowledged, cleared, and escalated/de-escalated.
  2. Select Test Alert Delivery to send a test alert and message, to verify if you have configured the integration correctly.
  3. Select Import if you want to import integration details in JSON format.
  4. Select Save to save the custom HTTP integration.
  5. If you want to cancel the integration, select Cancel.
In This Article