Containment alert missing context when "no longer contained" action is selected

[mbarretta]

Kibana version:
8.2.0

Elasticsearch version:
8.2.0

Server OS version:
ESS

Describe the bug:
The context object is empty for the Tracking Containment alert action, resulting in the action (email, slack message, etc) lacking relevant information.

Steps to reproduce:

1. Define a Tracking Containment Alert w/ "No longer contained" Run-when action
2. Configure the action message with some context field or {{.}}
3. Trigger the action and inspect the results

Expected behavior:
The context should contain information, specifically the context.entityId of the entity that is no longer contained in the defined boundary

Screenshots (if relevant):
Configured Alert

Output from ^^ alert:

{
"alertId":"813bb290-eda6-11ec-a70e-97c4463664cb",
"alertName":"flights-over-my-neighborhood-2",
"spaceId":"default",
"tags":[],
"alertInstanceId":"ad9922-T6j4xnsBTUoj7Y2cALr3",
"alertActionGroup":"notGeoContained",
"alertActionGroupName":"No longer contained",
"context":{},
"date":"2022-06-16T20:30:21.802Z",
"state":{},
"kibanaBaseUrl":<snip>,
"params":{
  "index":"flights*",
  "entity":"icao",
  "dateField":"@timestamp",
  "boundaryType":"entireIndex",
  "geoField":"location",
  "boundaryIndexTitle":"geo_alerts",
  "boundaryGeoField":"coordinates",
  "boundaryNameField":"<nothing selected>",
  "indexId":"ab74a140-79cf-11ea-b317-7b8367a6c9c3",
  "boundaryIndexId":"da1f6040-9e25-11eb-85bb-a3dec98a9178"
},
"rule":{
  "id":"813bb290-eda6-11ec-a70e-97c4463664cb",
  "name":"flights-over-my-neighborhood-2",
  "type":".geo-containment",
  "spaceId":"default",
  "tags":[]
},
"alert":{
  "id":"ad9922-T6j4xnsBTUoj7Y2cALr3",
  "actionGroup":"notGeoContained",
  "actionGroupName":"No longer contained"
}
}
---------------------
Entity:
Detection Time:
Current Location:

[elasticmachine]

Pinging @elastic/kibana-gis (Team:Geo)

[thomasneirynck]

Below is not to dismiss this bug, but to provide some explanation as to why this is happening:

The No longer contained-event is a rename of a generic condition in the Kibana alerting framework. It is a rename of the RecoveryActionGroup (

kibana/x-pack/plugins/stack_alerts/server/alert_types/geo_containment/alert_type.ts

Lines 226 to 231 in 3730dd0

	recoveryActionGroup: {
	id: RecoveryActionGroupId,
	name: i18n.translate('xpack.stackAlerts.geoContainment.notGeoContained', {
	defaultMessage: 'No longer contained',
	}),
	},

). This actionGroup collects all the alert-instances that are no longer being fired.

e.g. a typical lifecycle of a geo-containment alert would be:

• time-window 1: car outside boundary
• time-window 2: car inside boundary -> event 'A' is created (context.* is available)
• time-window 3: car inside boundary -> event 'A' is maintained (context.* is available)
• time-window 4: car inside boundary -> event 'A' is maintained (context.* is available)
• time-window 5: car outside boundary -> event 'A' is recovered (context.* is lost)

So the recovery event (which only happens once) loses a reference to the context.*

Taking this into account, there seem to be a few open-questions:

• should a recovered message have access to context.*?
• is the UX correct? Should the context.* properties be shown as available when the No longer contained-event is selected.

I am not sure how this should be resolved. Any thoughts from @elastic/response-ops ?

[ymao1]

@thomasneirynck The alerting framework has recently merged a PR to allow rule types to specify context for recovered alerts.

Here is the PR: #124972
Here is the README with an example of how to use the new framework functions: https://github.com/elastic/kibana/blob/main/x-pack/plugins/alerting/README.md#recovered-alerts

If the geo containment rule type does create an issue for this, please link it to this meta issue where we're tracking the rule types.

[thomasneirynck]

thanks @ymao1 , I linked this issue to #126617

It's great that there's a pathway forward.

[mbarretta]

This might be a dup of #127191

[nreese]

@mbarretta

Your example requests context.detectionDateTime and context.entityLocation. entityLocation is unknown in the recovered alert. The recovered alert only has access to previous alerting state. The recovered alert does not have access to the latest document triggering the entity to be outside the boundary. Therefore, context.entityDateTime and context.entityLocation can either be null or the value of the last detection inside the boundary. Is that ok?

@ymao1
Can recovered alerts query elasticsearch? For example, could the recovered alert context logic query for the latest document to have entityDateTime and entityLocation?

The logic is in an async method so technically it is possible, just want to know if its a good idea performance wise?

[mbarretta]

Therefore, context.entityDateTime and context.entityLocation can either be null or the value of the last detection inside the boundary. Is that ok?

Frankly, I don't think the alert has any real value if I don't know where or when the entity left the boundary. The fact that it left is interesting, but the time it left (knowing we can approximate it as some point between the recovered alert trigger and the look-back time for that alert) and where it was going (leave north boundary or south?) are fairly critical.

Your question about querying ES to pull in last known location/time is a good one as I'd expect (haven't asked anyone) users would be doing that in practice when using this kind of alert.

... to provide a workaround to the entityLocation question, I guess users could define a second boundary around the "primary" one so they could see where and when an entity left via where it entered the second boundary. It wouldn't be pretty to create that secondary boundary in a non-overlapping way.

[nreese]

@mbarretta

Would you expect recovered alert context to not contain context.containingBoundaryId and context.containingBoundaryName since the alerts are no longer "contained"?

[mbarretta]

@nreese I know I'm too slow on the reply, but for completeness: yes, I'd expect the alert context to contain the boundaryID/Name of the boundary the entity just left. If I have more than one boundary, how would I know which boundary a given entity left? Granted, a query could tell me that, but obviously more valuable to be pushable in the body of an alert.