In certain cases this could cause Watcher to prevent from being started (either automatically or manually):
* The watch of the triggered watch doesn't exist
* The execution service rejected the execution the watch. (due to not enough threads in the thread pool)
If a watch record gets overwritten this means it has been executed before when watcher was running, but we were unable to delete the triggered watch. So we executed the a watch twice with the same trigger event. This can happen if watcher was stopped before because of the node running Watcher unexpectedly stopped (master left, power loss etc.)
In stead of failing to write the watch record, we overwrite it set the state 'executed_multiple_times'.
Closeselastic/elasticsearch#695
Original commit: elastic/x-pack-elasticsearch@20f805cb99
```
Chained input for now works like this
{
"chain" : [
{ "first" : { "simple" : { "foo" : "bar" } } },
{ "second" : { "simple" : { "spam" : "eggs" } } }
]
```
This allows to access the payload via ctx.payload.first.foo for example
The array notation is needed to guarantee order, as JSON itself does not guarantee
order of objects.
Closeselastic/elasticsearch#353
Original commit: elastic/x-pack-elasticsearch@7ab32c43a8
Allows to configure watcher.http.proxy.host and watcher.http.proxy.port properties to
configure a HTTP proxy as well as specify a proxy whenever a HTTP request is executed.
Closeselastic/elasticsearch#587
Original commit: elastic/x-pack-elasticsearch@75ef260fef
The additional setting to specify the configuration path is no longer needed with elasticsearch 2.0, so
we should remove it from the documentation. Also cleans up the installation commands to be in line
with what 2.0 requires.
Original commit: elastic/x-pack-elasticsearch@b269568a67
Today, once you add a watch to watcher, it's always active. Being "active" means that the watch is registered with the trigger engine (scheduled) and will be executed when its trigger is triggered.
Quite often, ppl want to have an option to deactivate/disable a registered watch. Such that while the watch definition still exists in watcher, it is "inactive" and is never triggered. The only way to do this today is using a "hack" where you can change the watch schedule to a cron expression targeting a really far date in the future (say somewhere around 2050). Again.. this is very hackish and it requires changing the actual definition of the watch (you loose its original trigger).
This commit introduces the notion of an active/inactive watch.. here are the differences between the two states:
- active: the watch is registered with watcher and with the trigger engine and will be executed when its trigger is fired by the engine
- inactive: the watch is registered with watcher, but is not registered with the trigger engine. An inactive watch will never be fired, regardless of its trigger.
This commit also adds two new APIs:
- `_watcher/watch/{id}/_activate`
- `_watcher/watch/{id}/_deactivate`
to activate and deactivate existing watches.
In addition, the Put Watch API now accepts an `active` parameter that indicates the initial state of the put watch (by default set to `true`, i.e. "active").
Closeselastic/elasticsearch#90
Original commit: elastic/x-pack-elasticsearch@37b9ab4d54
This commit adds a new compare condition called “array_compare”. This
condition enables comparing a single resolved value to an array of
resolved values. The value can be compared for equality, non-equality,
and strict and non-strict ordering; the array compare condition will
evaluate to true if the value compares to true with respect to the
specified operator against all (“all”) or at least one (“some”) of the
values in the array specified by “array_path”. Each value in the array
can be resolved to a value using “path” (e.g., “array_path”:
“cx.payload.aggregations.some_field.buckets” and “path”: “doc_count”
would resolve each value in the buckets array to its “doc_count”).
Closeselastic/elasticsearch#345
Original commit: elastic/x-pack-elasticsearch@0d74b4dc11
- This action enables sending notifications to slack channels/users
- Utilizes the incoming webhook API of slack
- Similar to the `email` and `hipchat` actions, multiple slack accounts can be configured, each with its own URL and message defaults
- Slack actions are associated with an account, or if not, they'll be sent via the default account.
- The message itself is very flexible and enables defining simple messages to one or more users and/or one or more channels. For complex message structures, one can use `attachments` as described by the slack API.
Closeselastic/elasticsearch#491
Original commit: elastic/x-pack-elasticsearch@9ecc69c17c
An action capable of sending notifications to rooms and users on hipchat. This actions support three types of HipChat APIs:
- `v1` - The (now deprecated) legacy API where a token can be registered at the group level, and the `v1` version of the API can be used. This API only supports room notification (users cannot be notified). multi-room notification is supported.
- `integration` - The basic integration that one can create in HipChat (it is using the `v2` API version), where notifications can be sent to a single room. User notification is unsupported by this API
- `user` - this API uses an API token of a specific user. An admin user can create an API token and configure it to have access to room notification and user private messaging. This API supports multi-room and multi-user notifications.
The settings for `hipchat` are very similar to the `email` infrastructure in nature. It is possible to configure multiple/different hipchat account, each is associated with the api type (a.k.a profile) - can be `v1`, `integration` or `user`, and the respective `auth_token`. When configuring the action in the watch, one can specify what hipchat account they would like to use (when not specifying an account, the `default_account` will be used). Each account can also specify its own unique `host`/`port` for the hipchat server - for full flexibility.
Closeselastic/elasticsearch#462
Original commit: elastic/x-pack-elasticsearch@9d9ee13542
This commit changes the groupId to the above mentioned one
so that S3 uploads will end up in the right bucket. This will
allow the Elasticsearch plugin manager to install the commercial
plugins like
```
bin/plugin install {watcher,shield,license,marvel}
```
like the official ones.
Original commit: elastic/x-pack-elasticsearch@642f1f006a
debadair
uboness
Chris Earle
Martijn van Groningen
Alexander Reelsen
Clinton Gormley
jaymode
Rashmi Kulkarni
DeDe Morton
Jason Tedor
Shaunak Kashyap