Open mikecote opened 4 years ago
Pinging @elastic/kibana-stack-services (Team:Stack Services)
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. 🤣
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.
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
.
@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 ++ 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 ;)
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?
Users need the ability to schedule alerts at a specific time every day, at their local time and automatically adjusting to DST changes.
Moving from 7.x - Candidates
to 8.x - Candidates (Backlog)
after the latest 7.x planning session.
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.
Any progress on this matter?
cc @shanisagiv1. We can probably re-use rrule that is used for maintenance windows and snoozing for this.
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.
Still need this +1
We can probably re-use rrule that is used for maintenance windows and snoozing for this. @mikecote can you pls elaborate? Thanks
+1, this feature would be very helpful
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 acron
one, and we can later add things likehourly
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 ofinterval
orcron
, which should be fairly future-proof, as we can add more properties likehourly
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).