something seems to be broken... either in the integration test infra or somewhere else.. .investigation required
Original commit: elastic/x-pack-elasticsearch@c27bc41ef4
- Added watch CRUD tests + cleanup
- Changed and aligned terminology across the board. No more "watch name".. from now on we'll refer to it as "watch id" (aligned with the public APIs). Also the templates now refer to `"{{ctx.watch_id}}"` (instead of `"{{ctx.watch_name}}"`)
- cleaned up the Response constructs (removed dependency on index/delete/get responses)
Fixeselastic/elasticsearch#202
Original commit: elastic/x-pack-elasticsearch@3296a69128
Super useful when dealing with the `cron` schedule. It enables to:
1. validate a cron expression. If the cron expression is incorrect it will try to output a descriptive/guiding error message
2. show future times in which the cron expression will be triggered (based on the current time)
When deployed, once can access this tool from ES_HOME by `bin/watcher/croneval`
Also updated the docs
Original commit: elastic/x-pack-elasticsearch@2666c32a69
This change adds support for testing all watcher REST endpoints.
It also updates the api docs to be current with the latest code.
Change GetWatchResponse to only have the information in needs
GetWatchResponse used to contain a GetResponse this is not needed. Now it just contains the needed fields.
Closeselastic/elasticsearch#35
Original commit: elastic/x-pack-elasticsearch@905c5da318
- When the license is disabled, all actions of all watches are throttled, and all watcher APIs are blocked.
- before license expiry we're logging warning messages to the standard log file.
- Added a check on startup verifying the installed license plugin confirms to the min compatibility requirement of watcher
- Added a check on startup verifying the installed shield plugin (if one is installed) confirms to the min compatibility requirement of watcher
- Fixed a bug in simple input deserialization where it expected a `payload` field that should be there.
- Fixed a bug in `WatcherServiceResponse` where the acknowledged state wasn't de/serialized
Closeselastic/elasticsearch#30
Original commit: elastic/x-pack-elasticsearch@35dcaf4feb
Mainly useful for testing & debugging, but might be even useful as an actual action in production.
(for now, we won't document it)
Original commit: elastic/x-pack-elasticsearch@726049cece
- actions are not identified by a unique id. The actions in a "watch" definition are now keyed (instead of an array)
- the `ActionWrapper` is now a construct that holds: and action, the id of the action and optionally a transform
- the `webhook` action is now structured based on the templated http request it holds (no need for extra `request` element there`
- the `webhook` reponse holds the http response (not the `status` and `body` directly)
- the action builders now accept an `id` when created
- introduced `WatchSourceBuilders` for quickly access various source builders
- introduced `Template.SourceBuilder` to help building a template
- changed templated http request builder to accept template source builders (instead of templates directly)
- changed `HttpResponse` to accept the body as a `ByteReference` in the ctor (this construct used to be in an inconsistent state holding an input stream that could have already been read)
Original commit: elastic/x-pack-elasticsearch@296350b6a8
- now enables defining `types` (for document types)
- enables defining `types` and `indices` as comma-delimited strings (not just string arrays)
- aligned the parsing in `WatcherUtils` with the way we're parsing xcontent across the board (e.g. using `ParseField`)
- Added additional unit test to test deserialization
Original commit: elastic/x-pack-elasticsearch@5491b85f75
This commit enables the script transform return any value. If the value is of type `Map` we'll just use it as the payload itself. Otherwise (any other value type) we'll take that value and put it in a map under the `"_value"` key, and that map will be the new payload.
This will simplify writing scripts (as it doesn't require the script to build a map)
Original commit: elastic/x-pack-elasticsearch@73fab7dc2b
This commit fixes two issues.
1. The actual emails that were being sent after getting the defaults applied were not being returned as part of EmailSent
2. There was a possible NPE when writing an `Email` if from or to was null.
Closeselastic/elasticsearch#147
Original commit: elastic/x-pack-elasticsearch@0468280090
This commit adds tests for the webhook and index actions.
Also adds docs for the webhook and index actions and fixes url escaping of webhook action urls.
Original commit: elastic/x-pack-elasticsearch@b70435b198
This commit adds support for rest tests using the same yaml and json formatting as for core elasticsearch.
Also added is support for shield in the rest tests.
Original commit: elastic/x-pack-elasticsearch@bbeb9c0fc9
The http input allows to let any http interface be the input for a watch.
The http input can be configured with the following options:
* `method` - Optional http method. (default to GET)
* `host` - The host of the http service.
* `port` - The port of the http service.
* `path` - The url path.
* `params` - Optional url query string options.
* `header` - Optional http header.
* `auth` - Optional authentication http heads.
* `body` - Optional body
The response of the http request is expected to be valid json.
Closeselastic/elasticsearch#157
Original commit: elastic/x-pack-elasticsearch@0b1f122615
Today every `watch` is associated with a `schedule`. When the watch is added to the system, its schedule is registered with the `scheduler` that is responsible to trigger the watch based on the schedule. This is effectively time based triggering of a `watch`.
Thinking about it further, triggering a watch is a higher abstraction than the schedule. Many things can potentially trigger a watch - a schedule (or time based triggering) is just one example of such trigger.
A `Trigger` was added to provide this abstraction. A `watch` is associated with a `trigger` not with a `schedule` directly. One type of `trigger` that can be set on a watch is a `schedule`.
This abstraction will enable us much flexibility in the future as we'll be able to add other types of triggers that are not necessarily based on time. 3 examples:
- we're planning to have a API that executes triggers on demand (rather than waiting for them to be triggered "naturally"). We could have a `"passive"` trigger with the intention to have a watch that can only be executed on demand. Today (with schedule only) you can achieve this by setting a `cron` schedule that is set to trigger very far in the future - but it's a hack.
- In the future we plan to have changes API in elasticsearch. An interesting trigger that we might want to add is `"changes"` - an ESP (event-stream processing) trigger that listens to all (data) events in the changes API, processes them and using some sort of state machine decides to trigger a watch based on some condition.
- With Shield we have audit trails. currently the only audit trail that is supported is log based (access logs). Another audit trail we'll add soon will be index based (indexing the audit info to elasticsearch). In the future, we might want to have `watcher` extend shield and add a `"watcher"` audit trail. this will effectively be a `"audit"` trigger that will trigger watches based on events arriving in the audit trail (think about notifying at real-time about a potential DDoS attack)
To support this change, we needed to change existing and introduce new constructs:
- A `Trigger` defines the logic of when a watch should be triggered
- A `TriggerEngine` is responsible for executing the logic defined by the `Trigger`
- A `TriggerEvent` is created whenever the engine triggers the trigger. The event holds relevant information (may be different for every trigger depending on its type and nature).
- A `TriggerService` manages trigger engines.
We currently have a single engine implementation - a `"scheduler"` trigger
- `ScheduleTrigger` defines a clock/calendar based schedule on which a watch should be triggered
- `QuartzScheduleEngine` a trigger engine that runs quartz scheduler which triggers the registered schedules.
- `ScheduleTriggerEvent` holds the `triggered_time` (the time the trigger was actually triggered) and the `scheduled_time` (the time the trigger was scheduled to trigger)
- Updated the docs
Closeselastic/elasticsearch#158
Original commit: elastic/x-pack-elasticsearch@5be20917cc
- Change action names to be aligned with Shield. All actions are categorized as `cluster management`.. the read actions (get & stats) are also also categorized as `cluster monitoring`.
- Added `ShieldIntegration` and `WatcherShieldModule` to handle all the integration points.
- We have a new internal shield user `__watcher_user` that will be the actor behind all the watcher interal action executions (managing the `.watches` and `.watch_history` indices
- This integration revealed a bug where the watcher plugin would not wire correctly with transport clients. This is now fixed with the introduction of a dedicated `TransportClientWatcherModule`
- Added docs
Closeselastic/elasticsearch#43
Original commit: elastic/x-pack-elasticsearch@26e9b0da06
- `alerts` package is now `watcher` package
- we no longer use the term `Alert`, but instead we use `Watch`
- documentation still needs to be updated
Original commit: elastic/x-pack-elasticsearch@1225edf7e3
SearchInput tests were failing locally for me in DEBUG because they weren't setting a valid alert on the ExecutionContext which was causing
the debug log messages in the SearchInput.execute method to NPE. I've added a dummy Alert to the context to fix things.
`
Original commit: elastic/x-pack-elasticsearch@2d744fdb7b
Also:
- removed `throttle` file (throttling is not covered in `alert-anatomy` page)
- fixed ctx model parameters in templates/scripts to use the `ctx` prefix.
- added a dediated section in alert-anatomy about execution context as template/script model
- wrote first page of `transform` section
Original commit: elastic/x-pack-elasticsearch@471ca7f0d9
Changed ClientProxy to be return responses instead of ActionFutures and removed builders. This helps with mocking.
Original commit: elastic/x-pack-elasticsearch@bfc36d9405
The idea behind a time warp mode is that while it's enabled the time related constructs in the alerts module are replaced with a mock test friendly version.. so we'll be able to control time and therefore avoid sleeping the threads.
In time warp mode:
- The `SchedulerMock` is used to manually fire jobs
- The `ClockMock` is used to set and fast forward time
- The alerts are executed on the same thread as the scheduler mock... so we don't have to deal with async nature at all. This is accomplished by the added `AlertsExecutor` abstraction.
By default, the time warp mode is enabled and tests run in it. If a test must not use the time warp mode, it is possible to add `@TimeWarped(false)` annotation to the test and it will then run with the standard scheduler & clock. It is also possible to disable this mode all together by running the tests with `-Dtests.timewarp=false`.
All the updated tests now work in both modes (whether the time warp mode is dis/enabled). This is important as on the server we would like to run the tests outside of this mode as well, but locally we'd like to run them with time warped enabled (so they'll be faster)
Also, cleaned up the tests.. we now only do `assertThat(...)` calls (no `assertTrue` or `assertEquals`... for consistency sake)
Original commit: elastic/x-pack-elasticsearch@11e09f6dea
Bill Hwang
uboness
Brian Murphy
Martijn van Groningen