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.319Views22likes13CommentsBuilt-in OpsGenie Integration
Hello, We currently use a third party (OpsGenie) for alerting, and currently we have a custom integration configured in LogicMonitor to send alert information to OpsGenie. Although there hasbeen significant improvements to integrations over the past few months, one feature that lacks significantly for us is a supported two way integration between OpsGenie and LogicMonitor. This would be very similar to the partnership/integration that LogicMonitor has already built with PagerDuty. As LogicMonitor releases new integration features, it tends to break current workflows with alert creation in OpsGenie. Asupported integration would give us more confidence that as LogicMonitor continues to release new features, that our alert functionality would continue to operate as expected.9Views8likes0CommentsLogic 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 ?Solved129Views8likes3CommentsLogicMonitor 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 repositoryto 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 -Zendesk215Views2likes10CommentsAdditional Activities for HTTP Integration
We would like to have someadditional activities for integrations. Currently integrations can be triggered for the following activities: Acknowledged Cleared Escalated/De-escalated We would like the followingadditional activities: Device Added Device Deleted Service Added Service Deleted This will solve a problem that we currently have. We use the HTTP integration to post events to a key-value database (in Google Cloud Platform). Normally, the 'cleared' activity will enable us to remove events from the database.However, if a device or service is deleted then we can end up with events in the database with no matching device or service in LogicMonitor. By adding the device/service add and delete activities we could keep our key-value database in sync with LogicMonitor.3Views1like0CommentsToken for Alert Acknowledgement Comment
I would like to request the ability to utilize a token to pass the Acknowledgement Comment for an alert to a ConnectWise ticket. Ideally we would like it so that when a ConnectWise ticket's status is updated because the alert has been acknowledged in LogicMonitor, the comment set for the acknowledgement is passed and included in the ticket. Currently we are able to use the ##ALERTSTATUS## token to display the current status of the alert, but the ability to utilize the acknowledgement comment would greatly improve ticket handling. Thank you, Chris Czuhanich5Views1like3CommentsJira 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 acknowledgementof the Incident (NOTAlert) 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.71Views1like1Comment