SDTing via API, one source work the other does not
So I've been working on an LM/Jira JSM integration lately.. the native functions did not work for us. And to be quite honest I cannot remember the details but suffice to say that I have a working Custom HTTP Delivery with three URLs for Active, ACK, and Clear alert functions.
Now the goal is an automation action on the Jira side to SDT a specific host. So I began by building and testing the call in Postman. Works like a champ.. I can add a DeviceSDT, with a comment using the deviceDisplayName for a period of 1 hour. Exactly what I want in Jira.
Build out the automation rule, it's a manual action with no user input. It should add a DeviceSDT to a variable {{deviceHostname}} with variables that are defining epoch time in MS for {{now}}, and an endDateTime of 1 hour.. again in epoch MS format.
I test it and nothing happens. Jira reports back an HTTP400. Odd.. so I run the same thing in Postman and it works. Ok remove the variables and replace them with static content, mirroring exactly whats in the Postman payload. Still, 400 error.
Stumble across https://webhook.site (which is fabulous for this sort of thing BTW) Nope.. the call/payload from Jira is 100% identical to Postman. Same Bearer token, and mostly the same headers; content-type, accept-encoding, Accept, Connection and User-Agent. Postman does add a couple that are unique to it but I have not found any doc on what (if any) headers other than Authorization, are required for this SDT call.
So does anyone here have any suggestions? I do have a case open with LM support as well as Atlassian.
Thanks!
Skeer
OP2 years agoAs a test I removed the dbl-quotes, 'Invalid filter'.. same as what Postman says if I do the same.
Skeer
OP2 years agoI was kinda hoping someone would offer a suggestion on who to give the Solution to ;)
Also wanted to come back.. I've encountered another small thing that directly related to this. I've added the call I mentioned earlier that gets the deviceId value from ../rest/device/devices?filter=name:"{{var1}}*" except Jira claims :Illegal character in query at index 72
The URL sent is: https://xxxxxx.logicmonitor.com/santaba/rest/device/devices?filter=name~"new-hostaa01.xxxx.net*"
I've sanitized but maintained the number of characters.. Its complaining about the tilde, I tried replacing it with the colon but it generated the same error on the same character.
Exact same call from Postman (like earlier) works. X-Version:3 header in both.
LM User
·2 years agoendoceURIComponent() in javascript. Do that to your query parameter values.
LM User
·2 years agoencodeURIComponent()
We have AI that can paint the mona lisa, but it can't detect spelling errors?
LM User
·2 years agoPostman automatically encodes the values, but your JS might not be doing that. So if it works in postman with the ~, but not in your JS, you need to encode the string that contains the ~ using encodeURIComponent().
Skeer
OP2 years agoHmm so that 'translates' to {{deviceHostname}}* at the destination however it would not work in a Jira 'Send web request' URL with a variable in the url string.
So the var won't get defined but instead passed as-is. I noticed Postman will send that encodes value as readily as the prior (name:"name-here*").
Any chance a filter can be part of the body?
LM User
·2 years agoNo, the filter has to be in the query params. But i don't get why you can't do it. Mind posting your sanitized code?
Skeer
OP2 years agoSo in a Jira automation rule there isn't 'code' in the traditional sense of the word. It's all visual like the application Tines.
This might help: https://imgur.com/a/oK61qK8
So what happens is there's a manual trigger, if the servicename == logicmonitor on the Incident in question then create a var: lmalertid from field 'issue.labels', print that to the audit log. Create a second var: deviceHostname from 'issue.customfield_20574', which is supplied from the ##host## token when the custom http delivery Active rule is triggered from LM.
Next we print that deviceHostname to the audit log, then send the first web request. The URL is https://xxxx.logicmonitor.com/santaba/rest/device/devices?filter=name:"{{deviceHostname}}*". The HTTP method is GET, with no body, and the following headers:
So provided LM sends the ##host## token, which defines the customfield_20574, and the rule can use that field to define {{deviceHostname}} and the URL is correctly formatted then it will throw the value of deviceHostname into the filter and send it.
I have other rules that successfully send these Jira variables in the body.. this is the first one I've tried using them in the URL.
Mike Moniz
·2 years agoTry replacing "~" with "%7E"
Skeer
OP2 years agoTaking this suggestion I replaced the :" with %3A%22 and the trailing " with another %22.
This time the call looks like it might have been sent. I need to add a couple more audit log actions. But it's a solid maybe!
Skeer
OP2 years agoWell shoot, you can't pick more than one solution. The Action in Jira is working now! I can set a 1 hour SDT on a specific device! plus I can remove the 4 steps I had to calculate epoch in milliseconds because duration works. However I do have to add a step to GET the ID integer of the device. Either way though, it's working. Thank you guys!
Skeer
OP2 years agoIt's working from Postman now.. resourceSDT and deviceId were the key. Also you can leave out the epoch fields and just use duration, it worked for me just now.
Skeer
OP2 years agoSo ResourceSDT, I don't see an obvious next field to define which resource.
Looks like, perhaps, you can ignore the epoch time stuff and maybe specify a duration too?
Skeer
OP2 years agoWell, looks like you can no longer add a Device-specific SDT using V3, am I understanding that correctly? There's no 'Device' type anymore, and no fields to specify deviceDisplayName or deviceID.
LM User
·2 years agoSet the type to "ResourceSDT"
In LM "resource" == "device"
Mike Moniz
·2 years agoOne trick that can help is that the portal itself uses the API. So you can set in SDT in the portal and watch the Networking tab of the Browser's developer tools to see the request and parameters. Like here is what I got when doing a 1 hr SDT on a device:
{"deviceId":100,"type":"ResourceSDT","sdtType":"oneTime","startDateTime":1715093520000,"endDateTime":1715097120000,"timezone":"America/New_York","comment":"test"}
P.S. The portal does sometimes use undocumented or functions that are not in the API. But most day-to-day stuff uses the same API.
Skeer
OP2 years agoHa! Yeah I'd think it'd be important to include 'deviceId' in the swagger docs. My main skill set is not developer related so I rarely think about dev tools like that. Good call.
Mike Moniz
·2 years agoYeah, that is very odd that it's missing from Swagger. I also thought that Swagger was auto generated from code so I'm not sure how it can miss it. I've never used it outside of vendor API references so perhaps I'm wrong on that.
LM User
·2 years agoWell, it does say "Response may contain extra fields depending upon the type of SDT being added". The thing to understand about swagger is that it's machine generated based on the source code. And SDTs are weird because the request is different depending on the target of the SDT. Since swagger doesn't know all those variations, it doesn't know to document it. LM should do a better job of enhancing the machine generated documentation with examples and use cases.
That said, i was going to suggest exactly what Mike_Moniz suggested: look at the calls the browser makes. The only caveat to that is that parts of the UI have started to use APIv4, which in most cases is backwards compatible with v3, but not always. Still, if the swagger is incomplete, that's the next best thing.
Skeer
OP2 years agoYup.. but I get the feeling I was using a V1/2 body content. Reading here under SDTs I'm seeing many more possible fields.
LM User
·2 years agoAccording to the swagger for v3, the type fields is actually "sdtType":
Skeer
OP2 years agoI see a slightly different body in the v3 swagger examples. More testing.
Skeer
OP2 years agoHmm so v3 must also have some deviations in the syntax or formatting. Postman complains now after adding 'X-Version:3' with "errorMessage":"invalid type", "errorCode":1400
LM User
·2 years agoDo your headers include a content-type header with application/json as the value?
Skeer
OP2 years agoTesting
Skeer
OP2 years agoNo sir, neither.
LM User
·2 years agoI don't think bearer token is supported with v1/v2 of the API, and if you're not forcing it to use a specific version it defaults to v2. You should force it to v3.
Skeer
OP2 years agoOh yeah.. I'm using a bearer token in both cases.
LM User
·2 years agoAre you forcing v3 of the API using either the X-Version header or the v query parameter?
LM User
·2 years agoWell, it depends on whether you're using an API id/key or a bearer token. If you're using api id/key, then you have to generate a signature based on the verb, endpoint, current time, and payload (if any). If you're not doing that, it might be why jira is getting the 400.
If you're using a bearer token, it's much simpler. However, they're newer and not many have started using them.
Skeer
OP2 years agoCrap sorry again.. no the 400 is a 'Bad Request'. So it sounds like improper formatting, incorrect field names/values. But I just compared again to a webhooks.sites and it's being sent accurate info.
Teh raw content is (slightly sanitized):
{ "type": "DeviceSDT", "sdtType": 1, "comment": "Device SDT'd by Ben Hart", "deviceDisplayName": "lbextd01.domain.net", "startDateTime": 1715091972832, "endDateTime": 1715095572832 }
LM User
·2 years agoRight, but even with a 400, you might be getting back a response detailing why it is bad. 400 includes authentication issues, like not generating the signature properly or using an old signature.
Skeer
OP2 years agoSorry, that was sarcasm above. lol. I was trying to be funny, but seriously no I have no idea about any script or sig needed.
Skeer
OP2 years ago? What is this signature thing you speak of? I don;t have/am not using a pre-request script in Postman. Sounds like there might be a part of this I missed..
Skeer
OP2 years agoYessir.. MS in postman and Jira. When I say I tested them identically I meant like identical twins sort of identical :)
LM User
·2 years agoAlright, alright, cool. Just checking the obvious things. When you get back the 400, does the body tell you what the error is? Also, in postman, you have the pre-request script, I assume in Jira you're implementing a similar script to generate the signature at runtime?
LM User
·2 years agoIs Jira putting the sdt time in milliseconds or seconds? LM won't take seconds.