Integration - Custom HTTP Delivery issues with AWS NLB
Ok so I'm trying to setup a custom http delivery to an Event-Driven Ansible webhook. The EDA target is in AWS behind a network load balancer where SSL terminates on the ec2. For sake of argument let's assume everything on the AWS side has been done; sec group with LM's public IP's, no bad NACLs, NLB is interface-facing, public DNS is good, etc. So I can test the webhook using curl from an internal and external host, and it's successful! But testing from LM ends in nothing but a request timed out. I do not know if it's TLS/SSL related.. Is it DNS? Like can LM correctly resolve my fqdn? Is it some LB attribute like preserve client ip's? Here is the URL in question, sanitized: https://ansible.domain.com/eda-event-streams/api/eda/v1/external_event_stream/630729f0-702d-4b66-8e77-66f12b923fb0/post/ I did set the method to POST, included the user and passwd and a very simple Raw payload of {"message": "HELLO"}
LogicMonitor 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 - ZendeskOrphaned 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.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.Jira 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.
