I'm slowly loosing what hair i have left with this one. Here's the problem to solve;
- we are running JSM Operations (nee Opsgeneie) and JSM
- we want to allow for email integration within JSM Operations so that alerts can be created automatically
- those on-call / alerted triage the alert and if deemed an incident they use the 'create incident button'
- this will then present the default form and once filled in an incident ticket is created in our JSM project
This all good and does what we need to get a ticket added to a team backlog. However there's an issue I can't solve. When the incident ticket is created in our JSM project, the sync process kicks in and merrily creates yet another alert ?!?!
I've looked at other reported issues such as https://community.atlassian.com/forums/Opsgenie-questions/How-to-manage-duplicate-alerts-against-jira-incident/qaq-p/1946586 and https://support.atlassian.com/opsgenie/docs/what-is-alert-de-duplication/ which goes some way and seems to rely upon the Alias custom field within JSM Operations (nee Opsgenie)
Where things come unstuck is that the value of the Alias custom field is *not* 'handed over' to JSM Project ticket. It therefore seems that the sync process will simply create a new alert (as the Alias custom field is not included during the sync process - or I can't see how it works)
What is confusing is that when you look at the JSM Project ticket, it contains a linked alert field (on the screen)
which points to the original Alert
that implies there is a link already so why is the sync process creating a new Alert ????
Here is the sync (which is pretty vanilla)
Hi @Paul Swartout ,
So the alerts are being created via email, apologies if I missed it but what's sending the email to the OpsGenie/Operations email? is it a JSM automation?
Email to JSM Operations (OpsGenie) which creates the alert via email integration as normal.
Open alert and click the creat incident button, fill in details and ticket is created into the JSM project.
The sync process then creates another alert.
All vanilla out of the box with no automation changes.
Very weird. I'm trying my own automation from JSM Operations (nee OpsGenie) but that's additional work I hadn't counted on.
Everything works apart from this superfluous alert that's being created by the sync process.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
From what I'm gathering, your sync is configured to create an alert whenever a [System] Incident is created in your JSM project. So, when you manually create an incident from an alert, that new incident is going to match the sync criteria resulting in another alert being generated.
If the alert is being generated from an incident, then that theoretically should be the record your team responds to the incident from after being alerted rather than creating a new incident from the alert.
Typically, we use the "Create Incident" action when an alert originates from an external monitoring tool and we want to open a work item in JSM. But if the alert is coming from within JSM itself, creating another incident seems to create a duplicate record to me
but If I'm misunderstanding your setup please let me know
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I think there's something I'm still not explaing correctly. Let's try again.
1 - email is sent to JSM Operations (OpsGeneie) via OpsGenie email intergration
2 - an alert is created (automatically) and someone triages that alert. if they feel it's a legitimate incident, then click on the "Creat Incident" button (built in functionality) which creates a '[System] Incident' ticket in a JSM project
3 - the sync process within OpsGenie then seems to pick up the event of creating a new '[System] Incident' ticket and creates yet another alert
What I'm trying to understand is why the OpsGenie sync process is creating a new alart rather than update the original alart.
NOTE: we also have Pingdom intergation with OpsGenie (which creates an alert) and process to follow is from point 2 onwards so this fault is not just related to email integration.
What's wierd is the fact that the '[System] Incident' refers to the original Alert in the Linked Alerts screen (see above). I have no idea what this field is so unable to check the data.
TLDR: OpsGenie sync is creating a new alert rather than updating the original despite the fact that the '[System] Incident' seems to know which Alert it was created from.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Seems like this sync's create alert rule isn't necessary if your team's process is triaging an alert created from your integration and then using the create incident button, it's what creates the duplicate alert.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I would agree but that's been like that from day dot. I'm under the impression that JSM handles this via https://support.atlassian.com/jira-service-management-cloud/docs/what-is-alert-deduplication/
Also we need that sync to create alerts from Incident tickets (our internal teams do that rather than create alerts - especially for P0/P1 issues). This works seamlessly 'unless' the ticket is created via the 'Create incidement' button within the Alert detail screen.
I'm starting to lose what hair I have left.
TBH I'll raise a ticket with Atlassian as there's something I can't see under the covers.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Maybe a workaround can be adding a condition in your sync rule to filter incidents created from your Pingdom alerts using the Incident Summary field if there is a format or tag that can be identified from the alert title / incident summary
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.