Overview

LM Service Insight enables you to create and monitor at the service level by creating logical “services” in LogicMonitor. The release of LM Service Insight coincided with the new umbrella term “resources”. Resources include devices, services, cloud resources, kubernetes resources (e.g. pods, nodes, services, deployments), and new types will be added as we move forwards. To ensure backwards compatibility, we did not rename our API resources. As such, API management of services is actually done via the devices resource, where a service is a type of device (and where the devices API endpoint really can be thought of as the resources API endpoint). This means that you can programmatically manage (add, create, update, delete) services with the devices API resource. This document provides examples and additional information for doing so.

Creating a service in the UI comprises of two parts:

1. Grouping together devices and instances to create the service
2. Creating a DataSource that is configured to aggregate data across service members

With the API, these two steps would be:

1. Add a device of type 6 (POST /device/devices)
2. Add a DataSource

You can easily add the service itself via API and have DataSources that were created via UI or imported via API and that automatically apply to the service to aggregate data.

Details & Required Fields

Aside from specifying a device type of 6 to create a service, there are a number of other requirements. Most importantly, the service members are specified via property. Below is a table that shows all required fields for creating a service with the /device/devices endpoint:

In addition to the required fields above, there are a number of optional fields you can include when creating your service (such as membership re-evaluation rate):

The following example script adds a Service named ‘Reporting Service’ that groups all devices with the property ‘kubernetes.label.app=argus’. The member re-evaluation interval is set to 30 minutes:

#!/usr/bin/env python

import requests
import json
import hashlib
import base64
import time
import hmac

#Account Info
AccessId ='xxxxx'
AccessKey ='yyyy'
Company = 'ACCOUNT'

#Request Info
httpVerb ='POST'
resourcePath = '/device/devices'
queryParams ='?v=2'
data = '{"name":"testAPIService","displayName":"Reporting Service","deviceType":6,"preferredCollectorId":-4,"customProperties":[{"name":"predef.bizService.evalMembersInterval","value":"30"},{"name":"predef.bizservice.members","value":"{\\"device\\":[{\\"deviceGroupFullPath\\":\\"*\\",\\"deviceDisplayName\\":\\"*\\",\\"deviceProperties\\":[{\\"name\\":\\"kubernetes.label.app\\",\\"value\\":\\"argus\\"}]}],\\"instance\\":[]}"}]}'

#Construct URL
url = 'https://'+ Company +'.logicmonitor.com/santaba/rest' + resourcePath +queryParams

#Get current time in milliseconds
epoch =str(int(time.time() * 1000))

#Concatenate Request details
requestVars = httpVerb + epoch + data + resourcePath

#Construct signature
hmac = hmac.new(AccessKey.encode(),msg=requestVars.encode(),digestmod=hashlib.sha256).hexdigest()
signature = base64.b64encode(hmac.encode())

#Construct headers
auth = 'LMv1 ' + AccessId + ':' + signature.decode() + ':' + epoch
headers = {'Content-Type':'application/json','Authorization':auth}

#Make request
response = requests.post(url, data=data, headers=headers)

#Print status and body of response
print ('Response Status:',response.status_code)
parsed = json.loads(response.content)
print(json.dumps(parsed, indent=4))

Overview

v2 of LogicMonitor’s REST API will allow you to programmatically query and manage your LogicMonitor resources: dashboards, devices, reports, websites, alerts, collectors, datasources, SDTs and more. Comprehensive documentation for available resources and methods can be found in our Swagger documentation. Additional information can be found in the sections below.

Note: For general information about LogicMonitor’s REST API, including authentication, rate limiting, and versioning information, see this page. Requests will default to v1 of the API, and you can make v2 requests by including a ‘?v=2’ query parameter or by including a ‘X-Version:2’ header.

Changes in REST API v2

v2 of LogicMonitor’s REST API features many differences (including non-backwards compatible ones) from v1. The following sections highlight the major differences, but please review v2 methods and resources for more details.

Status Codes

In v1 of the API, there were two status codes for a response: HTTP status code (almost always 200), and a different LM status code in the response body. With v2, we’re returning one HTTP status code, and we’ve considerably narrowed the list of possible status codes that will be returned. This change was made to ensure that response codes are as meaningful and actionable as possible.

Response Body Structure

In v1 of the API, successful responses included ‘status’, ‘errmsg’, and ‘data’ objects at the top level of the response. With v2, since the HTTP status now matches the LM status, the contents of ‘data’ will be returned at the top level for a successful response. A non-successful response will include error message fields. Note that this does mean that scripts written for v1 of the API and configured to parse API response should be adjusted to reflect this.

Here is an example of a before and after response:

HTTP 200 
Response Body:
{ 
"status":200, 
"errmsg":"OK", 
"data": { 
     "id":34, 
     "name":"Prod Server 1" 
 } 
}

HTTP 200
Response Body:
{
     "id":34,
     "name":"Prod Server 1"
}

No Basic Authentication Support

We’ve removed support for basic authentication with v2 of the API. We did this to encourage more use of API tokens for authentication, as there are many additional benefits (separation of UI / API access, audit log entries, more secure).

Support for PATCH

v2 includes support for HTTP PATCH for most resources. You may find this useful for updating just one field of a resource, instead of having to use PUT to update the entire resource (all fields).  You can determine whether PATCH is supported for a given resource by checking the Swagger documentation.

Filter Syntax

Filter query parameter values with special characters require encoding. Specifically:

• Filter query parameter values with special character "+" must be encoded twice.

  For example, the parameter value in this request GET /device/devices?filter=name:"Prod+Server" should be encoded twice for a result of: "Prod%252BServer"

• Filter query parameter values with special characters EXCEPT "+" (&, -, and so on) must be encoded once.

  For example, the parameter value in this request GET /device/devices?filter=name:"Prod&Server" should be encoded once for a result of: "Prod%26Server"

Supported Status Codes

When an unsuccessful request is made, the response body will contain an ‘errorCode’ field with one of the following codes:

Examples

GET /device/devices?v=2&fields=name,id&size=2
HTTP 200 
Response Body:
{
"total": 222,
"items": [
{
"id": 3,
"name": "ilo-mx233700hu.usa.lab"
},
{
"id": 5,
"name": "idrac-r610.csc.lab"
}
],
"searchId": null,
"isMin": false
}

GET /device/devices?v=2&fields=name,id&size=2 
HTTP 404 
Response Body:
{
"errorMessage": "Authentication failed",
"errorCode": 1401,
"errorDetail": null
}