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.

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

Research bi-directional action types #56396

Closed
mikecote opened this issue Jan 30, 2020 · 9 comments
Closed

Research bi-directional action types #56396

mikecote opened this issue Jan 30, 2020 · 9 comments
Labels
Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@mikecote
Copy link
Contributor

Research what it would take to accomplish #51636.

@mikecote mikecote added Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Jan 30, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

@pmuellr
Copy link
Member

pmuellr commented Jan 30, 2020

Let's get some use-cases listed!

here's one:

from #51636 (comment) :

a Slack message with a button that can Ack the alert

We don't have "Ack"ing for alerts yet, but we do have mute/un-mute/throttle kinda stuff. At the previous job, we had some Slack alerts that did this kind of thing, was SUPER useful to be able to silence a wall of noise in Slack, right from Slack.

@gmmorris
Copy link
Contributor

Things to think about in this context:
Does ACKing require a concept of an Alert Instance having a start and an end?
Would ACKing an Alert Instance mean that if it comes up again on the next run we don't include it? Do we include it in some semi-muted state so it appears in the Details Page, but doesn't fire actions?

Just some things that crossed my mind reading the issue.

@pmuellr
Copy link
Member

pmuellr commented Feb 1, 2020

Does ACKing require a concept of an Alert Instance having a start and an end?
Would ACKing an Alert Instance mean that if it comes up again on the next run we don't include it?

Great questions about ACKing, which AFAIK is not related at all to bi-directional action types. We should probably open up a separate discuss issue on ACKing alerts when we're ready to discuss it ...

@gmmorris
Copy link
Contributor

gmmorris commented Feb 3, 2020

Haha, fair enough... you brought it up ;)

@mikecote
Copy link
Contributor Author

Another use case:

Update a document in Kibana when a ServiceNow case has been closed. The bi-directionality here would be to check the case on an interval basis until a condition is met, then update document in Kibana.

The challenge here is to keep the credentials (API Key) of the person who originally invoked the action to lookup the case's status at a future time.

@mikecote
Copy link
Contributor Author

mikecote commented Jun 8, 2020

Example from @alexfrancoeur

The example I give is Slack and being able to acknowledge, mute or snooze and alert from a slack message

@alexfrancoeur
Copy link

There are many out there, but here's one example from OpsGenie. If we intend to eventually introduce ownership and acknowledgement natively from Kibana alerts, supporting this use case and functionality probably makes sense. Otherwise, we can defer to third party tools (like OpsGenie or PagerDuty)

image

https://docs.opsgenie.com/docs/slack-app-integration

@mikecote
Copy link
Contributor Author

mikecote commented Aug 6, 2020

Closing issue and merging with #51636.

@mikecote mikecote closed this as completed Aug 6, 2020
@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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
None yet
Development

No branches or pull requests

6 participants