[Logs / Metrics UI] [Discuss] Switching alert rules to the new rules registry

[Kerry350]

Summary

We should decide how we wish to proceed with moving to the new rules registry setup. This is just a ticket for discussion, implementation tickets can follow.

Changes

Code changes are small (AFAICT), our decision mostly pertains to how we register our registry / registries.

• Creation of a registry
• Registering rules on the registry
• Accessing scheduleActions via alertWithLifecycle

For the registry creation we can either:

• Become a child registry of Observability
  • With one registry (infra)
  • With two registries (logs and metrics)
• Become a child registry of APM (which is a child of Observability) (I'm not 100% sure why we'd choose this one? But it was mentioned recently so I've added it)

My personal preference would be to become a child of Observability, with two separate registries for logs and metrics.

Our solution specific rules (log threshold, metrics threshold, inventory threshold etc) are then registered via their specific registry.

Other questions

• How should we deal with fieldMap? This expects a mapping that maps to our rules. However, our rules are very freeform, in the sense that we allow the user to select the field and we don't know these up front.

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[jasonrhodes]

One thing that's a little fuzzy to me, for @dgieselaar / @smith probably: why do we need to each create our own registries, rather than just registering our own rule types with a central observability registry? I looked at the code path a little and it seems like the settings passed into the APM registry are pretty bare (at the moment, at least):

https://github.com/elastic/kibana/blob/master/x-pack/plugins/apm/common/rules/apm_rule_registry_settings.ts#L8-L10

Is there a reason we have this current split?

[dgieselaar]

@jasonrhodes it depends, if you need a lot of mappings (e.g. because you're alerting on a specific type of log message and want to extract those), then it makes sense to create your own mapping. What fields do you need indexed?

[dgieselaar]

If you don't know what needs to be indexed, the only option is to use runtime fields and/or the fields API, depending on what you need. I'm not sure where you want to show these alerts and where these fields should be displayed.

[jasonrhodes]

Sorry, I meant to say that I thought these types of settings would be defined at registration time, per each rule type that we register. I understand we have work to do to figure that part out. I wasn't clear on why we needed to create separate registries, rather than handling these options when we register a rule type. Does that make sense?

[dgieselaar]

The registry sets up the indices etc at plugin setup. Do you mean that you figured the index mappings/ilm policies etc would be defined per rule type?

[jasonrhodes]

The registry sets up the indices etc at plugin setup.

Ah, so we're storing alerts in separate indices per registry, at the moment? (Rather than a single observability alerts index with a unified mapping and sparse data, would I guess be the alternative I thought we were originally talking about?)

I have no preference here, just making sure I understand. Thanks.

[dgieselaar]

@jasonrhodes there's a pretty big difference between mappings in observability indices, so each plugin creating their own, but branching off the observability one seems like the most reasonable option. I'm not sure how it will pan out, we can revisit once more teams start integrating.

[jasonrhodes]

OK, so one index/mapping per rule registry, for now. Makes sense. I think each rule type may also end up having significant differences, but let's address that as we get to it.

[weltenwort]

Thanks for creating the issue.

How should we deal with fieldMap? This expects a mapping that maps to our rules. However, our rules are very freeform, in the sense that we allow the user to select the field and we don't know these up front.

I can think of two options to deal with the unpredictable set of fields:

1. flattened field type: Reserve a specific field in the mapping for storing these user-controlled key-value pairs. This allows for out-of-the-box querying of the values with limited semantics as defined by the flattened field type.
2. don't index the field: Reserve a specific field (or dynamic mapping rule) to turn off indexing for these user-controlled key-value pairs. This allows for querying using query-time runtime fields with the corresponding limitations (field types, performance).

To me it looks like it comes down to the queries we expect to run and the amount of data we intend to query:

1. Do we expect to query by user-controlled key-value-pairs?
2. Do we expect to require non-keyword semantics on the queries to the user-controlled key-value-pairs?
3. Do we expect the amount of documents to be so large that using runtime fields could be risky?

I'm not prepared to express preference for either option at this point and would be interested to hear if anyone else can come up with additional criteria and tradeoffs.

[jasonrhodes]

I think we should move forward with Logs UI rule registration separate from Metrics UI rule registration, whatever that means once the rule registration mechanics are stable. I'm going to create new tickets for each of the solutions to register their existing rules.