Seeing Failed To Parse ServiceNow Integration
We are sometimes seeing “-2” as the ##EXTERNALTICKETID## when sending alerts to ServiceNow. When this happens and the alert clears it is not auto-closing the ticket in SNOW. Has anyone seen this or have any idea how to fix this. Seems when there is an event where multiple alerts generate and send to SNOW at once this happens.395Views22likes13CommentsLogic Monitor service now integration issue
hi, i have followed the documentation for setting up logic monitor with service now but when i test the alert delivery from the alert routing page I get a incident created in service now but I don’t get any of the details that should be included in the HTTP payload also the alert does not show up in the integration log. anyone have any suggestions or experienced similar issues ?Solved205Views8likes3CommentsLogicMonitor Custom HTTP Integrations
In a little bit of a low profile announcement, we released the ability to import and export Custom HTTP integrations in LogicMonitor v.118! Using the collective available knowledge, I've sanitized and exported a handful of them as examples and/or starting points for anyone looking to utilize these solutions. See my 'LogicMonitor Integrations' Github repository to review and download the .JSON files for import to your LogicMonitor portal. Currently published integrations include: - Big Panda (Two Parts) - Freshdesk - Hipchat Server - Microsoft Teams - Neptune IO - OpsGenie - Status.IO - VictorOps - Zendesk325Views2likes11CommentsJira Integration - bad design
The new Jira integration has been badly designed. https://www.logicmonitor.com/support/jira-service-management-integration-overview I saw the feature announcement and though “finally!”, but no, this just makes a copy of alerts in Jira and makes you use 2 UIs instead of one. Just look at the workflow - entirely driven by the LogicMonitor UI, and entirely Alert focused (facepalm - it should be Incident and Problem focused). NO. The acknowledgement of the Incident (NOT Alert) should be done in Jira when workflow is invoked. Map that back into LM. While the Alert flaps (CPU high, CPU low, CPU high, CPU low) FFS don’t create MORE Jira tickets. The existing ticket should be updated, maybe with a new Jira comment for each state change. Finally, when the Incident is over (to be determined CONFIGURABLY) as a manual action or after a timeout, can the ticket be transitioned through the workflow, but this should take custom workflows into account, not assume the Jira out of the box (OOTB) workflow. No-one who is serious about Jira uses that. Next, Problem management. When there have been X such incidents in a time window Y, create a Problem ticket, with all the incidents linked. This can only be closed manually. --- Sorry to rant, but this focus on Alerts instead of Incidents in the ServiceNow, AutoTask, Jira etc. integrations just generates ticket spam that helps no-one.85Views1like1Comment