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
The following additional information will be shown per watch that is executing: `watch_id`, `watch_execution_id`, `triggered_time`, `execution_time`, `execution_phase` (whether it is execution an input, condition or an action) and `stack_trace` (useful for us when a customer reports an issue :) ).
The stats api will by default include the executing watches in the response. In order to control this, a `metric` option has been added, which can be specified as query string argument or as last path element in the stats api url. By default the watcher stats API will only return the basic statistics that are already there.
The `metric` option has the following values:
* `current_watches` - Include the current executing watches in the response.
* `_all` - Include all metrics in the stats response. Not very useful now, but when we expose more metrics in this api it will be more useful.
Original commit: elastic/x-pack-elasticsearch@093bef9bb3
Until today we could not search on the `met` field in the condition result. The reason for that is that this field was index as part of the condition result type only, and we disable the indexing for all condition results (to avoid mapping conflicts).
This commit pulls the `met` condition one level higher and enables its mapping. For now (beta1) we can live with the duplication of the condition result source (were the `met` is not placed in both the condition result type and on the condition result itself). Later we should remove the duplication though.
An example of a "compare" condition result now looks like:
```
"condition": {
"met": true,
"compare": {
"met": true,
"resolved_value": 1
}
}
```
Original commit: elastic/x-pack-elasticsearch@74a3372c25
A simple `condition` that compares a path into the model in the execution context to a value. The comparison is based on the following possible operators: `eq`, `not_eq`, `lt`, `lte`, `gt`, `gte`.
The following example shows a `compare` condition that checks if the total hits in the payload is greater or equal to 5.
```
{
"compare" : {
"ctx.payload.hits.total" : { "gte" : "5" }
}
}
```
Original commit: elastic/x-pack-elasticsearch@6d4f2bbf10
Fixed the mappings of the index action fields such that the `index` and `type` of the index response won't be analyzed.
Original commit: elastic/x-pack-elasticsearch@5db8bf6a33
rely on http header to be send for Shield authentication
and finally omit the manage_watcher role from the test user.
Original commit: elastic/x-pack-elasticsearch@57a6366119
- Disabled the search request body/template fields as they're too volatile to have mappings (applied for both for `search` input and transform)
- Disabled watch level transform result payload
Original commit: elastic/x-pack-elasticsearch@f69b237234
Holds the name of the version as it is defined in the `pom.xml` (different than the version number that is automatically generated by `WatcherVersion`)
Original commit: elastic/x-pack-elasticsearch@b6cf221f63
This change adds a check to make sure that the license is enabled when starting watcher in the tests.
This avoids a race-condition where a test might run before the license manager had a chance to start.
Original commit: elastic/x-pack-elasticsearch@0b9d0da5d4
I think the escaping done in XMustacheFactory (and by extension JsonEscapingMustacheFactory in core) is broken.
You cannot just escape any control character by sticking a '\' in front of it. For example a new line character it '\n' but this will be rendered as a line break. Simply prepending a '\' to this just results in a '\' and then a new line !
Added support for different escaping strategies based on the XContentType of a template for XMustacheEngine.
Currently only JSON escaping is supported using jackson.JsonStringEncoder.
Templates will be prepended with __<contentType>__:: when the content type is set. If this is set to JSON we will json escape the content.
Fixes: elastic/elasticsearch#404
Original commit: elastic/x-pack-elasticsearch@1400cba659
A truststore should not be required as the default system truststore can be used
to validate certificates that have been signed by most commercial CAs.
Additionally, the HttpClient is now a lifecycle component to prevent out of memory
exceptions when starting up with a bad configuration; when an exception is thrown
in the constructor, Guice will continue to try to create the object until the system runs
out of memory.
Closeselastic/elasticsearch#476
Original commit: elastic/x-pack-elasticsearch@2333e47ac1
Transform results may product different payloads per watch/execution. It means that if the resulted transformed payload is mapped and indexed, there's a high chance for mapping conflicts and thus failures.
For this reason, this commit disables the mapping of all `transform` results (on both the watch and the action levels).
This commit also changes the field name of the transform result from `transform_result` to just `transform` (aligned with other result field names - `input`, `condition` and `actions`)
Fixeselastic/elasticsearch#472
Original commit: elastic/x-pack-elasticsearch@2c6d4f5182
Until now you always needed to define the `actions` in a watch. Even if you didn't want any actions, you had to define and empty objects there.
Now, the `actions` is an optional field. When missing, we default to "no actions"
Original commit: elastic/x-pack-elasticsearch@3d1a961232
Move deduping to `validMonthTimes`
This change dedups the `MonthTimes` in `validMonthTimes` to support this two new methods on `MonthTimes` are added `contains(int,DayTime)` which detects if a given day and DayTime combination is contained in the MonthTime and `intersects(MonthTimes)` which detects if a `MonthTimes` has any day/DayTime combinations contained in this `MonthTimes`.
Original commit: elastic/x-pack-elasticsearch@f68039bc39
Code:
- renamed 'executed_request` back to `request` in the search input/transform result (makes more sense in the context of the overall response structure
- renamed `sent_request` back to `request` in the http input result (makes more sense in the context of the overall response structure)
- renamed `http_status` to `status` in the http input result (makes more sense in the context of the overall response structure)
Docs:
- fixed indentations
- fixed wrong example in put-watch docs (`actions` was shown as an array)
- changed action ids to be lowercased & underscored
Original commit: elastic/x-pack-elasticsearch@6ded0936d5
- Renamed `watch_execution` to `execution_result`
- Renamed `actions_results` to `actions`
- Renamed `input_result` to `input`
- Renamed `condition_result` to `condition`
- Updated the `watch_history.json` template to reflect the changes, also added concrete mappings for action types (such that field that should not be analized will be mapped as `not_analyzed`
- Fixed a bug in `WatchUtils.createSearchRequestFromPrototype` where the document types were ignored.
Also, changed the `actions` (fka `actions_results`) from an object to an array. the action id is not part of the action objects (indicated by the `id` field). For example:
```
{
"actions" : [
{
"id" : "my_email",
"email" : {
...
}
}
]
}
```
The reason for this change is to make the path to the action fields predictable deterministic. With the object structure, where the actions were keyed by their `id`, the path to the action fields depended on the action id, which is unpredictable and continuously changing from one action to another. This made it impossible to properly analyze the action data using aggregations (as aggs require full path into the aggregated fields).
With this change, the mappings of `watch_record` changed as well where the `actions` are not defined as nested type, yet it is still configured to include all the fields in the root object. We do this so in the future, when appropriate support will be added to kibana, it'll be able to apply nested aggregations on the actions, enabling correct/safe multi-dimensional aggregations. In the mean time however, while kibana doesn't support nested aggregations, we still need to have all the fields indexed on the root, so at least a single dimensional aggregations can be safely applied.
Also, change the `input` and `condition` objects in the `watch_record` such that their mappings are disabled. The main reason for this is the fact that a lot of the inputs use elements that can be configured in many ways, but the mappings are too strict to accept it. For example, a template can be configured as a `string` or as an `object`.
Original commit: elastic/x-pack-elasticsearch@83464a0c71
uboness
Martijn van Groningen
Brian Murphy
jaymode
Bill Hwang
Shay Banon