LM / ServiceNow Integration
I'm working on some API commands for ServiceNow from LogicMonitor and am trying to see if there's a way to see further information from the return payload from ServiceNow when a ticket is generated via the integration.
In particular, I'm trying to capture the sys_id field from ServiceNow so that I can use this to access the ticket in an escalation step using a custom HTTPS API command. I can see the payload includes sys_id in the integration logs, and indeed LogicMonitor uses it to generate the link to the ticket on the alert screens.
Does anyone know if there's a token or such that can be used to access this info, or if there would be a way of storing it for access?
Jason Clemons
Posted 1 year ago·Last reply 1 year ago
14 comments
Dave Lee
·1 year agoLogicMonitor 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
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
Jason Clemons
OP1 year agoThe 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.
Dave Lee
·1 year agoWe 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.
Jason Clemons
OP1 year agoThat's actually an interesting idea, I'll see what I can do along those lines. I'll need to sharpen up on my LM API skills, to be sure :D
Dave Lee
·1 year agoI can't take credit for that idea, it was mentioned by a chap in LM Pro Services. My "go to" for automation tends to be stuff running Azure Functions, but using a data source to run this stuff is an interesting approach indeed!
Jason Clemons
OP1 year agoI will say, I've been digging since I posted earlier and while it looks like /alert/alerts should return "alertExternalTicketUrl", I don't ever get that response when pulling the alerts list. Was thinking that if that were possible, I could strip out the sys_id that is at the end of the URL for SNow.
Dave Lee
·1 year agoAwesome! I hadn't even noticed that the sysid was at the end of the URL it gives you, that's really useful.
Jason Clemons
OP1 year agoJust to leave this here for anyone else who may find they want the sys_id from ServiceNow, I've written a standalone powershell script that I'm going to integrate into a datasource, based on Dave's suggestion above.
Jason Clemons
OP1 year agoAnd 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!
Jason Clemons
OP1 year agoI'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 Lee
·1 year agoAs 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 Clemons
OP1 year agoWell, 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 Lee
·1 year agoYou'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.
Jason Clemons
OP1 year agoWell, I've successfully developed out an EventSource that will write an event that has both the internal alert ID and the sys_id for Servicenow in the message, however, it's repeating the alert every minute. I think I need to find a way to check the current events to see if the same payload exists and exit.