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

Advance scheduling (cron syntax, etc). #50272

Open
mikecote opened this issue Nov 12, 2019 · 17 comments
Open

Advance scheduling (cron syntax, etc). #50272

mikecote opened this issue Nov 12, 2019 · 17 comments
Labels
estimate:needs-research Estimated as too large and requires research to break down into workable issues Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework Feature:Alerting Feature:Task Manager R&D Research and development ticket (not meant to produce code, but to make a decision) Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@mikecote
Copy link
Contributor

mikecote commented Nov 12, 2019

For reference, Watcher allows some uber-flexible ways of scheduling, documented as "triggers", documented here:

https://www.elastic.co/guide/en/elasticsearch/reference/current/trigger-schedule.html

I think I'd be happy with having our existing interval type scheduling and a cron one, and we can later add things like hourly if cron ends up being too obtuse for humans (it will).

So, I think what should happen is we create a top-level schedule object that takes one of interval or cron, which should be fairly future-proof, as we can add more properties like hourly later.

Note, this probably then also applies to Task Manager, as we attempt to move alerting's scheduling directly to task manager (seems like they are kinda independent right now).

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-stack-services (Team:Stack Services)

@gmmorris
Copy link
Contributor

I'm just gonna put this here: https://crontab.guru/

almost two decades of working with Cron and I still find it to be one of the worst formats I've ever had to work with. 🤣

@pmuellr
Copy link
Member

pmuellr commented Nov 21, 2019

It would be interesting to see how much customers use cron vs the other "easier" watcher schedule triggers like hourly, daily, etc. Easier probably for customers, and implementation-wise. Given our current interval precision, we'd probably want a minutely (urgh!) as well.

@gmmorris
Copy link
Contributor

Discussing this with the @elastic/kibana-stack-services team, we've decided to make an api change in Alerting & Task Manager to allow us to take a generic scheduling configuration for 7.6, instead of the existing interval, which will support receiving an interval.

In a later release we'll add support for cron like scheduling along side interval.

@mikecote
Copy link
Contributor Author

@gmmorris ++ can we create a new issue to change the mapping structure of interval within alerting / task manager for 7.6? You can add it to the 7.6 alerting bucket. Similar to what we discussed, we'll put the capability in place for it by simply changing how we store the value in alerts / task manager.

@gmmorris
Copy link
Contributor

@gmmorris ++ can we create a new issue to change the mapping structure of interval within alerting / task manager for 7.6? You can add it to the 7.6 alerting bucket. Similar to what we discussed, we'll put the capability in place for it by simply changing how we store the value in alerts / task manager.

No prob ;)

@bmcconaghy bmcconaghy added Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) and removed Team:Stack Services labels Dec 12, 2019
@gmmorris gmmorris self-assigned this Dec 17, 2019
@cpmoore
Copy link

cpmoore commented Jun 12, 2020

It would be nice to be able to add blackout periods too. Sometimes it’s easier to say when an alert shouldn’t fire, than when it should.
Do we want to take into account holidays too?

@arisonl
Copy link
Contributor

arisonl commented Jun 15, 2020

Users need the ability to schedule alerts at a specific time every day, at their local time and automatically adjusting to DST changes.

@mikecote mikecote added the R&D Research and development ticket (not meant to produce code, but to make a decision) label Sep 9, 2020
@mikecote
Copy link
Contributor Author

mikecote commented Feb 4, 2021

Moving from 7.x - Candidates to 8.x - Candidates (Backlog) after the latest 7.x planning session.

@gmmorris gmmorris added the Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework label Jul 1, 2021
@gmmorris gmmorris added the loe:needs-research This issue requires some research before it can be worked on or estimated label Jul 14, 2021
@gmmorris gmmorris added the estimate:needs-research Estimated as too large and requires research to break down into workable issues label Aug 18, 2021
@gmmorris gmmorris removed the loe:needs-research This issue requires some research before it can be worked on or estimated label Sep 2, 2021
@kobelb kobelb added the needs-team Issues missing a team label label Jan 31, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Jan 31, 2022
@mikecote
Copy link
Contributor Author

From: #132265 (closed in favour of this issue).

Describe the feature:
Currently you can specify how often you would like a rule to run in terms of minutes, hours, days. It would be nice to be able to select a specific set of days or hours or minutes that you could have a rule run. It would add a lot more flexibility to the Rule system.

Describe a specific use case for the feature:
It would be nice to be able to have a Rule run only Monday-Friday when data collection is occurring without having to manually disable a rule at the end of the work week. We have rules set up to notify us of a 24 hour data outage for a specific data type. This data type is not collected over the weekend so we end up with alerts being triggered over the weekend; false positives.

@timorkal
Copy link

timorkal commented Feb 5, 2023

Any progress on this matter?

@mikecote
Copy link
Contributor Author

mikecote commented May 4, 2023

cc @shanisagiv1. We can probably re-use rrule that is used for maintenance windows and snoozing for this.

@BenB196
Copy link

BenB196 commented Sep 26, 2023

Recently ran into a use case where this would have been helpful. Need to run a rule once every 24 hours within a given time window.

Had to do some manual effort to disable/enable the rule around the window to get the rule's execution to "sync" to it.

@Erikg346
Copy link

Erikg346 commented Apr 2, 2024

Still need this +1

@shanisagiv1
Copy link

We can probably re-use rrule that is used for maintenance windows and snoozing for this.
@mikecote can you pls elaborate? Thanks

@erin-bristow
Copy link

+1, this feature would be very helpful

@Erikg346
Copy link

Is there an update on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
estimate:needs-research Estimated as too large and requires research to break down into workable issues Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework Feature:Alerting Feature:Task Manager R&D Research and development ticket (not meant to produce code, but to make a decision) Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
No open projects
Development

No branches or pull requests