Forum Discussion
LogicMonitor does store the Incident number and also seems to store a link to the Incident, which includes the sysid. If you query the LogicMonitor API for the information about an alert, you will see something like the following in the alertExternalTicketUrl column
"alertExternalTicketUrl": {
"servicenowIncidentLinks": {
"INC5132740": "https://XXXXX.service-now.com/now/nav/ui/classic/params/target/incident.do%3Fsys_id%3Db05f563a1b962a10438ced79b04bcb81"
}
},
I don't think you would be able to access this from a token so you could pass it to a custom HTTP integration though.
Depending on what system you are hitting with your custom HTTPS integration, maybe you could pass it the alert ID, then maybe get your external system to query the LM API for the details of the alert, then parse the sysId from the alertExternalTicketUrl column?
Then again, if you can have the external system do that, you could instead just have it query Service Now to find the Incident based on the AlertId that will be stored against it.
If it helps, here's some python code I've pulled out of a bigger project, I think it'll work standalone
import requests
import json
import hashlib
import base64
import time
import hmac
instance = "xxxxx" # name of your ServiceNow instance
username = "xxxxx" # your ServiceNow username
password = "xxxxx" # your ServiceNow password
alertid = "xxxxxxxx" # LogicMonitor alert ID to search for
# Set up the API endpoint for incident search
uri = f"https://{instance}.service-now.com/api/now/table/incident"
# Set up authentication
auth_header = base64.b64encode(f"{username}:{password}".encode()).decode()
headers = {
"Accept": "application/json",
"Content-Type": "application/json",
"Authorization": f"Basic {auth_header}"
}
# Query parameters - search for the specific LogicMonitor alert ID and exclude certain incident states
# 7 = Resolved, 6 = Closed, 14 = Pending Closure
query_params = {
"sysparm_query": "x_lomo_lmint_logicmonitor_alert_id=" + alertid + "^incident_stateNOT IN14,6,7",
"sysparm_fields": "number,short_description,sys_id,state,priority,assigned_to,logicmonitor_alert_id",
"sysparm_limit": "1" # Limit to 1 result since we're looking for a specific record
}
try:
# Make the GET request to ServiceNow
response = requests.get(
uri,
headers=headers,
params=query_params
)
# Check if the request was successful
if response.status_code == 200:
print(f"Response: {response.text}")
result = response.json()
if result['result']:
logging.info("Incident found:")
logging.info(json.dumps(result['result'][0], indent=2))
return result['result'][0]
else:
print(f"No incident found with logicmonitor_alert_id={alertid}")
return None
else:
logging.error(f"Error: {response.status_code} - {response.text}")
return None
except Exception as e:
logging.error(f"Exception occurred: {str(e)}")
return None
I've gotten close, to the point that I can add a propertysource that will run a groovyscript to write an auto property with the sys_id at the time the propertysource is added. But I don't see a way of having it automatically update on a schedule.
I'm now thinking that an EventSource might be the best way of going after this, but I'll need to dig into what it expects as a return value and how to modify the groovyscript to fit.
(the groovyscript actually does a https API call back to LM since I couldn't figure any other way of accessing the API from the groovyscript in the platform, which I find odd)
- Dave_Lee27 days ago
Advisor
As I understand it, you don't really have any control over when a Property Source runs. It is a convenient way to get a property onto a device though...
Do you need to store the sysid against the device? Just thinking that might get complicated, especially if a device has more than one active alert for whatever reason.
You could create a dummy device in LogicMonitor, make sure the device is assigned to a collector, put some LM API and Service Now API credentials in properties on that device. This dummy device just serves as something to associate a custom data source off so you can get code to run on a collector.
Then write a data source that applies just to that dummy object. Have it query the LM API for all alerts created between 1 hour and 2 hours ago and their sysids. Then loop through those alerts and call the Service Now API to create Incident Tasks you need. You could even use the Collector Cache to store the alerts IDs that you've already processed so you don't create duplicate Incident Tasks.
You could have the data source return just a single value 0=good, 1=there was an error. Then do an alert on that so you know if your script is failing.
- Jason_Clemons26 days ago
Neophyte
Well, I started looking at PropertySouce since, unless I'm mistaken, DataSource requires a numeric, yeah? I couldn't really wrap my head around setting up an EventSource which I suspect would be technically most appropriate though.
- Dave_Lee24 days ago
Advisor
You're right, a data source can only be used to return a numeric to LogicMonitor itself, but essentially a script based data source just runs whatever code you put in it and should then return some numeric values to logicmonitor for the metrics it is designed to capture.
Admittedly, it's a bit of a weird way to use a data source but, given you can have it run whatever code you like, you could write code that pulls Alerts from the LM API and happened in the last run then have it call the Service Now API to raise Incident Tasks. It could then return a value to LogicMonitor to confirm it ran successfully or not.