Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ResponseOps] Add config to control maximum "for the last" / window allowed #153723

Open
dhinesh260 opened this issue Mar 25, 2023 · 5 comments
Open
Labels
Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@dhinesh260
Copy link

Add a option or config for admin to control maximum interval allowed by a user to check for last X (minute/hour/days) to avoid cluster overload.

(last 5 minute / last 30 minutes) in screenshot for ref

@botelastic botelastic bot added the needs-team Issues missing a team label label Mar 25, 2023
@wayneseymour wayneseymour added the Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) label Mar 31, 2023
@elasticmachine
Copy link
Contributor

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

@botelastic botelastic bot removed the needs-team Issues missing a team label label Mar 31, 2023
@pmuellr
Copy link
Member

pmuellr commented Apr 6, 2023

I suspect you mean "minimum interval" and not "maximum interval". You're trying to prevent people from creating rules that would run every 1 second (for example), correct?

Also, there is no screenshot attached.

We have a configuration settings xpack.alerting.rules.minimumScheduleInterval.value and xpack.alerting.rules.minimumScheduleInterval.enforce that I think will do what you want:

see: https://www.elastic.co/guide/en/kibana/current/alert-action-settings-kb.html#alert-settings

These settings were adding in version 8.2.

xpack.alerting.rules.minimumScheduleInterval.value
Specifies the minimum schedule interval for rules. This minimum is applied to all rules created or updated after you set this value. The time is formatted as:

<count>[s,m,h,d]

For example, 20m, 24h, 7d. This duration cannot exceed 1d. Default: 1m.

xpack.alerting.rules.minimumScheduleInterval.enforce
Specifies the behavior when a new or changed rule has a schedule interval less than the value defined in
xpack.alerting.rules.minimumScheduleInterval.value. If false, rules with schedules less than the interval will be created but warnings will be logged. If true, rules with schedules less than the interval cannot be created. Default: false.

@pmuellr
Copy link
Member

pmuellr commented Apr 6, 2023

Since I suspect this answers your question, I'm going to go ahead and close this issue.

If it doesn't answer your question, feel free to re-open, and add additional detail.

@pmuellr pmuellr closed this as completed Apr 6, 2023
@dhinesh260
Copy link
Author

Hi @pmuellr

20230415_173338.jpg

I think i have used wrong terminology which made this confusion.

I m referring to maximum timeframe user can select, not minimum schedule interval.

Admin need control that User should not select more than "last x minutes/hours" (pls refer screenshot)

Eg) Admin wants user to select not more than last 4h while configuring the rules.

But, if a user try to configure alert if xyz condition for last 6h.

If Kibana has a config that does not allow user to select last 6hours because maximum timeframe a user can configure is 4h.

@pmuellr pmuellr changed the title Alerts (Rules) Add config to control maximum interval allowed Alerts (Rules) Add config to control maximum "for the last" / window allowed Apr 17, 2023
@pmuellr pmuellr changed the title Alerts (Rules) Add config to control maximum "for the last" / window allowed [ResponseOps] Add config to control maximum "for the last" / window allowed Apr 17, 2023
@pmuellr
Copy link
Member

pmuellr commented Apr 17, 2023

Ah, I'll re-open the issue; I already change the title to reflect this.

This will be slightly interesting because I think most rules do have a "for the last" / "window" / "look back" argument, controlling how far they "look back" when running queries. But it's not a standardized field at the rule level; these sort of fields are defined by the rule type.

So, I can imagine having a "general" config option controlling the maximum value here, but each rule will need to add their own checks for this, as part of their validation. Some cat-herding will be needed to make sure we get all the rules modified once we do this.

@pmuellr pmuellr reopened this Apr 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
Development

No branches or pull requests

4 participants