elastic / kibana

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

Advance scheduling (cron syntax, etc). #50272

Open mikecote opened 4 years ago

mikecote commented 4 years ago

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 commented 4 years ago

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

gmmorris commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 ;)

cpmoore commented 4 years ago

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 commented 4 years ago

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

mikecote commented 3 years ago

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

mikecote commented 2 years ago

From: https://github.com/elastic/kibana/issues/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 commented 1 year ago

Any progress on this matter?

mikecote commented 1 year ago

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

BenB196 commented 9 months ago

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 commented 3 months ago

Still need this +1

shanisagiv1 commented 3 months ago

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

erin-bristow commented 1 month ago

+1, this feature would be very helpful