Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Ability to resolve ServiceNow, IBM Resilient and Jira incidents #83221

Open
YulNaumenko opened this issue Nov 11, 2020 · 11 comments
Open

Ability to resolve ServiceNow, IBM Resilient and Jira incidents #83221

YulNaumenko opened this issue Nov 11, 2020 · 11 comments
Labels
enhancement New value added to drive a business result estimate:needs-research Estimated as too large and requires research to break down into workable issues Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework Feature:Alerting/RuleActions Issues related to the Actions attached to Rules on the Alerting Framework Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@YulNaumenko
Copy link
Contributor

YulNaumenko commented Nov 11, 2020 •
edited by mikecote
Loading

It would be great to leverage the new recovered action group to make alerts resolve certain types of incidents when they recover. There is currently no way to deduplicate incidents in ServiceNow, Jira and IBM Resilient to find the right incident to resolve. If there could be something similar to PagerDuty, that would be great.

Original description In the [issue](https://github.com//issues/77772) we are changing the grouping field for ServiceNow, Jira and IBM Resilient from {{alertId}} to {{alertInstanceId}}. But there is no similar way as for PagerDuty to avoid duplication of incident creation. We need to do an API call to check if the incident for a current alertInstanceId was created. Similarly there is no way to Resolve created incidents as we do for PagerDuty. ServiceNow, Jira and IBM Resilient requires to do a separate API call with the existing incident Id to change the status to Resolved. Do we planning to support Deduplication and Resolve mechanism for ServiceNow, Jira and IBM Resilient with the current limitations?
@YulNaumenko YulNaumenko added discuss Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Nov 11, 2020
@YulNaumenko YulNaumenko mentioned this issue Nov 17, 2020
Closed
@YulNaumenko
Copy link
Contributor Author

Based on the team discussion, was decided to solve the problem in two steps:

  1. Create a short term solution, where Resolved action group will be unavailable for ServiceNow, Jira and IBM Resilient action types. The proper issue is opened Bump Node.js from 12.19.0 to 12.19.1 #83452
  2. @arisonl will investigate how competitors implemented this integration. Does someone else support deduplication/ resolution features for incidents in ServiceNow, Jira or IBM Resilient. If it is, we should start working on the long term approach for adding similar support for Kibana Alerting.

@YulNaumenko
Copy link
Contributor Author

Based on the research from @arisonl, competitors have a support for Resolving incidents for ServiceNow, Jira or IBM Resilient

@mikecote mikecote changed the title [Actions][Discuss] Deduplication mechanism for ServiceNow, Jira and IBM Resilient Ability to resolve ServiceNow, IBM Resilient and Jira incidents Nov 23, 2020
@mikecote
Copy link
Contributor

Rename title to Ability to resolve ServiceNow, IBM Resilient and Jira incidents. We can use this issue to find a way to resolve IBM Resilient, Jira and SerivceNow incidents. If deduplication is the way to go, we'll handle it at the same time.

@mikecote mikecote removed the discuss label Nov 23, 2020
@mikecote
Copy link
Contributor

Moving from 7.12 - Candidates to 7.x - Candidates.

@mikecote
Copy link
Contributor

mikecote commented Feb 4, 2021

Moving from 7.x - Candidates to 8.x - Candidates (Backlog) after the latest 7.x planning session.

@gmmorris gmmorris added the Feature:Alerting/RuleActions Issues related to the Actions attached to Rules on the Alerting Framework label Jul 1, 2021
@gmmorris gmmorris added the loe:needs-research This issue requires some research before it can be worked on or estimated label Jul 14, 2021
@gmmorris gmmorris added enhancement New value added to drive a business result Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework Feature:Alerting/RuleActions Issues related to the Actions attached to Rules on the Alerting Framework estimate:needs-research Estimated as too large and requires research to break down into workable issues and removed Feature:Alerting/RuleActions Issues related to the Actions attached to Rules on the Alerting Framework labels Aug 13, 2021
@gmmorris gmmorris removed the loe:needs-research This issue requires some research before it can be worked on or estimated label Sep 2, 2021
@gmmorris gmmorris mentioned this issue Sep 22, 2021
Closed
@gmmorris gmmorris mentioned this issue Oct 13, 2021
Closed
@elasticmachine
Copy link
Contributor

Pinging @elastic/security-threat-hunting-cases (Team:Threat Hunting:Cases)

@ymao1 ymao1 removed the Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) label Nov 19, 2021
@cnasikas cnasikas added Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) and removed Team:Threat Hunting:Cases labels Jan 10, 2022
@elasticmachine
Copy link
Contributor

Pinging @elastic/response-ops (Team:ResponseOps)

@kobelb kobelb added the needs-team Issues missing a team label label Jan 31, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Jan 31, 2022
@timorkal
Copy link

Where is that currently at? We have Elastic Cloud and Jira Service Management, and we currently lack the ability to auto-resolve incidents.

@cnasikas cnasikas mentioned this issue Nov 3, 2023
Closed
@cnasikas
Copy link
Member

cnasikas commented Nov 3, 2023

Related #170522

@cnasikas
Copy link
Member

cnasikas commented Dec 1, 2023

PR #171760 implemented auto-closing SN incidents when an alert recovers.

@doakalexi doakalexi moved this from Awaiting Triage to Todo in AppEx: ResponseOps - Execution & Connectors Dec 7, 2023
@doakalexi
Copy link
Contributor

cc @shanisagiv1

@shanisagiv1 shanisagiv1 mentioned this issue Dec 13, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New value added to drive a business result estimate:needs-research Estimated as too large and requires research to break down into workable issues Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework Feature:Alerting/RuleActions Issues related to the Actions attached to Rules on the Alerting Framework Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
No open projects
AppEx: ResponseOps - Execution & Connectors
Status: Todo
Milestone
No milestone
Development

No branches or pull requests
9 participants
@gmmorris @kobelb @mikecote @cnasikas @ymao1 @elasticmachine @timorkal @YulNaumenko @doakalexi