Neophyte
AdvisorLogicMonitor 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
NeophyteThe idea here ultimately is to have LM trigger an escalation 1 hour after an alert/SNow Incident is created which will add an Incident Task to the Incident. I have the SNow API string developed out to do so but need the sys_id field to attach it to the correct Incident. So, the custom HTTP integration is to send that API call to the same ServiceNow instance.
AdvisorWe have a similar issue with trying to do an integration with BMC Remedy. Although we can get back an Incident ID on the initial Incident creation, sending updates requires us to use a different value (a Remedy internal ID for the Incident, much like a sysid in Service Now). So you have to make an API call to get that value first, then use it in your update calls - it seems some updates need multiple calls as well.
Long story short, we can't do this natively, so we're developing our own automation to deal with it. LM will send to our automation platform via Custom HTTP Integration, our platform will deal with the translation.
I did recently speak to someone in LM PS who said they had done something similar using a data source. We didn't go into details, but I suppose that runs a "collection" script that queries the LM API for new alerts periodically and then makes all the API calls required.
Interesting workaround, perhaps that could work for you? Maybe have a data source that queries the LM API for alerts that are 1 hour old that have a Service Now ticket ID in them, then make the API calls you require to add an Incident Task? I think that could work.
NeophyteAnd of course, I figured out the issue there, I had forgotten the x-version:3 header. Once I added that, I got the URL, so I should be able to strip it and add as a datapoint.
Thanks for the help, Dave!
NeophyteI'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)
AdvisorAs 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.
NeophyteWell, 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.
