e0a70722e0
Until now, acking and throttling functionality was applied at the watch level. This has major drawbacks in different aspects: - When multiple actions are defined on a watch, acking a watch effectively acks all the actions. This is conceptually wrong. Say you have two actions: `email` and `index`. It's very likely you'd like to ack the email action (to avoid receiving too many emails) but at the same time continue indexing the data in the `index` action. Right now it's not possible. - Different actions types may require different throttling. An `email` action probably needs a longer throttle period compared to an `index` action. Also for different `webhook` actions, the throttling is ultimately determined by the 3rd party system that is called. This commit changes how we do throttling & acking. Moving this functionality to the action level. Now, when acking, each action in the watch will be acked separately. During executiong, each action will determine whether it needs to be throttled or not. The throttler is not associated with the action, not with the watch. The throttle period was enhanced. There is a default throttle period that is configured for watcher as a whole (using the `watcher.execution.default_throttle_period` setting. Next to that, each `watch` can define its own `throttle_period` that can serve as the default throttle period for the actions in the watch. Lastly, each action can have its own throttle period set. Since the throttler is now an action "thing", the `throttle` package was renamed to `throttler` and moved under the `actions` package. Also, `WatchThrottler` was renamed to `ActionThrottler`. With this change, the `Watch Execute API` changed as well. Now, when executing a watch, you can define an execution mode per action. The execution mode offers 4 types of execution: - `execute`: executes the watch normally (actually executing the action and it may be throttled) - `force_execute`: skips/ignores throttling and executes the watch - `simulate`: simulates the watch execution yet it may be throttled - `force_simulate`: skips/ignores throttling and simulates the watch execution As part of this change, the structure of the watch status changed along with the xconent representing the `watch_record`. A new `ActionStatus` was introduced (as part of the `WatchStatus`) and is always set for every action in the watch. This status holds: - the current state of the action (`ackable`, `awaits_successful_execution`, `acked`) - the last execution state (success/failure + reason) - the last successful execution state - the last throttle state (timestamp + reason) Original commit: elastic/x-pack-elasticsearch@32c2985ed8 |
||
|---|---|---|
| dev-tools | ||
| rest-api-spec | ||
| src | ||
| LICENSE.txt | ||
| README.asciidoc | ||
| all-signatures.txt | ||
| core-signatures.txt | ||
| pom.xml | ||
| test-signatures.txt | ||
| tests.policy | ||
README.asciidoc
= Elasticsearch Watcher Plugin This plugins adds conditioned scheduled tasks features to elasticsearch - such a task is called a `Watch`. You can build the plugin with `mvn package`. The documentation is put in the `docs/` directory.