LogicMonitor provides logs for out-of-the-Box (OOTB) integrations directly in your portal. This gives you visibility into the outgoing and response payloads for every integration call to help you troubleshoot. Each time LogicMonitor makes a call to an integration, an entry is added to the Integrations Logs. Communication inbound to LogicMonitor from an integration is captured in the Audit Logs. For more information, see About Audit Logs.

You can expand each individual log for more details about the call, including the HTTP response, header, number of delivery retries, and error message (if applicable).

While LogicMonitor has a robust alert delivery, escalation, and reporting system, you may be using other tools in parallel to access and store IT information.

You can use LogicMonitor’s custom HTTP delivery integration settings to enable LogicMonitor to create, update, and close tickets in Zendesk in response to LogicMonitor alerts.

In this support article, we’ve divided the process of creating a Zendesk/LogicMonitor integration into three major steps:

1. Familiarize yourself with background resources
2. Ready Zendesk for integration
3. Create the Zendesk custom HTTP delivery integration in LogicMonitor

Familiarize Yourself with Background Resources

Review the following resources before configuring your Zendesk integration:

• LogicMonitor support article: Custom HTTP Delivery. This support article provides an overview of the various configurations and settings found in LogicMonitor’s custom HTTP delivery integrations.
• LogicMonitor support article: Tokens Available in LogicModule Alert Messages. This support article provides an overview of the available tokens that can be passed through to Zendesk. Note: The examples in this support article additionally use a ##zendesk.authorid## token that was created as a custom property on the device. Custom device properties can be very useful when using the same integration to create tickets as multiple organizations or users.
• Zendesk developer documentation: API Introduction

Ready Zendesk for Integration

To ready Zendesk for integration, perform the following steps:

1. Create a Zendesk user to be used for authentication.
2. Configure your Zendesk API key for authentication.

Create the Zendesk Custom HTTP Delivery Integration in LogicMonitor

To create a Zendesk/LogicMonitor custom HTTP delivery integration that can create, update, and close tickets in Zendesk in response to LogicMonitor alerts, perform the following steps:

1. Select Settings > Integrations > Add > Custom HTTP Delivery.
2. Enter a name and description for the Zendesk integration.
3. Select Use different URLs or data formats to notify on various alert activity.
   This allows LogicMonitor to take different actions in Zendesk, depending on whether the alert is being created, acknowledged, cleared, or escalated.
4. Specify settings for creating a new ticket (as triggered by a new alert):
   Note: For each request, you can select which alert statuses trigger the HTTP request. Requests are sent for new alerts (status: Active), and can also be sent for alert acknowledgements (status: Acknowledged), clears (status: Cleared) and escalations/de-escalations/adding note (status: Escalated). 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.
   1. Select HTTP Post as the HTTP method and enter the URL to which the HTTP request should be made. Format the URL to mimic this path structure: “[acme].zendesk.com/api/v2/tickets.json”. Be sure to preface the URL with “https://” in the preceding drop-down menu.
   2. Provide username and password values.
      Note: When authenticating with the Zendesk API, you only need to enter the API key in the password field and your username with “/token” appended at the end, as shown in the next screenshot.
   3. The settings under the “Alert Data” section should specify raw JSON, and the payload should look something like the following as a starting point:

      {   "ticket": {     "subject":  "##LEVEL## - ##HOST## ##INSTANCE##", "type": "incident",     "comment":  { "body": "Host: ##HOST##\nDatasource: ##DATASOURCE##\nDatapoint: ##DATAPOINT##\nLevel: ##LEVEL##\n Start: ##START##\nDuration: ##DURATION##\nValue: ##VALUE##\nReason: ##DATAPOINT## ##THRESHOLD##"},     "priority": "normal"   } }

      

5. If you want LogicMonitor to update the status of your Zendesk tickets when the alert changes state or clears, check the “Include an ID provided in HTTP response when updating alert status” box. Enter “JSON” as the HTTP response format and enter “ticket.id” as the JSON path, as shown next. This captures Zendesk’s identifier for the ticket that is created by the above POST so that LogicMonitor can refer to it in future actions on that ticket using the ##EXTERNALTICKETID## token.
6. Click the Save button located within the blue box to save the settings for posting a new alert.
7. Click the + icon to specify settings for acknowledged alerts, if applicable to your environment. Several settings remain the same as entered for new alerts, but note the following changes:
   1. Select Acknowledged.
   2. Select “HTTP Put” as the HTTP method and enter the URL to which the HTTP request should be made. Notice that the URL in the following screenshot references a slightly different URL path than the one used to create a new ticket and includes the ##EXTERNALTICKETID## token in order to pass in the ticket we want to acknowledge.
   3. The payload should look something like the following as a starting point:

      {   "ticket": {     "status": "open",      "comment": { "body": "##MESSAGE##", "author_id": "##zendesk.authorid##" }   } }

8. Save the settings for acknowledged alerts and then click the + icon to specify settings for escalated alerts, if applicable to your environment. Several settings remain the same as entered for acknowledged alerts, but note the following changes:
   1. Check the “Escalated/De-escalated” box.
   2. The payload should look something like the following as a starting point:

      {   "ticket": {     "subject":  "##LEVEL## - ##HOST## ##INSTANCE##", "type": "incident",     "comment":  { "body": "Alert Escalated/De-escalated:\nHost: ##HOST##\nDatasource: ##DATASOURCE##\nDatapoint: ##DATAPOINT##\nLevel: ##LEVEL##\n Start: ##START##\nDuration: ##DURATION##\nValue: ##VALUE##\nReason: ##DATAPOINT## ##THRESHOLD##"},     "priority": "normal"   } }

9. Save the settings for escalated alerts and then click lick the + icon to specify settings for cleared alerts. Several settings remain the same as entered for acknowledged and escalated alerts, but note the following changes:
   1. Check the “Cleared” box.
   2. The payload should look something like the following as a starting point:

      {   "ticket": {     "subject":  "##LEVEL## - ##HOST## ##INSTANCE##", "type": "incident",     "comment":  { "body": "Alert Cleared:\nHost: ##HOST##\nDatasource: ##DATASOURCE##\nDatapoint: ##DATAPOINT##\nLevel: ##LEVEL##\n Start: ##START##\nDuration: ##DURATION##\nValue: ##VALUE##\nReason: ##DATAPOINT## ##THRESHOLD##"},     "status": "solved","priority": "normal"   } }

10. Save the settings for cleared alerts and then click the Save button at the very bottom of the screen to save your new Zendesk custom HTTP delivery integration.
11. Add your newly created delivery method to an escalation chain that is called by an alert rule. Once you do, Zendesk issues will be automatically created, updated, and cleared by LogicMonitor alerts, as shown next.

    Note: Alert rules and escalation chains are used to deliver alert data to your Zendesk integration. When configuring these, there are a few guidelines to follow to ensure tickets are created and updated as expected within Zendesk. For more information, see Alert Rules and Escalation Chains.

    

Puppet is IT automation software that enables system administrators to manage provisioning and configuration of their infrastructure.  We know that in addition to maintaining correct infrastructure configuration, system administrators additionally rely on monitoring to help prevent outages.  Our Puppet module was created with this in mind, and allows your Puppet infrastructure code to manage your LogicMonitor account as well.  This enables you to confirm that correct device properties are maintained, that devices are monitored by the correct Collector, that they remain in the right device groups and much more.

Module Overview

LogicMonitor’s Puppet module defines 4 classes and 4 custom resource types:

Classes

• logicmonitor: Handles setting the credentials needed to interact with the LogicMonitor API
• logicmonitor::master: Collects the exported lm_device resources and lm_devicegroup resources. Communicates with the LogicMonitor API
• logicmonitor::collector: Handles LogicMonitor collector management for the device. Declares an instance of lm_collector and lm_installer resources
• logicmonitor::device: Declares an exported lm_device resource
• logicmonitor::device_group: Declares an exported lm_device_group resource

Resource Type

• lm_device_group: Defines the behavior of the handling of LogicMonitor device groups. We recommend using exported resources
• lm_device: Defines the handling behavior of LogicMonitor collectors. Used only with the logicmonitor::collector class
• lm_collector: Defines the handling behavior of LogicMonitor collectors. Used only with the logicmonitor::collector class
• lm_installer: Defines the handling behavior of LogicMonitor collector binary installers. Used only within the logicmonitor::collector class

Requirements

To use LogicMonitor’s Puppet Module, you need the following:

1. Ruby 1.8.7 or 1.9.3
2. Puppet 3.X or Puppet 4.x
3. JSON Ruby gem (included by default in Ruby 1.9.3)
4. Store Configs in Puppet
5. Device Configuration

Store Configs

To enable store configs, add storeconfigs = true to the [master] section of your puppet.conf file, like so:

# /etc/puppet/puppet.conf
[master]
storeconfigs = true

Once enabled, PuppetDB is needed to store the config info.

Device Configuration

As with your other LogicMonitor devices, the collector will need to communicate with the device in order to gather data. Make sure the correct properties and authentication protocols are configured as part of the Puppet installation.

Installing the LogicMonitor Puppet Module

You can install LogicMonitor’s Puppet Module one of two ways:

1. Using Puppet’s Module Tool
2. Using GitHub

Using Puppet’s Module Tool

Run the following command on your Puppet Master to download and install the most recent version of the LogicMonitor Puppet Module published on Puppet Forge:

$ puppet module install logicmonitor-logicmonitor

Using GitHub

$ cd /etc/puppet/modules
$ git clone git: //github.com/logicmonitor/logicmonitor-puppetv4.git
$ mv logicmonitor-puppet-v4 logicmonitor

Getting Started

Once you’ve installed LogicMonitor’s Puppet Module, you can get started using the following sections:

• Create a new user for Puppet
• Configuration
• Examples

Create a New User for Puppet

We recommend you create a new user with administrator privileges in your LogicMonitor account that you will use exclusively within your Puppet nodes to track changes made by Puppet in the audit log. You will need to provision this user API Tokens.

Configuration

• Class: logicmonitor (modules/logicmonitor/manifests/init.pp)

This is the top level class for the LogicMonitor module; it only needs to be defined on the Puppet Master. Its purpose is to set the LogicMonitor credentials to be used by all the child classes.

• class: logicmonitor::master (modules/logicmonitor/manifests/master.pp)

The master class enables communication between the LogicMonitor module and your LogicMonitor account for group and device management. This class acts as the collector for the lm_device and lm_devicegroup exported resources. This prevents conflicts and provides a single point of contact for communicating with the LogicMonitor API. This class must be explicitly declared on a single device.

Parameters: none

• Class: logicmonitor::collector (modules/logicmonitor/manifests/collector.pp)

This class manages the creation, download, and installation of a LogicMonitor collector on the specified node.

• The only absolute requirement for a collector node is that it is Linux and can make an outgoing SSL connection over port 443
• We suggest the collector system have at least 1G of RAM
• If the collector will be collecting data for more than 100 devices, it is a good idea to dedicate a machine to it

• Class: logicmonitor::device (modules/logicmonitor/manifests/device.pp)

This class is used to add devices to your LogicMonitor account. Devices which are managed through Puppet will have any properties not specified in the device definition removed.

class {'logicmonitor:: device':
collector => "qa1.domain.com",
hostname => "10.171.117.9",
groups => ["/Puppetlabs", "/Puppetlabs/Puppetdb"],
properties => {"snmp.community" => "Puppetlabs"}.
description => "This device hosts the PuppetDB instance for this deployment",
}

class {'logicmonitor::device':
collector => $fqdn,
display_name => "MySQL Production Host 1",
groups => ["/Puppet", "/production", "/mysql"],
properties => {"mysql.port" => 1234},
}

Adding a Device Group:

Type: lm_device_group Device groups should be added using an exported resource to prevent conflicts. It is recommended device groups are added from the same node where the logicmonitor::master class is included. Devices can be included in zero, one, or many device groups. Device groups are used to organize how your Logic Monitor Devices are displayed and managed and d not require a collector. Properties set at the device group level will be inherited by any devices added to the group.

Examples

To add collector to a node:

include logicmonitor::collector

If you want to specify a specific location where you’d like to install a collector:

class{"logicmonitor::collector":
install_dir => $install_dir,
}

To add and edit properties of device groups use lm_devicegroup, example below.

@@lm_device_group{"/parent/child/grandchild/greatgrandchild":
ensure => present,
disable_alerting => false,
properties => {"snmp.community" => "n3wc0mm", "mysql.port" => 9999, "fake.pass" => "12345"}, description => "This is the description",
}

For more examples of the module in action, check out logicmonitor-puppet-v4/README.md.

Your LogicMonitor account comes ready to integrate alert messages with your ServiceNow account. The bidirectional integration enables LogicMonitor to open, update and close ServiceNow incidents based on LogicMonitor alerts. By sending alerts from LogicMonitor into ServiceNow, you can take advantage of ServiceNow’s alerting platform features to increase uptime of your apps, servers, websites, and databases. ServiceNow users can also acknowledge an alert directly from an incident in ServiceNow.

As discussed in the following sections, setup of this integration requires:

1. Installation of the LogicMonitor Incident Management Integration from the ServiceNow store.
2. Configuration of the integration within LogicMonitor
3. Configuration of alert rule/escalation chain to deliver alert data to the integration
4. Configuration of ServiceNow (optional) to include acknowledge option on incident form

Installing and Configuring the LogicMonitor Incident Management Integration

1. Click the GET button on the LogicMonitor Store page.
2. Accept ServiceNow’s Notice by clicking Continue
3. Note the Dependencies and Continue if they apply to your environment
   • For the Entitlement Section choose to make the application available to all instances or just specific ones.  (NOTE: This step does not install the application, it just makes it available for install later.)
   • Accept the ServiceNow Terms
   • Click GET
4. Login to your ServiceNow instance
5. Navigate to System Applications > Applications
6. The LogicMonitor Incident Management application should be available in the Downloads section.  Click Install to add the application to your instance.

After the application is installed you will need to provide account details for ServiceNow to automatically acknowledge alerts:

1. Navigate to LogicMonitor Incident Management > Setup > Properties
2. Set values for:
   • LogicMonitor Account Name
   • API Access ID*
   • API Access Key*
3. Click Save

*As discussed in API Tokens, API tokens for LogicMonitor’s REST API are created and managed from the User Access page in the LogicMonitor platform.

Configuring the Integration in LogicMonitor

You can enable the ServiceNow Integration in your account from Settings > Integrations.  Select Add and then ServiceNow:

SubDomain

Your ServiceNow subdomain. You can find this in your ServiceNow portal URL. For example, if your ServiceNow portal url is https://dev.service-now.com/, your subdomain would be dev.

Username

The username associated with the ServiceNow account you want LogicMonitor to use to open, update and close ServiceNow incidents. Ensure that this user account is assigned the “LogicMonitor Integration” (x_lomo_lmint.LogicMonitor Integration) role, which was automatically added to your ServiceNow instance as part of the LogicMonitor application installation performed in step 1.

Password

The password associated with the ServiceNow username you specified.

ServiceNow Default Settings

The ServiceNow Settings section enables you to configure how incidents are created in ServiceNow for LogicMonitor alerts.

Company

The ServiceNow company that incidents will be created for.

Note: If you’d like to create, update and delete tickets across multiple ServiceNow companies, you can do that by setting the following property on the device whose alerts should trigger a new or change to existing ServiceNow incident:

servicenow.company

When an alert is triggered and routed to the ServiceNow Integration, LogicMonitor will first check to see if this property exists for the device associated with the alert. If it does exist, its value will be used instead of the value set in the Integration form.

Due Date

This field will determine how LogicMonitor sets the due date of the incidents in ServiceNow. Specifically, the ServiceNow incident due date will be set to the number of days you set this field to.

ServiceNow Severities

Indicate how the LogicMonitor alert severities should map to incidents created in your ServiceNow portal.

Note: This mapping determines severity level only for the ServiceNow incident. It does not play a role in determining the incident’s priority level.

ServiceNow status

Indicate how the LogicMonitor alert statuses should update the incidents created in your ServiceNow portal.

HTTP Delivery

The HTTP Delivery section controls how LogicMonitor formats and sends the HTTP requests to create, update and/or close incidents. You shouldn’t need edit to anything in the HTTP Delivery section, but if you wish to customize something you can use the information in the following sections to guide you.  If not, you can save the integration now and proceed to the Configuring Alert Rule and Escalation Chain section.

By default, LogicMonitor will pre-populate four different HTTP requests, one for each of:

• new alerts (Active)
• acknowledged alerts (Acknowledged)
• cleared alerts (Cleared)
• escalated alerts (Escalated)

For each request, you can select which alert statuses trigger the HTTP request. Requests are sent for new alerts (status: Active), and can also be sent for alert acknowledgements (status: Acknowledged), clears (status: Cleared) and escalations/de-escalations/adding note (status: Escalated). 

HTTP Method

The HTTP method for ServiceNow integrations is restricted to POST and PUT.

URL

The URL that the HTTP request should be made to. This field is auto-populated based on information you’ve provided.

Alert Data

The custom formatted alert data to be send in the HTTP request (used to create, update and close ServiceNow incidents). This field will be auto-populated for you. You can customize the alert data field using tokens.

Test Alert Delivery

This option sends a test alert and provides the response, enabling you to test whether you’ve configured the integration correctly.

Tokens Available

The following tokens are available:

• LogicModule-specific alert message tokens, as listed in Tokens Available in LogicModule Alert Messages.
• ##ADMIN##. The user the alert was escalated to.
• ##MESSAGE##. The rendered text of the alert message. This token will also pass all relevant acked information (e.g. the user that acknowledged the alert, ack comments, etc.).
• ##ALERTTYPE##. The type of alert (i.e. alert, eventAlert, batchJobAlert, hostClusterAlert, websiteAlert, agentDownAlert, agentFailoverAlert, agentFailBackAlert, alertThrottledAlert).
• ##EXTERNALTICKETID##. The ServiceNow incident ID.

Configuring Alert Rule and Escalation Chain

Alert rules and escalation chains are used to deliver alert data to your ServiceNow integration. When configuring these, there a few guidelines to follow to ensure tickets are opened, updated, and closed as expected within ServiceNow. For more information, see Alert Rules.

Alert Acknowledgement

You can configure an incident form in ServiceNow to acknowledge LogicMonitor alerts from ServiceNow. This involves adding an Acknowledge option to a ServiceNow Incident form, and allows technicians to view acknowledged LogicMonitor alerts from ServiceNow.

Requirements

To acknowledge LogicMonitor alerts from ServiceNow, you must have the LogicMonitor instance set up in the Incident Management Setup tab in ServiceNow. This involves providing your LogicMonitor Account Name and corresponding API Tokens. 

For more information about configuring an incident in ServiceNow, see ServiceNow’s Incident Management documentation.

For more information about creating LogicMonitor API tokens, see API Tokens.

Adding Acknowledge Option to ServiceNow Incident Form

1. As a ServiceNow administrator open an incident form.
2. Click the Menu button > Configure > Form Design.

​

3. Drag “LogicMonitor Alert Acknowledge” to the appropriate section of your form.

Additional ServiceNow solutions can be found in our Communities and Blog Posts that demonstrate custom implementations using the LogicMonitor Marketplace application as a base.

LogicMonitor offers an out-of-the-box alert integration for Slack via the LogicMonitor app for Slack. The integration between LogicMonitor and Slack is bi-directional, supporting the ability to:

• Route LogicMonitor alert notifications to Slack
• View and acknowledge alerts from Slack
• Put the resource triggering the alert into scheduled downtime (SDT) from Slack
• Open alerts in LogicMonitor from Slack
• Configure the conditions (alert rule, escalation chain, recipient group) under which alerts are routed to Slack—from Slack or LogicMonitor

Setting Up the LogicMonitor App for Slack

Setup of LogicMonitor’s alert integration solution for Slack involves four primary steps:

• Installing and configuring the app
• Routing alerts to Slack
• Adding/inviting the app to a Slack channel
• Configuring additional Slack channels (optional)

Installing and Configuring the Slack App

Installation and configuration of the LogicMonitor app for Slack can be initiated from either your LogicMonitor portal or Slack workspace.

Installation and Configuration from LogicMonitor

Follow these steps to initiate installation and configuration of the LogicMonitor app for Slack from within LogicMonitor:

1. In LogicMonitor, navigate to Settings > Integrations.
2. Select Add. The Start New Integration pane appears.
   
3. Select Slack App. The Add Slack-2 Integration dialog box appears.
   
4. Enter a unique name and description for the Slack integration. The value you enter for Name displays in the list of integrations. 

5. Select any of the following options to install and configure the LogicMonitor app:
   • Add Integration to New Workspace to install and configure the LogicMonitor app for a Slack workspace that doesn’t yet have the app installed.
   • Add Integration to Existing Workspace to create additional channel integrations for a Slack workspace that already has the LogicMonitor app installed. To know more about configuring additional integrations for a Slack workspace, see the Configuring Additional Slack Channels section of this support article.
6. Depending on the level of permissions you have for your Slack workspace, the following Slack options appear:
   • If you have the permissions to install apps to your Slack workspace, click the Allow button to grant the LogicMonitor app access to your Slack workspace and proceed to the next step.
   • If you do not have the permissions to install apps to your Slack workspace, enter a note and click Submit to request install approval from a Slack app manager. Once permission has been granted, begin this set of steps again.

7. You are redirected back to LogicMonitor where additional configurations are now available.
   
8. From Alert Data, select Insert Token, and select the tokens you want for customizing the alert message. To know more about tokens, see Tokens.

9. Select the HTTP Delivery section to format and send the HTTP Post requests to create, update and/or close incidents.
   By default, LogicMonitor will pre-populate four different HTTP requests, one for each of the following alert statuses:
   • New alerts (Active)
   • Acknowledged alerts (Acknowledged)
   • Cleared alerts (Cleared)
   • Escalated alerts (Escalated)
10. From the Select Channel dropdown menu, select the Slack channel to which LogicMonitor alert notifications will be routed. Only public channels are initially available from the dropdown; once set up, you could change a public channel to a private channel and it would persist as an option here.

11. Select the alert statuses you would like routed to Slack. Receipt of new alerts is mandatory, but updates on the current alert status (escalated/de-escalated, acknowledged, cleared) are optional.

12. Select Save.

Installation and Configuration from Slack

Follow these steps to initiate installation and configuration of the LogicMonitor app from within Slack:

1. From the Slack App Directory, install the LogicMonitor app to your workspace.
2. Depending on the level of permissions you have for your Slack workspace, Slack presents you with one of the following options:
   • If you have the permissions necessary to install apps to your Slack workspace, click the Allow button to grant the LogicMonitor app access to your Slack workspace and proceed to the next step.
   • If you do not have the permissions necessary to install apps to your Slack workspace, enter a note and click Submit to request install approval from a Slack app manager. Once permission has been granted, begin this set of steps again.
3. You are redirected back to your Slack workspace. Open the LogicMonitor app from the left-hand menu where a direct message is waiting. Click the Get Started button from the direct message to configure the alert integration.

   

   Note: This direct message is only available to the Slack user that performed the previous installation steps.

4. At the Finish Your Install dialog, enter the name of your LogicMonitor portal into the Portal Name field. Your portal name can be found in the first portion of your LogicMonitor URL (for example, https://portalname.logicmonitor.com).

   

5. In the Integration Name and Integration Description fields, enter a unique name and description for your Slack integration. The name entered here will be used as the title for the resulting integration record within LogicMonitor.
6. Verify the alert statuses you would like routed to Slack. New alerts, which are not shown here for selection, are mandatory and part of the integration by default, but updates on the current alert status (escalated/de-escalated, acknowledged, cleared) are optional and can be disabled.
7. From the Channel field’s dropdown menu, select the Slack channel to which LogicMonitor alert notifications will be routed.
8. Click the Submit button. A new message displays to indicate successful creation of a LogicMonitor integration record for Slack. This new record can be viewed and edited in LogicMonitor by navigating to Settings | Integrations.

   

   The success message also prompts you to optionally begin configuring alert routing conditions, which determines which alerts are delivered to the Slack channel that is associated with the integration. Because this workflow can be configured at a later time—via the LogicMonitor portal—you have the option to exit these configurations at any time by clicking the Exit Configuration Process button.

   If you’d like to begin configuring alert routing conditions from Slack, you have two options from this dialog:

   • Assign to Recipient Group. A recipient group is a single entity that holds multiple alert delivery recipients. Recipient groups are intended for use as time-saving shortcuts when repeatedly referencing the same group of recipients for a variety of different types of alerts. There is no requirement to make your Slack integration a member of a recipient group in order to have alerts routed to it; you can optionally directly reference the integration from an escalation chain if it doesn’t make sense to group alert delivery to Slack with other alert recipients. However, if a recipient group does make sense for your Slack integration, you can add your new Slack integration as a member of a new or existing recipient group. See the following Assigning Your Slack Integration to a Recipient Group section of this support article for more information.
   • Assign to Escalation Chain. An escalation chain determines which recipients should be notified of an alert, and in what order. From Slack, you can add your new Slack integration as a stage in an existing escalation chain or you can create a new escalation chain. See the following Assigning Your Slack Integration to an Escalation Chain section of this support article for more information.

Assigning Your Slack Integration to a Recipient Group

There is no requirement to make your Slack integration a member of a recipient group in order to have alerts routed to it; you can optionally directly reference the integration from an escalation chain if it doesn’t make sense to group alert delivery to Slack with other alert recipients. For more information on the logic behind recipient groups, see Recipient Groups.

However, if a recipient group does make sense for your Slack integration, follow the next set of steps to add your new Slack integration as a member to a new or existing recipient group.

1. Click the Assign to Recipient Group button to begin recipient group configuration.
2. Indicate whether you’ll be adding this Slack integration as a member to an existing group or whether you’ll be creating a new recipient group.

   

   • Update Recipient Group. To add this integration as a member to an existing recipient group, click the Update Recipient Group button and, from the Update a Recipient Group dialog that displays, select the recipient group from the provided dropdown. Slack limits dropdown menus to 100 selections, listed in alphabetical order; if your desired recipient group is not present due to this limitation, you can enter its name directly in the field below.

     Note: By adding this integration to an existing recipient group, all escalation chains currently configured to route to that recipient group will automatically begin delivery to your Slack integration. This means that there may not be a need for any additional alert delivery configurations.

   • Create Recipient Group. To add this integration as a member to a brand new recipient group, click the Create Recipient Group button. From the Add New Recipient Group dialog that displays, enter a unique name and description for the new recipient group.

     Note: A brand new recipient group will eventually need to be assigned to an escalation chain in order for alerts to be routed to its members.

3. Click the Submit button. A new message displays to indicate successful assignment of the Slack integration to the new or existing recipient group. The recipient group record you just created or updated can be further edited in LogicMonitor by navigating to Settings | Alert Settings | Recipient Groups.

   

   The success message also prompts you to optionally assign the recipient group you just edited/created to a new or existing escalation chain. Remember, if you just added your Slack integration to an existing recipient group, you may not necessarily need to perform any escalation chain configurations as all escalation chains currently configured to route to that recipient group will automatically begin delivering to your Slack integration. If you added your Slack integration to a brand new recipient group, the new recipient group will eventually need to be assigned to an escalation chain in order for alerts to be routed to its members.

   If you’d like to assign your recipient group to a new or existing escalation chain, see the next section of this support article.

Assigning Your Slack Integration to an Escalation Chain

From Slack, you can add your new Slack integration (or a recipient group that contains your Slack integration) as a stage in an existing or new escalation chain. For more information on the role escalation chains play in alert delivery, see Escalation Chains.

The configuration of an escalation chain from within Slack can be arrived at in one of two ways:

• You chose to add your Slack integration directly to an escalation chain immediately after configuring a new Slack channel.
• You edited/created a new recipient group from Slack and are now adding that recipient group to an escalation chain.

Either way, whether you are adding your Slack integration directly to an escalation—or a recipient group containing your Slack integration as a member—the following set of steps is the same.

1. Indicate whether you’ll be adding this integration/recipient group as a stage in an existing escalation chain or a new escalation chain.

   

   • Update Escalation Chain. To add the integration/recipient group as a stage in an existing escalation chain, click the Update Escalation Chain button.
     1. From the Update a Chain dialog that displays, select the escalation chain from the provided dropdown. Slack limits dropdown menus to 100 selections, listed in alphabetical order; if your desired escalation chain is not present due to this limitation, you can enter its name directly in the field below. Click Next.
     2. Select the stage to which the integration/recipient group should be added from the provided dropdown.

        Note: By adding this integration/recipient group to an existing escalation chain, all alert rules currently configured to route to that escalation chain will automatically begin delivery to your Slack integration. This means that there may not be a need for any additional alert delivery configurations.

   • Create Escalation Chain. To add this integration/recipient group as a stage in a brand new escalation chain, click the Create Escalation Chain button and, from the Add New Escalation Chain dialog that displays, enter a unique name and description for the new escalation chain.

     Note: The integration/recipient group is automatically assigned as the first stage of the new escalation chain. Escalation chains can have multiple stages and advanced configurations; to build on your new escalation chain, open it in LogicMonitor.

2. Click the Submit button. A new message displays to indicate successful assignment of the Slack integration or recipient group to the escalation chain. The escalation chain record you just updated/created can be further edited in LogicMonitor by navigating to Settings | Alert Settings | Escalation Chains.

   The success message also prompts you to optionally assign the escalation chain you just edited/created to a new or existing alert rule. Remember, if you just added your Slack integration to an existing escalation chain, you may not necessarily need to perform any alert rule configurations as all alert rules currently configured to route to that escalation chain will automatically begin delivering to your Slack integration. If you added your Slack integration to a brand new escalation chain, the escalation chain will eventually need to be assigned to an alert rule in order for alerts to be routed through it.

   If you’d like to assign your escalation chain to a new or existing alert rule, see the next section of this support article.

Assigning Your Escalation Chain to an Alert Rule

From Slack, you can assign your newly created/updated escalation chain to a new or existing alert rule using the following set of steps. (For more information on the role alert rules play in alert delivery, see Alert Rules.)

1. From the success message that displays after editing/creating an escalation chain (see previous screenshot), indicate whether you’ll be assigning your escalation chain to an existing or new alert rule.
   • Update Alert Rule. To assign the escalation chain to an existing alert rule, click the Update Alert Rule button and, from the Update an Alert Rule dialog that displays, select the alert rule from the provided dropdown. Slack limits dropdown menus to 100 selections, listed in alphabetical order; if your desired alert rule is not present due to this limitation, you can enter the name directly in the field below.

     Note: Once this escalation chain is assigned to an existing alert rule, all alerts matching that alert rule will be delivered to your Slack integration.

   • Create Alert Rule. To assign the escalation chain to a brand new alert rule, click the Create Alert Rule button and, from the Add New Alert Rule dialog that displays, configure the available settings.

     Note: The settings available here (priority, alert level, escalation interval) mirror what is available within the LogicMonitor portal when creating a new alert rule. For a description of these settings, see Alert Rules.

2. Click the Submit button. A new message displays to indicate successful assignment of the escalation chain to the alert rule.
3. If you assigned the escalation chain to a brand new alert rule, you’ll need to open the alert rule in LogicMonitor (Settings | Alert Settings | Alert Rules) in order to additionally configure which resources/instances/datapoints will trigger alert rule matching.

Routing Alerts to Slack

Alert notifications are routed to Slack in the same way that all alert notifications are routed: via an escalation chain that is associated with an alert rule within LogicMonitor. Through these very flexible mechanisms, you have complete control over which alerts are delivered to the Slack channel that is associated with the integration.

If you installed the LogicMonitor app from Slack, you may have already configured the recipient group, escalation chain, and/or alert rule responsible for delivering alert notifications to Slack, as outlined in these three previous sections:

• Assigning Your Slack Integration to a Recipient Group
• Assigning Your Slack Integration to an Escalation Chain
• Assigning Your Escalation Chain to an Alert Rule

If you installed the LogicMonitor app from LogicMonitor (or if you installed from Slack but chose to exit out of these alert routing configurations), you can configure alert routing to Slack by creating escalation chains and alert rules in LogicMonitor, as discussed in Escalation Chains and Alert Rules respectively.

Adding/Inviting the App to a Slack Channel

As with all Slack apps, the LogicMonitor app will not be allowed to send messages to your chosen Slack channel until it’s been added or invited to the channel. In the most cases, LogicMonitor will automatically add/invite the app to the Slack channel during install and configuration. The exception is if you’re creating an integration for a private channel that doesn’t already have the app added. In this rare instance, apps can be added to the private channel from the channel’s details or by opening the channel and mentioning the app (@logicmonitor) in a message, as shown next.

Configuring Additional Slack Channels (Optional)

As part of the app installation process, you will have configured one Slack channel to which alert notifications will be routed. This Slack channel is referenced by the resulting integration record that resides in LogicMonitor.

There is a one-to-one relationship between the integration records that reside in LogicMonitor and Slack channels. Therefore, if you’d like alert notifications to go to multiple channels within a single Slack workspace, you’ll need to create multiple integration records—one per channel. As with the installation process, this can be initiated from either your LogicMonitor portal or your Slack workspace.

Configuring Additional Slack Channels from LogicMonitor

To configure an additional Slack channel from LogicMonitor:

1. Select Settings | Integrations | Add | Slack.
2. In the configuration dialog, enter a unique name and description for your Slack integration.
3. Click the Add Integration to Existing Workspace button.
4. From the Select Workspace field’s dropdown menu, select the Slack workspace that will be assigned to the integration.
5. From the Select Channel field’s dropdown menu, select the Slack channel to which LogicMonitor alert notifications will be routed.

   Note: The channels available for selection correspond to the workspace selected in the previous field.

6. Check the alert statuses you would like routed to Slack. Receipt of new alerts is mandatory, but updates on the current alert status (escalated/de-escalated, acknowledged, cleared) are optional.
7. If you’d like to test your new integration before saving, click the Test Alert Delivery button to deliver a synthetic alert notification to the Slack channel specified on this dialog.

   Note: As discussed in the Testing Your Slack Integration section of this support article, you can come back to this dialog at any time to initiate a test.

8. Click Save.
9. Don’t forget to configure alert notification routing to your new Slack channel (integration record), as discussed in the Routing Alerts to Slack section of this support article.

Configuring Additional Slack Channels from Slack

To configure an additional Slack channel from Slack:

1. Open a Slack channel in the workspace in which the LogicMonitor app is installed and perform one of the following actions:
   • Mention the LogicMonitor app (@logicmonitor) in a message and click the Get Started button from the direct message that the LogicMonitor app sends in response.
   • Enter the slash command /lm configure [integration name]. See the Slack Slash Commands section of this support article for more information on slash commands.
2. Complete the fields presented on the Add a New Integration dialog.

   Note: This dialog prompts you to complete the same fields requested when initially installing the LogicMonitor app (with the exception of the Portal Name field which is not necessary in this context). These fields are documented in the Installation and Configuration from Slack section of this support article.

3. Click the Submit button. A new message displays to indicate successful creation of a LogicMonitor integration record for Slack. This new integration record can be viewed and edited in LogicMonitor by navigating to Settings | Integrations.

   The success message also prompts you to optionally begin configuring alert routing conditions, which determines which alerts are delivered to the Slack channel that is associated with the integration. Because this workflow can be configured at a later time—via the LogicMonitor portal—you have the option to exit these configurations at any time by clicking the Exit Configuration Process button.

   If you’d like to begin configuring alert routing conditions from Slack at this time, see the Installation and Configuration from Slack section of this support article where alert delivery configuration from Slack is documented in detail.

Testing Your Slack Integration

Once you’ve completed the required setup steps, you can test the connection between your Slack workspace and LogicMonitor portal by opening the integration record in LogicMonitor (Settings | Integrations) and clicking the Test Alert Delivery button. If successful, a synthetic read-only alert is sent to the Slack channel specified in the integration record.

Note: You can initiate a more thorough test, one that tests the entire chain of events from alert triggering to alert rule matching to alert delivery, from the resource or website whose alerts you want delivered to Slack. For more information, see Testing Alert Delivery.

Viewing and Responding to Alerts from Slack

Alert notifications are posted to your Slack channel with summary information that includes alert severity level, alert ID, alert message, and other key pieces of information.

As discussed in the following sections, there are several actions you can perform from alert notifications in Slack, depending upon the type of alert.

Note: A user must have the appropriate acknowledge and SDT permissions (as assigned on a resource group or website group basis) in LogicMonitor in order to perform these actions. For more information on assigning this level of permissions for resource and website groups, see Roles.

Open the Alert in LogicMonitor

Any alert notification can be directly linked to and opened in LogicMonitor by clicking the “Link to alert” hyperlink that is provided immediately above the alert message. The alert opens in the Alerts page. You will be prompted to log into LogicMonitor if you are not currently logged in.

Acknowledge the Alert

If viewing an active alert, you have the option to acknowledge the alert using the Acknowledge button. As discussed in Guidelines for Responding to Alerts, acknowledging an alert suppresses further routing of notifications for that particular alert.

Note: You can optionally enter the slash command /lm ack [alert ID] [comment - optional] to acknowledge an alert. See the Slack Slash Commands section of this support article for more information on available slash commands.
Upon successful acknowledgement, you will receive a confirmation message in Slack that the alert was acknowledged. If you attempt to acknowledge an alert that has since cleared or is inactive or has already been acknowledged, an ephemeral error message displays (visible only to you) explaining why the alert couldn’t be successfully acknowledged.

Assuming your Slack integration configuration was set up to include routing of alert notifications with an acknowledged status, you’ll also receive a new alert notification indicating acknowledged status.

Put the Resource or Instance Triggering the Alert into Scheduled Downtime (SDT)

If viewing an active alert, you have the option to put the resource (including a Collector resource) or instance that is triggering the alert into SDT using the Schedule Down Time button. As discussed in Guidelines for Responding to Alerts, SDT suppresses the routing of alert notifications for that resource or instance for the duration of SDT.

Note: You can optionally enter the slash command /lm sdt [alert ID] [comment - optional] to SDT an alert. See the Slack Slash Commands section of this support article for more information on available slash commands.

Upon successful scheduling of SDT, you will receive confirmation in Slack that the resource or instance was placed into SDT. If your attempt to schedule SDT is unsuccessful, an ephemeral error message displays (visible only to you) explaining why the alert couldn’t be successfully placed into SDT.

View the Full Details of the Alert

If viewing an active alert, you have the option to view additional details that aren’t initially presented by the alert notification using the Full Alert Details button. Upon clicking this button, an ephemeral message displays (visible only to you) with the additional details.

Slack Slash Commands

The following slash commands can be entered to interact with LogicMonitor alerts and integrations. With the exception of the SDT command, all commands can be performed from any channel in the Slack workspace, regardless of whether the LogicMonitor app has been invited to the channel.

• Help
• Acknowledge
• SDT
• Configure
• Uninstall

Help Slash Command

Returns a message offering useful information, shortcuts to common actions, and links to a list of currently available slash commands and this support page.

Command: /lm help

Acknowledge Slash Command

Acknowledges a LogicMonitor alert.

Command: /lm ack [alert ID] [comment - optional]

Examples:

• /lm ack LMD001
• /lm ack LMD001 investigating now

Schedule Downtime (SDT) Slash Command

Schedules downtime for a LogicMonitor alert, and its associated triggering resource or instance.

Command: /lm sdt [alert ID] [comment - optional]

Examples:

• /lm sdt LMD001
• /lm sdt LMD001 scheduled sdt for 30 minutes

Note: Unlike the other slash commands which can be performed from any channel in the Slack workspace, this command requires that the LogicMonitor app be explicitly invited to the channel from which it is performed.

Configure Slash Command

Creates a new Slack integration or edits an existing Slack integration. The Update Integration dialog opens if this command is entered with the name of an existing Slack integration. Otherwise, the Add New Integration dialog opens.

Command: /lm configure [integration name - optional]

Examples:

• /lm configure
• /lm configure Slack Alert Integration

Note: This command should only be used once the initial app installation is fully complete, after the workspace has been linked to your company via creation of the first integration record.

Uninstall Slash Command

Completely uninstalls the LogicMonitor app from the Slack workspace along with all associated Slack integration records for the workspace. See the App Uninstallation section of this support article for more details on uninstalling the LogicMonitor app.

Command: /lm uninstall

Note: This command should only be used once the app installation is fully complete and at least one Slack integration record exists in LogicMonitor.

Troubleshooting

Overall, the error messages returned by Slack and/or LogicMonitor when working with the Slack integration are specific and self explanatory. However, there are a couple that may require action on your end in order to resolve; these are discussed next.

Slack Username Mapping

Error message: Sorry, we couldn’t map your Slack username to a LogicMonitor account and couldn’t complete the requested action. A workaround will be available soon!

Error condition: When receiving requests from Slack (for example, acknowledge an alert or create an integration record), LogicMonitor attempts to authenticate the Slack username. If authentication cannot be made and the above error message is returned.

Solution: Contact customer support for guidance. (As the error message implies, LogicMonitor is working on improving the user validation process between Slack and LogicMonitor.)

Insufficient Permissions

Error message: You don’t have permission in LogicMonitor to perform this action. Please contact a LogicMonitor admin to obtain the needed permissions to resolve this issue.

Error condition: The user attempting to perform the action from Slack (for example, acknowledge or SDT an alert), configure an integration), doesn’t have the necessary permissions in LogicMonitor to perform the action.

Solution: Obtain the appropriate LogicMonitor permissions. In order to configure any aspect of a Slack integration, a LogicMonitor user must have manage-level permissions for integrations. In order to acknowledge or SDT alerts from Slack, a user must have acknowledge-level permissions for the resource or website group from which the alert is being triggered. For more information on these permissions, see Roles.

App Uninstallation

The LogicMonitor app can be uninstalled from a workspace via your LogicMonitor portal or via a Slack channel.

Uninstalling from LogicMonitor

A dialog box that warns of imminent app uninstallation will appear when you attempt to delete the only remaining Slack integration record associated with a particular Slack workspace. Confirming the delete action will effectively uninstall the app from the Slack workspace associated with the deleted integration record.

Uninstalling from Slack

The LogicMonitor app can be uninstalled from Slack by entering the slash command /lm uninstall. (See the Slack Slash Commands section of this support article for more information on available slash commands.)

Upon uninstalling from Slack, the app will be deleted from your Slack workspace and all Slack integration records that reside in LogicMonitor that are associated with the workspace will also be deleted. Additionally, any escalation chains, recipient groups and alert rules that exclusively reference these integrations will also be deleted, with the exception of escalation chains configured to deliver Collector down alerts.

Group Chat Tools, such as 37Signals Campfire have been adopted by many companies for communication management. It is straightforward to configure LogicMonitor to deliver alerts to group chat rooms via a Custom HTTP Alert Delivery Method.

A good use of this integration is to both avoid email alert overload, and to increase responsiveness to an alert.  Having alerts sent to Campfire requires:

1. Getting an Authentication Token from Campfire
2. Configuring a Custom HTTP Alert Delivery Method within LogicMonitor
3. Adding the Custom HTTP Alert Delivery Method to an escalation chain

1. Getting an Authentication Token from Campfire

NOTE: We recommend that you make a separate campfire user named LogicMonitor which you will use to log in when generating the authentication token. This user will be the one shown as speaking the alerts into the room, and that user  will not receive the alert in the chatroom unless they refresh the page.

Obtain a Campfire “Auth Token”

Login to Campfire from your web browser.  From your home page click the “My Info” link at the top right.  The token will be on this page.

The only other information that you will need from Campfire is the URL for the room you want to be alerted in, which you can copy directly from your browser while in the relevant room. For example:

https://yourcompany.campfirenow.com/room/570279

That’s all we need from Campfire.  Now on to getting it into LogicMonitor!

2a. Adding your Campfire Auth Token to LogicMonitor

The Auth Token will be be used by a LogicMonitor Custom HTTP Alert Delivery Method to route the alerts into Campfire.  While you could hardcode it directly into the Custom HTTP Alert Delivery Method, it is a better practice to define it as a Property within LogicMonitor, just as you would set other authentication credentials such as an SNMP community or a MySQL password.

The properties we will be setting are:

• campfire_api.pass

This property corresponds to the “Auth Token” gathered earlier from Campfire.

From the “Devices” tab in LogicMonitor, select Manage at the account level (click the company name in the navigation pane) and set the properties:

2b. Creating a Custom HTTP Alert Delivery Method

Add a custom HTTP alert delivery method from Settings | Integrations | Add | Custom HTTP Delivery Method:

For each request, you can select which alert statuses trigger the HTTP request. Requests are sent for new alerts (status: Active), and can also be sent for alert acknowledgements (status: Acknowledged), clears (status: Cleared) and escalations/de-escalations/adding note (status: Escalated).

Note: 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.

The following fields are set:

• HTTP Method: HTTP Post
• URL:  https://yourcompany.campfirenow.com/room/570279/speak.xml  Remember: This is the url from YOUR specific chat room and you need to append /speak.xml to the end
• Username: ##campfire_api.pass##
• Password: (you don’t need a password the authentication token counts as the username and password)
• Alert Data:  <message><body>##ALERTID## ##LEVEL## ##HOST## ##DATASOURCE## ##DATAPOINT##: ##VALUE## ##THRESHOLD## (##ALERTSTATUS##) https://<MY-SITE>.logicmonitor.com/santaba/uiv3/alert_mobile/index.jsp#detail~id=LME254587&type=eventAlert </body></message>
• Data Format: XML Data

3. Configure an Alert Rule and Escalation Chain

The Custom HTTP Alert Delivery Method you just created (“to_Campfire_TechOps” in our example) is now a new alert destination for any user.  For the purpose of Campfire, you will simply want to add one user with this new alert destination to any escalation chain in which you want a message to a Campfire room to be part of the chain.  In the example below, we chose the user Bill.  The only difference in using different users is if a reference is made to the “##ADMIN##” token in the Alert Data.  If that token is present, than the user for which the alert is being generated will be substituted. In this case we are not referencing ##ADMIN##, so any active user will work:

Any alert that hits the “CampfireErrors” escalation chain (following the routing of the defined rules) will now send an alert message to the specified Campfire room (“TechOps: in our example)

Puppet is IT automation software that enables system administrators to manage provisioning and configuration of their infrastructure.  LogicMonitor’s Puppet module allows your Puppet infrastructure code to manage your LogicMonitor account as well.

Notes:

• This module is only compatible with linux servers. Windows compatibility may be added in future releases.

Module Overview

LogicMonitor’s Puppet module defines 5 classes and 4 custom resource types:

Classes

• logicmonitor: Handles setting the credentials needed to interact with the LogicMonitor API
• logicmonitor::config: Provides the default credentials to the logicmonitor class
• logicmonitor::master: Collects the exported lm_host resources and lm_hostgroup resources. Communicates with the LogicMonitor API
• logicmonitor::collector: Handles LogicMonitor collector management for the device. Declares an instances of lm_collector and lm_installer resources
• logicmonitor:host: Declares an exported lm_host resource

Resource Types

• lm_hostgroup: Defines the behavior of the handling of LogicMonitor device groups. We recommend using exported resources
• lm_host: Defines the handling behavior of LogicMonitor devices. Used only within the logicmonitor::host class
• lm_collector: Defines the handling behavior of LogicMonitor collectors. Used only with the logicmonitor::collector class
• lm_installer: Defines the handling behavior of LogicMonitor collector binary installers. Used only within the logicmonitor::collector class

Requirements

In order to use LogicMonitor’s Puppet Module, you’ll need to make sure you have the following:

1. Ruby 1.8.7 or 1.9.3
2. Puppet 3.X
3. JSON Ruby gem (included by default in Ruby 1.9.3)
4. Store Configs in Puppet

Store configs are required for the exported resources used by this module. To enable store configs, add storeconfigs = true to the [master] section of your puppet.conf file, like so:

# /etc/puppet/puppet.conf
[master]
storeconfigs = true

Once enabled, Puppet will need a database to store the config info. Puppet recommends PuppetDB, although other database solutions are available.

Device Configuration

As with your other LogicMonitor devices, the collector will need to communicate with the device in order to gather data.  Make sure the correct properties and authentication protocols are configured as part of the Puppet installation.

Installing the LogicMonitor Puppet Module

You can install LogicMonitor’s original Puppet Module via GitHub:

$ cd /etc/puppet/modules
$ git clone git: //github.com/logicmonitor/logicmonitor-puppet.git
$ mv logicmonitor-puppet logicmonitor

Getting Started

Once you’ve installed LogicMonitor’s Puppet Module, you can get started using the following sections:

Create a new user for Puppet

We recommend you create a new user with administrator privileges in your Logic Monitor account that you will use exclusively within your Puppet nodes to track changes made by Puppet in the audit log.

Configuration

• Class: logicmonitor (modules/logicmonitor/manifests/init.pp)

This is the top level class for the LogicMonitor module. It’s purpose is to set the LogicMonitor credentials to be used by all the child classes. Explicit declaration of this class will override the default credentials set in the logicmonitor::config class. This class does not need to be explicitly declared.

• Class: logicmonitor::config (modules/logicmonitor/manifests/config.pp)

This class is used to set the default LogicMonitor account credentials for your Puppet environment. This class does not need to be explicitly declared.

Parameters: None

• Class: logicmonitor::master (modules/logicmonitor/manifests/master.pp)

The master class enables communication between the LogicMonitor module and your LogicMonitor account for group and device management. This class acts as the collector for the lm_host and lm_hostgroup exported resources. This prevents conflicts and provides a single point of contact for communicating with the LogicMonitor API. This class must be explicitly declared on a single device. NOTE: All devices with the logicmonitor::collector and logicmonitor::master classes will need to be able to make outgoing http(s) requests.

Parameters: none

• Class: logicmonitor::collector (modules/logicmonitor/manifests/collector.pp)

This class manages the creation, download and installation of a LogicMonitor collector on the specified node.

• The only absolute requirement for a collector node is that is is Linux and can make an outgoing SSL connection over port 443
• We suggest the collector system have at least 1G of RAM
• If the collector will be collecting data for more than 100 hosts, it is a good idea to dedicate a machine to it

Examples

To add collector to a node:

include logicmonitor::collector

If you want to specify a specific location where you’d like to install a collector:

class{"logicmonitor::collector":
install_dir => $install_dir,
}

Class: logicmonitor::host (modules/logicmonitor/manifests/host.pp)

This class is used to add devices to your LogicMonitor account. Devices which are managed through Puppet will have any properties not specified in the device definition removed.

Examples

class {'logicmonitor::host':
        collector => "qa1.domain.com",
        hostname => "10.171.117.9",
        groups => ["/Puppetlabs", "/Puppetlabs/Puppetdb"],
        properties => {"snmp.community" => "Puppetlabs"},
        description => "This device hosts the PuppetDB instance for this deployment",
      }

class {'logicmonitor::host':
        collector => $fqdn,
        displayname => "MySQL Production Host 1",
        groups => ["/Puppet", "/production", "/mysql"],
        properties => {"mysql.port" => 1234},
      }

Adding a Device Group:

Type: Lm_hostgroup Device groups should be added using an exported resource to prevent conflits. It is recommend device groups are added from the same node where the logicmonitor::master class is included. Devices can be included in zero, one, or many device groups.  Device groups are used to organize how your LogicMonitor Devices are displayed and managed and do not require a collector . Properties set at the device group level will be inherited by any devices added to the group.

To add and edit properties of device groups use lm_hostgroup, example below.

@@lm_hostgroup{"/parent/child/grandchild/greatgrandchild":
  ensure => present,
  alertenable => true,
  properties => {"snmp.community" => "n3wc0mm", "mysql.port" => 9999,"fake.pass" => "12345"},
  description => "This is the description that shows up in the yellow box from hover in your LM account",
}

For more examples of the module in action, check out logicmonitor-puppet/README.md.

LogicMonitor’s Custom Email Delivery integration allows you to format alert notification emails in a more consistent format, without explanatory text. Custom email delivery enables you to define the precise format of the email subject and body, so that it can be easily parsed by the recipient system.

Emails generated by this alert delivery method are not actionable. You cannot reply to them in order to acknowledge, SDT, or escalate an alert. Additionally, only new alerts and cleared statuses will trigger notifications to this type of integration.

Setting Up a Custom Email Delivery Integration

You can add a new Custom Email Delivery integration from Settings | Integrations. Click the Add button and then click Custom Email Delivery to open the Add Custom Email Delivery Integration configuration dialog, shown (and discussed) next.

Note: Once created, your Custom Email Delivery integration 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 in order for alert notifications to be delivered using this integration method.

Name

The name of the integration.

Description

The description for the integration.

From Address

This field displays the email address from which your custom email notifications will be sent. It is auto-generated by LogicMonitor based on the parameters shown and is the same sender address used for all LogicMonitor alert notifications.

Destination Addresses

The email address(es) to which alert notifications will be sent. You can separate multiple addresses with commas.

Use the ##ADMIN.EMAIL## token to dynamically reference the email address associated with the user in the escalation chain to which the alert is routed.

Subject and Email Body

Both the subject and body of the alert notification email support tokens. You can use any of the following tokens in these fields:

• LogicModule-specific alert message tokens, as listed in Tokens Available in LogicModule Alert Messages.
• ##ADMIN##. The user the alert was escalated to.
• ##MESSAGE##. The rendered text of the alert message. This token will also pass all relevant acked information (e.g. the user that acknowledged the alert, ack comments, etc.).
• ##ALERTTYPE##. The type of alert (i.e. alert, eventAlert, batchJobAlert, hostClusterAlert, websiteAlert, agentDownAlert, agentFailoverAlert, agentFailBackAlert, alertThrottledAlert).
• ##EXTERNALTICKETID##. The ticket ID generated by the external ticketing system.

Test Alert Delivery

This button sends a test alert and provides the response, allowing you to test whether the integration is configured correctly.

Custom HTTP Alert Delivery Methods (i.e. 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 (i.e. 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 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.

Custom HTTP Alert Delivery

You can add and/or configure existing custom HTTP alert delivery from Settings | Integrations. Select Add and then Custom HTTP Delivery:

Name

The name of the custom HTTP alert delivery template.

Description

The description for the custom HTTP alert delivery template.

Will requests be sent to different URLs?

Use the Same URL and data to notify on various alert activity

This option will send HTTP requests for alert acknowledgements, clears, and/or escalations/de-escalations 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

This option will send HTTP requests to different URLs based on the alert status.

Which alert statuses should trigger an HTTP request?

Select which alert statuses should trigger an HTTP request. Requests will be sent for new alerts, and can additionally be sent for alert acknowledgements, clears and escalations/de-escalations.

• New Alerts: This state is for new, active alerts is required.
• Acknowledged: This state is intended to process previously generated alerts that are acknowledged.
• Cleared: Once an active alert satisfies the alert threshold that triggered it, this state will control the HTTP request made.
• Escalated/De-escalated: Reserved to handle 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.

For each request, you can select which alert statuses trigger the HTTP request. Requests are sent for new alerts (status: Active), and can also be sent for alert acknowledgements (status: Acknowledged), clears status: Cleared) and escalations/de-escalations/adding note (status: Escalated).

HTTP Method

The HTTP method to be used for the HTTP request. Options are POST and GET.

Use Custom Headers

Selecting this box will display new configuration fields for adding the header key and header value.

Custom headers are used to define your authentication credentials.

For the Content-Type header key, you can add charset value as null or charset 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.

URL

The URL to which the HTTP request to the specific URL, if required.

Password

The password associated with the specified username.

Alert Data

Raw

An HTTP request will deliver a custom alert notification message using a raw data format. Choose the message to be formatted in: Form Data, JSON, Plain Text, URL-Encoded Form Data or XML.

Key/Value Pairs

An HTTP request will deliver a custom alert notification message formatted using Key/Value pairs. With this option, the message’s format will be restricted to JSON. You can add one or more JSON key/value pairs to be included in the alert notification message.

You can use tokens in this field.

HTTP Response Format

If LogicMonitor is to use the ID provided in the response, select the format the response will be in. Choose from JSON, Regular Expression, No Interpretation and XM

Tokens Available

The following tokens are available:

• LogicModule-specific alert message tokens, as listed in Tokens Available in LogicModule Alert Messages.
• ##ADMIN##. The user the alert was escalated to.
• ## MESSAGE##. The rendered text of the alert message. This token will also pass all relevant acked information (e.g. the user that acknowledged the alert, ack comments, etc.).
• ##ALERTTYPE##. The type of alert (i.e. alert, eventAlert, batchJobAlert, hostClusterAlert, websiteAlert, agentDownAlert, agentFailoverAlert, agentFailBackAlert, alertThrottledAlert).
• ##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.

Include an ID provided in HTTP response when updating alert status

Check this option if you would like LogicMonitor to find the ID (e.g. ticket ID) returned in response to the HTTP request that is associated with a new alert.

LogicMonitor will use this ID in any subsequent requests for alert acknowledgements, clears, and escalations/de-escalations.

Test Alert Delivery

This option sends a test alert and provides the response, enabling you to test whether you’ve configured the integration correctly.

Example

In the above example, a custom HTTP delivery method is used to integrate LogicMonitor with the LogicMonitor Certification Platform, where a custom datasource monitors user scores. When a user fails the exam their course data is reset. When the alert clears, the user will be un-enrolled from the exam and must purchase anther attempt.

Your LogicMonitor account comes pre-configured to integrate with Autotask. The out-of-the-box integration enables LogicMonitor to open, update, and close Autotask tickets based on LogicMonitor alerts.

As discussed in the following sections, you’ll need to perform the following primary steps in order to configure the Autotask integration:

1. Create an Autotask API-only user account that LogicMonitor will use to create, update, and close tickets in Autotask
2. Configure the Autotask integration from within LogicMonitor
3. Create an alert rule and escalation chain to route alert data to Autotask

Create an Autotask User Account

To create, update, and close tickets in Autotask, LogicMonitor needs to access Autotask with an authorized user account. Autotask requires that this user be an API user with an API-only security level assigned to it.

As best practice, it is recommended that you create a copy of Autotask’s built-in “API User (System) (API-only)” security level for assignment to the LogicMonitor API user account. This allows you to significantly slim down the account’s permissions to just those required for proper functioning of the Autotask integration.

Minimum Permissions

When creating a more restrictive copy of the “API User (System) (API-only)” security level, name it something similar to “LogicMonitor API User” and leave the following minimum permissions in place:

• Section: CRM
  • Account & Contact Access
    • Select “All” for all dropdowns in the Permission column.
  • Object Permissions
    • For Configuration Items & Subscriptions, select “All” from the View column’s dropdown; all other areas and permission levels should have a value of “None”.
  • Other Permissions
    • Check the Display ALL accounts in account pick lists and data selectors option.
  • Dashboard Display
    • Select “All” from the dropdown.
• Section: SERVICE DESK
  • Object permissions
    • For Tickets, select “All” from the View and Delete columns’ dropdowns; select “Yes” from the Add and Edit columns’ dropdowns.
    • For Ticket Notes, select “All” from the Edit and Delete columns’ dropdowns.
  • Other Permissions
    • Check all options under this heading with the exception of the Can access Dispatch Calendar option.
• Section: ADMIN
  • Feature Access – check the following options:
    • Application-Wide (Shared) Features (Full Access)
    • Your Organization
    • Accounts & Contacts
    • Service Desk (Tickets)
  • Section: WEB SERVICES API
    • Check the Can login to Web Services API option

For more information, see Autotask’s Autotask PSA: API User security level documentation.

Configure the Autotask Integration

To configure the Autotask integration, select Settings > Integrations > Add > Autotask. From the Add Autotask Integration dialog that appears, you’ll configure three categories of settings, discussed in the following sections.

Autotask Authentication Settings

The information provided in the Autotask Authentication area of the dialog provides LogicMonitor with access to Autotask. Upon entering authorization information, you will need to validate authorization in order to proceed with the configurations.

Zone

In the Zone field, enter your Autotask WSDL zone (typically can be found in your Autotask URL). This must be a numeric value.

Username and Password

In the Username and Password fields, enter the username and password that correspond with the Autotask API-only user created in the previous Create an Autotask User Account section of this support article.

Authenticate

Click the Authenticate button to authenticate access to Autotask using the zone, username, and password provided. If authentication is successful, the Autotask Settings section, discussed next, will dynamically appear.

Autotask Settings

The information provided in the Autotask Settings area of the dialog determines how LogicMonitor will create, update, and close tickets in Autotask.

Account

From the Account field’s dropdown menu, select the Autotask account that tickets should be created under.

If you’d like to create, update and delete tickets across multiple Autotask accounts, you can do that by setting the autotask.accountid property on the resource whose alerts should trigger the creation (or editing) of Autotask incidents under another account. The value of this property must be the numeric ID associated with the account, not the company name.

When an alert is triggered and routed to the Autotask integration, LogicMonitor will first check to see if this property exists for the resource associated with the alert. If it does exist, its value will be used instead of the value set in this dialog.

Due Date

In the Due Date field, enter an integer that represents the number of days after the LogicMonitor alert start time that the Autotask ticket’s due date should be automatically set to.

Queue Id

From the Queue Id field’s dropdown menu, select the Autotask queue in which new tickets should be created.

Autotask Priorities

In the Autotask priorities area, map LogicMonitor’s alert severity levels to Autotask’s ticket priority levels to determine what priority Autotask tickets will be assigned upon creation. LogicMonitor has three alert severity levels whereas Autotask has four priority levels. By default, Autotask’s “High” priority level is excluded from mapping, but you can override this if necessary.

Autotask Status

In the Autotask status area, map LogicMonitor’s alert statuses to Autotask’s ticket statuses. LogicMonitor will use this mapping to determine what status Autotask tickets will be assigned when a new Autotask ticket is created based upon a new LogicMonitor alert, as well as how its status will change when the LogicMonitor alert is acknowledged, escalated/de-escalated, or cleared.

Generate Delivery Options

After completing the configurations in the Autotask Settings section, click the Generate Delivery Options button to generate the default set of HTTP requests that are responsible for creating and updating Autotask tickets. As discussed next, the HTTP Delivery section will dynamically appear.

HTTP Delivery Settings

The information provided in the HTTP Delivery area of the dialog determines how LogicMonitor will create, update, and close tickets in Autotask.

Will requests be sent to different URLs?

Select whether HTTP requests for alert acknowledgments, clears and escalations/de-escalations should be sent to the same URL that HTTP requests for new alerts should be sent to, or with different alert data in the request. If ‘Use the same URL and data to notify on various alert activity’ is selected, all HTTP requests will be sent to the same URL (you can choose what alert updates prompt an HTTP request) and the same alert data format will be used each time. If ‘Use different URL or data format to notify on various alert activity’ is selected, you can map out which alert status updates should trigger an HTTP request to which URLs and how the alert data should be formatted for each request. The configuration fields for each HTTP request are the same for both options.

By default, LogicMonitor will pre-populate four different requests, one for each of the following events:

• New alerts (Active)
• Acknowledged alerts (Acknowledged)
• Cleared alerts (Cleared)
• Escalated alerts (Escalated)

For each request, you can select which alert statuses trigger the HTTP request. Requests are sent for new alerts (status: Active), and can also be sent for alert acknowledgements (status: Acknowledged), clears (status: Cleared) and escalations/de-escalations/adding note (status: Escalated)

HTTP Method

The HTTP method for Autotask integrations is restricted to POST.

URL

The URL that the HTTP request should be made to. This field is auto-populated based on information you’ve provided.

Alert Data

The custom formatted alert data to be sent in the HTTP POST request (used to create, update and close Autotask tickets). This field will be auto-populated for you, and is restricted to XML raw data. If desired, you can customize the alert data field using tokens.

Tokens Available

The following tokens are available:

• LogicModule-specific alert message tokens, as listed in Tokens Available in LogicModule Alert Messages.
• ##ADMIN##. The user the alert was escalated to.
• ##MESSAGE##. The rendered text of the alert message. This token will also pass all relevant acked information (e.g. the user that acknowledged the alert, ack comments, etc.).
• ##ALERTTYPE##. The type of alert (i.e. alert, eventAlert, batchJobAlert, hostClusterAlert, websiteAlert, agentDownAlert, agentFailoverAlert, agentFailBackAlert, alertThrottledAlert).
• ##EXTERNALTICKETID##. The Autotask ticket ID.

Include an ID provided in HTTP response when updating alert status

Check this option if you’d like LogicMonitor to find the Autotask ticket ID returned in the response to the HTTP request associated with a new alert, and use the ID in any subsequent requests for alert acknowledgements, clears and escalations/de-escalations. By default, this option will be selected.

HTTP Response Format

If LogicMonitor is to use the ID provided in the response, select the format the response will be in. By default, this option is set to XML and the Xpath for the Autotask ticket ID is auto-populated

Test Alert Delivery

This option sends a test alert and provides the response, enabling you to test whether you’ve configured the integration correctly.

Creating an Alert Rule and Escalation Chain

Alert rules and escalation chains are used to deliver alert data to your Autotask integration. Specifically, when a triggered alert matches the alert rule and is routed to the escalation chain with the Autotask integration, a ticket will be created in your Autotask account. The ticket can then be updated and/or closed when the alert is acknowledged, escalated, de-escalated and/or cleared. For more information, see Alert Rules and Escalation Chains.