elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.82k stars 8.2k forks source link

Improve rule parameters validation #164024

Open maryam-saeidi opened 1 year ago

maryam-saeidi commented 1 year ago

📝 Summary

Multiple scenarios will be mentioned later in this ticket, in which we need more data for validation on FE or BE than what is available in the rule params. To compensate for that, usually, the solution is to save extra information in the rule parameters solely for validation purposes.

❓ Question

I will share two examples here (related discussion), and my question is, how can we improve this case and ensure we have enough context for validation without polluting rule parameters?

📔 First example - Elasticsearch query (there is a similar situation for the new Threshold rule)

When selecting data view in Elasticsearch query, we need to make sure the data view has a timestamp field.

Since we don't have all the information related to the data view at the time of FE or BE validation and those validations are synchronous, an extra field called timeField was added to the rule param, which is used for this purpose.

I see 2 issues with this approach:

  1. Adding an extra field to the API just for the sake of validation (As Chris pointed out: "My main issue is now we have a field in the API which isn't really required and doesn't make sense for the Rule-As-Code use case")
  2. How to ensure that when the rule is created via API, the timeField is matching the actual timestamp field in the data view?

📔 Second example - SLO (provided by @simianhacker )

This is a problem with the FE rule validation, you have to put everything in the rule params even if you're trying to validate something that doesn't need to be stored.

We had a similar issue with the SLO Burn Rate Rule, we need to calculate the max_burn_rate_threshold using the SLO the user had selected. BUT the SLO is not available in the validation code SO instead we had to add it to the rule params schema even though it's only used for validation. My main issue is now we have a field in the API which isn't really required and doesn't make sense for the Rule-As-Code use case.

elasticmachine commented 1 year ago

Pinging @elastic/response-ops (Team:ResponseOps)

Zacqary commented 7 months ago

Assigning this to myself as part of Create Rule Flow V2 #175634