Add geo containment tracking alert type

[kindsun]

Introduce new alert type Tracking containment to alerts. Differentiated from Tracking threshold by the following features:

• Alerts are sent repeatedly (toggle dependent) on containment
• Leverages action groups for containment vs. non-containment allowing different per action scheduling
• Simplified UI

Generally, these instructions will apply for testing this PR with a couple of exceptions:

For 6, use the following mappings:

PUT /manhattan_mta_alerts/_mapping
{
  "properties": {
    "entityId": {
      "type": "keyword"
    },
    "entityDateTime": {
      "type": "date"
    },
    "entityDocumentId": {
      "type": "keyword"
    },
    "detectionDateTime": {
      "type": "date"
    },    
    "entityLocation": {
      "type": "geo_point"
    },
    "containingBoundaryId": {
      "type": "keyword"
    },
    "containingBoundaryName": {
      "type": "keyword"
    }
  }
}

For 9, use this indexing structure:

{
    "entityId": "{{context.entityId}}",
    "entityDateTime": "{{context.entityDateTime}}",
    "entityDocumentId": "{{context.entityDocumentId}}",
    "detectionDateTime": "{{context.detectionDateTime}}",
    "entityLocation": "{{context.entityLocation}}",
    "containingBoundaryId": "{{context.containingBoundaryId}}",
    "containingBoundaryName": "{{context.containingBoundaryName}}"
}

[elasticmachine]

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

[kindsun]

@thomasneirynck Might also be worth changing our experimental flag in this PR to cover both alert types and make more generic. Thoughts?

Update: Discussed offline and agreed to update config value to cover both. enableGeoTrackingThresholdAlert -> enableGeoAlerts. New config value to enable both alerts is: xpack.stack_alerts.enableGeoAlerts: true

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: dd727b5

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
stackAlerts	31	41	+10

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
stackAlerts	81.7KB	114.0KB	+32.4KB

Distributable file count

id	before	after	diff
default	43205	43214	+9

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
stackAlerts	14.6KB	17.3KB	+2.7KB

Unknown metric groups

async chunk count

id	before	after	diff
stackAlerts	2	3	+1

History

• 💚 Build #91539 succeeded af967c6
• 💔 Build #91447 failed e6903e3
• 💔 Build #91412 failed 4f473d3
• 💔 Build #91153 failed d1e72db
• 💔 Build #90906 failed 09e61e1

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[thomasneirynck]

🎉 I think this has a great scope.

---

imho, the containment-approach fits in really nicely with the overall alerting framework:

• this monitors the state of a vehicle over time. the state is its location relative to a given shape. Compare this to e.g. monitoring the health of a system.
• a vehicle can be in a given state across multiple time-windows. Compare this e.g. to how a server may be in "danger-state" for multiple windows
• containment "resolves" when the vehicle no longer is in a given-state, ie. the vehicle is "outside".
• the UX forms of the containment-alert-type does not clash with the surround forms of the alerting-frameword.. In contrast, the UX-form of the geo-threshold alert-type do significantly clash with the surrounding forms. The latter has a lot of options which do not make sense (e.g. what does it mean to throttle messaging for thresholds? what does it mean to notify on resolved-action-group?)

With containment, the alerting framework then handles nuances in the messaging:

• Alerts resolving allows us to only message on "exiting"-events. This is handled by the ability to tie an action to a "resolved" action-group only.
• Ability to throttle messages allows us only to notify when a vehicle enters a shape (pending Ability to throttle alert instances until action group changes #50077)
• In the future, we could even remove the tuple-approach which explicitly ties an alert to a shape-vehicle combo, and instead tie an alert to a vehicle only (pending [Alerting] Add a possibility to define a custom status for the alert instances #78981)

---

Outstanding known issues:

On geo-containment alert side:

• dealing with laggy data: (ie. ingest is laggy, causing the vehicle-time to precede the index time quite a bit. in this scenario, the alert-window executes before the data for that window is actually indexed).
• dealing with sparse data: vehicles do not ping on a regular frequency, causing their "current"-location (in the real world) to be equivalent to the last-known location (by Elasticsearch). In such a case, the moving interval window is flagging these vehicles as resolved, even though they are still inside.

Overall performance considerations:

• under heavy load (thousands of alerts per window), the alerting-window frequency slows down significantly. Will be discussed with alerting-team on how to proceed: cc @gmmorris @YulNaumenko

[thomasneirynck]

+1 on grouping them together

[thomasneirynck]

nice. very intuitive now in containment-alert

[thomasneirynck]

+1 I think this probsbly capture what we would like in a message. cc @kmartastic Anything else?

[thomasneirynck]

we could remove having this other-bucket altogether, because we are explicitly filtering out these results later on:) . This may be hypothetically useful for more advanced fucntionalities later down the line (e.g. tracking vehicle-location through state)

idk, up2you if you would like to remove. It does negatively impact the query, creating buckets when they are not needed. in terms of code, footprint is minor.

[kindsun]

Yep, I considered this too. I only left it in because it was going to be the only query mod required for this PR and I happen to know I want this information for the forthcoming PR that adds better handling for if/when an alert instance goes into a resolved state. Basically it gives a firm "We've received an update and confirmed this is not in an area of interest" message. Agreed this is a performance hit in the meantime and should be removed if not used but I'm fairly confident it will be. Good to document this decision here though 👍

[YulNaumenko]

Code LGTM. Tested locally and it works great!