You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently watcher provides two mechanisms of throttling, see here. A watch or an action inside of a watch can be configured to be throttled for a certain amount of time, so that you do not send out emails every few minutes. Or a watch/action can be acknowledged via an API, so that it needs to become false first to ever fire again.
However, there is another use-case, where you would want to mix the two in order to silence a watch/action for a certain amount of time before the watch/action will be firing again.
A possible solution to this could be to extend the ACK Watch API to provide a body, that contains an expiry date for the watch or for certain actions.
Right you one can call
POST _xpack/watcher/watch/my_watch/_ack/action1,action2
POST _xpack/watcher/watch/my_watch/_ack
Adding a body like this
POST _xpack/watcher/watch/my_watch/_ack
{
"expiry_date" : "2018-09-25T12:12:12Z"
}
POST _xpack/watcher/watch/my_watch/_ack
{
"expiry_after" : "25m"
}
would add a time based throttling instead of an ack based one.
The text was updated successfully, but these errors were encountered:
This has been open for quite a while, and hasn't had a lot of interest. For now I'm going to close this as something we aren't planning on implementing. We can re-open it later if needed.
Describe the feature:
Currently watcher provides two mechanisms of throttling, see here. A watch or an action inside of a watch can be configured to be throttled for a certain amount of time, so that you do not send out emails every few minutes. Or a watch/action can be acknowledged via an API, so that it needs to become false first to ever fire again.
However, there is another use-case, where you would want to mix the two in order to silence a watch/action for a certain amount of time before the watch/action will be firing again.
A possible solution to this could be to extend the
ACK Watch API
to provide a body, that contains an expiry date for the watch or for certain actions.Right you one can call
Adding a body like this
would add a time based throttling instead of an ack based one.
The text was updated successfully, but these errors were encountered: