Orphaned tickets when a alert changes severity...
Hi, I came in today and had a bunch of leftover tickets from the weekend. They were all for Low Disk Space since we had patching on Saturday. I know all the servers are working fine so I wasn't sure why I had these alerts. After some research, I think LM has a slight issue in how it interacts with Integrations. I'm specifically using Zendesk but I'm not sure if that matters. Here's what happened. Error alert came in for a server with low disk space. LM used our ZD integration and fired the Active line which creates a ticket in ZD for us. 6 minutes later, the disk space dropped below the next threshold and became a Critical. LM used our ZD integration and fired the Active line which creates a ticket in ZD for us. Now we had two tickets for the same alert. One for the Error and one for the Critical. Later on, the alert cleared. LM used our ZD integration and fired the Clear line which closes the ticket in ZD for us. However, it only fired this line once, for the Critical alert, which closed the second ticket that had been created. This left the Error ticket still open and now orphaned. The subject line of the tickets has the Severity in them, so it's right that it created a second ticket when the alert went Critical. However, it should have either then, or when it closed the alert, fired two Clear integrations to close out both the tickets that had been created. Has anyone else ever noticed anything like this? I'm not sure if we have something broken or if this has always been like this or what. Thanks.42Views0likes9CommentsSeeing 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.357Views22likes13CommentsLogic 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 ?Solved154Views8likes3CommentsJira 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.80Views1like1CommentLogicMonitor 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 -Zendesk248Views2likes10CommentsLogicMonitor Integration with IFTTT (If This, Then That)
IFTTT is a free SaaS platform that helps you "do more with all your apps and devices" - by providing an integration point betweencommonly used services and platforms. In the following example, we're using the IFTTT Applet webhooks "trigger" to activate a Philips Hue wireless lighting "action" - blinking the lights of the connected Hue platform as a result ofa LogicMonitor alert! Other things you might be able to do with LogicMonitor alerts, through IFTTT (lots of untested possibilities!) : Change lighting colors based on alert status (red for new, green for cleared, etc.) Receive alert notificationsto connected systems like Skype,Twitter, Evernote, or Google. Play music on a connected Sonos system after triggering an alert. Turn on a connected Smart Plug like the Wemo from Belkin. The Finished Result The following tutorial assumes that you have an IFTTT account created and permissions to add an integration to your LogicMonitor account. Step 1: Log into your IFTTT account and create a new 'Applet' Step 2: Search for and choose the 'Webhooks' service. Step 3: Choose the 'Receive a Web Request' trigger. Step 4: Configure (and remember) the event name that will be recognized by the incoming webhook to trigger the event. Step 5: Configure the 'Action' that will be taken when this event is triggered in IFTTT - lots of intriguing possibilities! Step 6: Once you've added and configured the 'Action,' review the applet settings and click 'Finish' to save the Applet. Step 7: Select 'Services' from the account dropdown - we will be looking up the incoming webhook URL for our account so we know where to send our alerts. Step 8: Search for the 'Webhooks' service and select it to proceed. Step 9: Select the 'Documentation' link from the 'Webhooks' services page. Step 10: Copy the incoming Event trigger URL along with the key for your account. You will replace {event} in the URL with the one you configured above. Step 11: Moving to your LogicMonitor account, navigate to 'Settings -> Integrations' and add a new 'Custom HTTP Delivery' integration using the event name from Step 4 and theURL (with key) from Step 10 : Step 12: IFTTT allows you to include an (optional!) payload - which will show in the 'Activity Log' of the IFTTT Applet. Step 13: Test Alert Delivery and you should see output similar to below in the IFTTT Activity Log. Step 14:Save your integration, assign it to an Escalation Chain, and assign the Escalation Chain to an Alert Rule - and now we've configured a simple integration between LogicMonitor and IFTTT that could form the basis of a handful of interesting alert actions!13Views0likes1CommentAdditional 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.8Views1like0Comments"Filter" Integration
I have at least one case where it would be handy to use an external integration in a filter-only mode. The idea is we could pass the tokens into the integration, and the integration would pass back a formatted message suitable for inclusion in an alert. In my case, the goal is to build a more powerful alert templating tool for the standard email method rather than requiring the integration also deliver alerts. One major result of this is that the integration server reliability becomes less critical -- if it is not responding, the default presentation could be used instead, for example. Hopefully that makes sense, please let me know if I can answer any questions. Thanks, Mark4Views0likes1Comment