Share additional context logic between different rule types

[maryam-saeidi]

Summary

We would like to extract the additional context (maybe into a package) and share it between different rule types to ensure consistency and make it easier to extend this logic.

Currently, we have the following logic for adding additional context as mentioned in this comment:

Rule	Group	Include	Exclude
Custom threshold rule & Metric threshold rule	host.name, host.hostname, host.id, kubernetes.pod.uid, container.id	host.*, cloud.*, orchestrator.*, container.*, labels, tags	host.cpu.*, host.disk.*, host.network.*
Inventory rule	no group by	host.*, cloud.*, orchestrator.*, container.*, labels, tags	host.cpu.*, host.disk.*, host.network.*
Log threshold rule	fields contain any of these prefixes: host, cloud, orchestrator, container	only related prefix will be added: host.*, cloud.*, orchestrator.*, container.*, labels, tags	*.cpu.*, *.disk.*, *.network.*, *.memory.*

There are subtle differences between rules such as the exclusion of host.cpu.* vs *.cpu.*, or excluding *.memory.* only in log threshold. We also have a plan to add additional sources. So we need to share this logic between different rules to be able to extend this logic more easily and make sure it is consistent everywhere.

Proposal

Here is the proposal for the shared logic:

Rule	Group	Include	Exclude
All rules	fields contain any of these prefixes: host, cloud, orchestrator, container	only related prefix will be added: host.*, cloud.*, orchestrator.*, container.*, labels, tags	*.cpu.*, *.disk.*, *.network.*, *.memory.*

[elasticmachine]

Pinging @elastic/obs-ux-management-team (Team:obs-ux-management)

[jasonrhodes]

I think a big question for us to clearly answer and document for ourselves is if we intend for all of these rule types to work the same way re: storing these contexts. Moving to this kind of shared usage makes sense so long as we can guarantee that's the intention (I think it is, but I know we don't have a great way to document this as the definitive decision going forward, maybe?)

[maryam-saeidi]

Some reasons for having this logic shared:

1. Based on this comment, we learned through adding additional context about how to improve this logic but since this logic is not shared, we didn't have those improvements everywhere.
2. Having a shared logic helps our users to have similar expectations for different rules, so I think by default it is good to have the same logic everywhere unless there is a reason.
   We can still accommodate and document differences but having this logic in one place would help us to have a better overview of those differences.
3. Extending this logic for all the rules would be easier if this logic is shared (Especially since we are considering adding more ECS groups to the list).