-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Alerting] Add a possibility to define a custom status for the alert instances #78981
Comments
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
We can discuss this from another angle as well. Once we add UI support for multiple action groups, they should be reflected in the status somehow. As a discussion starting point, I had in mind the following:
This way it can keep a standard status across different types of alerts but allow a bit more information which would be tied to the action group. Using the issue description, usage of a |
From the triage meeting, we left this as discuss as:
So, we'll need to check back with Maps to see if the multiple action groups will handle their needs, and if not, get a better understanding of the problem. Also makes me wonder, given the note about the instance status disappearing, if there is something about there alert instance strings that needs to be tweaked. IIRC, they embed a location in the alert instance string, which could lead to instances seeming to come and go. |
@pmuellr Maybe, but the geo user experience might be better if we could explicitly assign the top-level states. It sounds like using action groups, we could have an action group called |
We recently merged PR #82275 , which adds the action group to the alert details view, per row. So the customers would see "active (tracking_contained)" or "active (tracking_outside)". BTW, I purposefully named the default action group for the index threshold to "met threshold" (with a space!) because I figured we'd eventually want to make these "human readable", and so wanted to make sure we weren't "surprised" if someone else wanted to use spaces in their action groups. And there may be i18n stuff going on besides that to do further translations anyway. Not clear if you knew that was coming or not - does that suit your needs? Or perhaps I'm misunderstanding the comment. |
@pmuellr After chatting a little further about it with folks from Maps and Alerting, what we ideally need is something dynamic and more granular. This would be roughly the ideal workflow:
We're still determining how best to use action groups, but I don't think they'll help us here since the categories we use are dynamically determined (in step 2 above). Also since action groups are more user facing, I can't imagine a user explicitly defining the conditions for each of the 50 states of the USA (as an example). |
Thanks for the additional detail, this is great! More use cases like "notify when a user moves into a different US state" are good!
What happens if shapes overlap? My first thought is that the instanceId should basically be On the face of it, I'd prefer a new alert instance service function Is there any software in this area, doing this kind of stuff, already used in the field? |
@pmuellr Good questions/comments!
Correct. Not ideal for us, just our best idea for a workaround in the current code. We'd prefer to be able to do historic tracking of where the point was prior.
We can add a layer in the Maps app that displays a point tracking layer containing all records of where a point has been and then overlay an indexed alert layer. It's not ideal for filtering though if the alert instance ID (
In the proposed setup this would create different alert instances. The user would be alerted of newly active
Agreed!
This is interesting. Can we include context variable data in the dash?
A function like
I was just thinking of having a |
Event log does not current store any alert-specific information, so there's no opportunity to store the locations. We'll probably stick to this line for as long as we can, otherwise we'll have more mapping complexities, potential for alerts storing huge documents, etc. We tend to think of alerting storage as "just alerting-related bits" and not "app-related data", so we'd prefer to keep app-related data linked somehow (via saved object references, instance ids, etc), instead of duplicated.
So again, those "records" won't be event log records, they would need to be something you store in separate SO's, or encode in the instanceId. Basically, you shouldn't consider the event log to be your primary store.
Currently no, IIUC. The mustache templating variables provided by an alert that can be used in action params are transient, we don't store those anywhere. We render the action params with the variables provided, and store the results of those renderings, which are the action params themselves, and even those are transient - they exist within task manager documents, but will be deleted once the action successfully executes.
I think having the statuses open-ended, extendable by alerts, is going to be a bit of complexity nightmare. Maybe it makes sense to have a "side car" property (string(s)) on the status that could be alert-specific (and completely ignored by alerting itself), that could also be displayed in UIs. @mikecote? |
Agreed. @aaronjcaldwell I'm trying to understand how the "shapes" are defined by the user and maybe the alert creation flow will help me better understand what we can propose here. This could be a case for dynamic action groups 🙈 but I may be wrong. |
We're open to other options. We just need to accomplish the following: When a point moves to a different shape, let's say it's a car that goes from Alabama to Georgia, an alert is triggered. It was active before and it's active now, but its containing State has changed.
This comment gives the high-level version, but can do a deeper dive if needed! Upon creation of a single alert, a user selects an index and filters to select a number of shapes for containment tracking. These could really be any shapes, a single square in the middle of the ocean or every zip code in the USA. It's pretty open ended.
This possibly is a case for dynamic action groups. The only reason we aren't considering action groups currently is because they're static and declared upfront when the alert type is registered. If they were dynamic, we could have an action group per shape. I'm not entirely sure how this would play out in the UI though. |
How would dynamic action groups work from a UI view? You certainly don't want to have to add the same actions to 50 action groups in the UI! |
I'd also have questions about the interplay of the current static action groups with dynamic action groups. We're already thinking static action groups will be useful to us to represent |
Hi @aaronjcaldwell , In this way, you could have Would this address your need? |
@gmmorris I believe this would fit our needs perfectly! A few questions:
|
I need to sync with @ymao1 but I'd expect it to be the same as with normal action groups.
Subgroups are just away of identifying when you might want to fire fresh actions even though the instance is still in the same action group as before. This means recovery should be unaffected as the instance hasn't in that case recovered, but rather remained active within another group.
It's impossible top recover from a subgroup, only from a normal action group, so it's the same as before |
After chatting with @aaronjcaldwell it sounds like #84751 addresses this need for the Maps team. Do we think there's more to this beyond what we've already delivered? |
After chatting with @mikecote I'm going to close this - seems like our SubActionGroups addressed the core need and feel it's sufficient |
Currently alert instance can be in a two statuses:
Active
andOK
.For example, Maps team noticed that it would be useful to have a special status for Contained object inside the polygon.
When object just crossed the polygon border, alert was triggered and become an Active just for a second and after the next execution moved to status OK and then just disappeared.
'Contained' alert instance status can be useful for the user to understand that the object was crossed the polygon border and currently stayed inside.
The text was updated successfully, but these errors were encountered: