- `TimerScheduleTriggerEngine` - a single threaded Java `Timer`based scheduler. "Ticks" every second and checks all the registered schedules.
- `SimpleTickerScheduleTriggerEngine` - a single threaded scheduler. "Ticks" every second and checks all the registered schedules
- `SchedulerScheduleTriggerEngine` - a single threaded engine based on Java's schedule executor service. Here, every job is added as a scheduled task to the executor and each job is managing its own execution times.
- `HashWheelScheduleTriggerEngine` - a single threaded engine based on Netty's `HashWheelTimer`. Like with the `scheduler` above, every job is added as a scheduled task to the executor and each job is managing its own execution times.
Also:
- Added an undocumented feature to configure the schedule engine in the settings using `watcher.trigger.schedule.engine` (optional values right now are `quartz`, `simple`, `timer`, `hashwheel` and `scheduler`)
- `Cron` is a fork/copy of quartz `CronExpression`.. a bit cleaned up though.
- `Schedule` now exposes `nextScheduledTimeAfter` to return the next scheduled time after the given one.
- `CronnableSchedule` is now based on `Cron` (this exposed bugs in the schedule tests where we generated invalid cron expression. Now, since `Cronnable` creates the actual cron, validation is in place to make sure only valid expressions are created)
- While at it... refactored how the thread pool settings are set. Removed it from the plugin class, now each module is responsible for the settings of its own TPs. Also, if the thread pools are already configured in node settings we don't configure our default ones. This will enable users to configure the TPs in `elasticsearch.yml`
- Also updated `CronEvalTool` to work with `DateTime` construct (instead of java's `Date`)
Original commit: elastic/x-pack-elasticsearch@40d107c66e
* Split the action into two constructs: `Input` and `ExecutableInput`. The former holds all the input configuration, the latter can execute the input based on that configuration (an executable input holds an input)
- This the code clearer to understand and maintain.
- This also enabled to pull some common implementation code into the `ExecutableInput` and by that reduce the implementation details of each executable to the minimum required.
* Also, extracted the `Input.Parser` to its own top level class, and renamed it to - `InputFactory`. The main thing that the factory does is: 1) delegate to the parsing to the `Input` class, 2) construct & wire up the `ExecutableInput`.
* With the introduction of `Input`, we no longer need the `SourceBuilder` for inputs. Instead, we have an `Input.Builder` that help you build an input. This is much more intuitive from the client perspective.
* Changed the `request` xcontent field in the http input result to `sent_request` for clarity
* Changed the `request` xcontent field in the search input result to `executed_request` for clarity
Original commit: elastic/x-pack-elasticsearch@63b93f9c7b
The default mustache template that is supported by elasticsearch doesn't support array/list access. This poses a real limitation for watcher as with `search` input, the hits are returned as an array/list. To bypass this limitation, an extra (tedious) step is required in order to transform the hits to a data structure that is supported by mustache.
This commit adds a new mustache script engine - `xmustache` to elasticsearch that supports array/list access in the form of `array.X` where `X` is the index into the array/list. This enables accessing the search results without using a transform. The following example will fetch the `"key"` field of the 3rd hit in the search result: `ctx.payload.hits.hits.3._source.key`.
This array/list support will be added to elasticsearch, but it'll only be available in later versions. For now, the default template in watcher will therefore be `xmustache`.
Added docs for templates
Fixeselastic/elasticsearch#230
Original commit: elastic/x-pack-elasticsearch@b09cad7f8b
The watch metadata is now accessible to the templates and scripts (under `ctx.metadata`).
Also, changed the default email attachment to include the ctx model as a whole (not just the payload). This provides more context to the watch exectuion (e.g. watch id, execution time, metadata, etc...)
Original commit: elastic/x-pack-elasticsearch@c5dde855d2
The `WatchLockService` was not using fair locks. This could result in out of order execution of queue executions of the same watch.
Fork KeydLock tests from core and make global lock fair.
Fixeselastic/elasticsearch#225
Original commit: elastic/x-pack-elasticsearch@77382e09ca
* Split the action into two constructs: `Condition` and `ExecutableCondition`. The former holds all the condition configuration, the latter can execute the condition based on that configuration (an executable condition holds a condition)
- This the code clearer to understand and maintain.
- This also enabled to pull some common implementation code into the `ExecutableCondition` and by that reduce the implementation details of each executable to the minimum required.
* Also, extracted the `Condition.Parser` to its own top level class, and renamed it to - `ConditionFactory`. The main thing that the factory does is: 1) delegate to the parsing to the `Condition` class, 2) construct & wire up the `ExecutableCondition`.
* With the introduction of `Condition`, we no longer need the `SourceBuilder` for conditions. Instead, we have `Condiiton.Builder` that help you build condition. This is much more intuitive from the client perspective.
* Renamed `always_true` condition type to `always`
* Renamed `always_false` condition type to `never`
* Updated docs (also added docs for the `never` condition)
Original commit: elastic/x-pack-elasticsearch@0f8eb494ca
We weren't properly registering the chain or script transforms so that they were accessable from the Watch.parse and PUT Watch APIs.
Original commit: elastic/x-pack-elasticsearch@2a236d62f3
This change makes the default throttle period 5s.
This default can be controlled from config with the parameter `watcher.throttle.period.default_period`.
Added test and updated docs.
Original commit: elastic/x-pack-elasticsearch@cf8f5de724
This change persists the Watch.Status if needed by marking the Status as `dirty` if the status mutates during watch execution.
If the status is dirty it will be persisted at the end of execution while the execution lock is held.
Change record_in_history to record_execution which also controls weither the status will be updated.
Fixeselastic/elasticsearch#222
Original commit: elastic/x-pack-elasticsearch@25869cabf0
There were a few corner cases where a `HistoryStore.put` operation was underway while we were shutting down since we were not holding any lock during this time.
This change adds a ReadWriteLock and uses the ReadLock for updates and put operations and the WriteLock for shutdown.
Also add a lock around the manual execution of a watch since it could change the status.
Fixeselastic/elasticsearch#204
Original commit: elastic/x-pack-elasticsearch@60ef78eff5
If we failed to parse a `Watch` or `WatchRecord` at startup we currently get stuck as this behaviour is undefined.
This commit just adds some logging so we can tell that this is what happened.
Original commit: elastic/x-pack-elasticsearch@aa6d95c172
* Split the action into two constructs: `Action` and `ExecutableAction`. The former holds all the action configuration, the latter can execute the action based on that configuration (an executable action holds an action)
- This the code clearer to understand and maintain.
- This also enabled to pull some common implementation code into the `ExecutableAction` and by that reduce the implementation details of each executable to the minimum required.
* Also, extracted teh `Action.Parser` to its own top level class, and renamed it to - `ActionFactory`. The main thing that the parser does is: 1) delegate to the parsing to the `Action` class, 2) construct & wire up the `ExecutableAction`.
* Cleaned up and aligned the log messages across all actions. Introduced
- introduced parameterized exceptions (now the exception messages are constructed exactly like that log messages - using `{}` params)
- Introduced the notion of `Wid` - Watch (execution) ID`. Now the `WatchExecutionContext` and the `WatchRecord` hold this construct as their ID (instead of an opaque string). The Wid has a well defined structure where it's prefixed with the watch id. This is very helpful to provide context to parsing the different constructs (actions in our case) as when parsing error occurs we can point directly to the place were we found the error (ie. watch id, record id and action id).
* With the introduction of `Action`, we no longer need the `SourceBuilder` for actions. Instead, we have `Action.Builder` that help you build actions. This is much more intuitive from the client perspective.
Original commit: elastic/x-pack-elasticsearch@df22da4e1f
This change adds a new test class that runs the REST tests with the license disabled.
It checks the error message to make sure that all api access is blocked from all the apis we normally test.
Fixeselastic/elasticsearch#193
Original commit: elastic/x-pack-elasticsearch@a70de9b7a7
`
{
"script" : "<script>"
}
`
Should be a valid script condition. This was silently failing to parse creating invalid watches in the system that could not be executed or interacted with except via DELETE.
Added a test for this as well.
Fixeselastic/elasticsearch#191
Original commit: elastic/x-pack-elasticsearch@25ed27bf2e
- Introduced `TemplateEngine` and its only implementation `MustacheTemplateEngine`
- Change `Template` to only hold the template config.. the rendering is now done by the engine
- Introduced `EmailTemplate` that can render itself to an `Email` (given an engine and model)
- Renamed `TemplatedHttpRequest` to `HttpRequestTemplate` and it has a `render` method that given a model and an engine it creates an `HttpRequest` construct.
- also fixed a bug where when the http request is build, the configured scheme wasn't set.
- cleaned up `HttpRequest` - made it immutable and now we use a builder to build it.
- also fixed a bug in `HttpRequest` where the xcontent didn't render the scheme
- Got rid of all old template implementations... also, parsing a template is now simply `Template.parse(...)` (no need for a special `TemplateParser`.
- While at it, change the action builder to only deal with actions and not know anything about the action id. The id is now passed to the watch builder directly when adding an action
Original commit: elastic/x-pack-elasticsearch@1a7acc5868
- What used to be the `HistoryService` is not named `ExecutionService`. In fact, it always was an execution context and was simply named wrong and place in the wrog place in the code.
- A new `execution` package was created, to contain all execution related contsructs which includes the new `ExecutionService`, `WatchExecutionContext`, `WatchExecutor`, `InternalWatchExecutor`.
- The `WatchExecutionContext` role in the execution process was extended to also enable it to "control" the execution. "control" in the sence that it can now provide default results to some of the contructs (for example, it can provide a default input and by that skip the execution of the input). Also, it enables simulating actions (more bellow).
- There are two implementations now of the `WatchExecutionContext`. A `TriggeredExecutionContext` which is used when the trigger service triggers the execution of a watch. And `ManualExecutionContext` enabling to manually execute a watch. The latter, can be configured such that different phases in the normal executions of the watch can be skipped. This is great for simulating a watch execution, that is, executing a watch without actually fully executing the actions (e.g. create the emails that the email action would have normally send, but without actually sending it). Both of these new context implementations also sit in the new `execution` package.
- With the changes described above, the actions now consult the execution context before actually performing their tasks. If the execution context indicates that the action should run in a "simulated" mode, the action will semi execute and return a `Simulated` result. Each action type defines what is "simulated mode" for it. For example, the email action creates the email and renders all its templats but doesn't actually send it, the returned `Email.Simulated` result will contain the email that would have been sent if it was running under normal conditions (non-simulated mode). The `index` action, doesn't actually indexes anything (just creating the index request that would have been executed), and the `webhook` action only creates the HTTP request but doesn't actually send it.
- A new `execute` API was introduced that utilizes all of the above and enables to manually execute registered watches. The API provides all the tools to control what actions are simulated and enables skipping the execution of the watch `input` and `condition`. By default it also skip the recording of the execution in the watch history (though this can be enabled if desired). This API is exposed both by the Java `WatcherClient` and via a dedicated REST endpoint. (documentation around this new API was added as well)
Closeselastic/elasticsearch#149
Original commit: elastic/x-pack-elasticsearch@ee8fe0490a
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
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
Use in:
- Determining the execution time of an alert
- The period throttler to determine the time passed since last execution
Original commit: elastic/x-pack-elasticsearch@9197b86b68
- the transform parser and registry can now parse transform results
- every transform result may have its own format
- the chain transform result outputs the "transformation trail" of all the chained transforms (great tool for debugging)
- removed `Transform.NOOP` - was redundant, when no transform is defined the alert's transform is `null`
- removed `payload` from the `AlertExecution`. Instead, the execution holds the input result, transform result and potentially the transform results of the actions
- changed the xcontent representing a transofrm result to `{ "transform_type" : { "payload" : {...}, ... } }`
- with this change, the `Action` interface is cleaned up (`execute` only accepts the execution context)
Original commit: elastic/x-pack-elasticsearch@6ecf7f2c92
An alert may have multiple actions associated with it, but each action may need to have different view of the data. For example, the email may need a certain model for its templates while the index or webhook actions may need a completely different data structure.
Until now, there's only an option to defina a single `transform` on the alert level that would have applied to all actions. This commit adds
the ability to associate a transform with each action. We still keep the tranform on the alert level (in case all actions need the same transformation, in which case we'd like to avoid repetition).
Original commit: elastic/x-pack-elasticsearch@5493a2179b
Now `Variables.createCtxModel` is responsible for creating the model for scripts & templates across the board. Accessing the payload, alert name, fired time and scheduled fire time is done via the `ctx.` prefix.
Original commit: elastic/x-pack-elasticsearch@443ac17579
Now the script's params in the `script` condition are merged with the payload data into a single variable context to the script execution. The payload data is now accessed using the `payload.` prefix.
Original commit: elastic/x-pack-elasticsearch@e313a6301c
The `AlertSourceBuilder` along with a set of source builder for all the different constructs that make an alert (condition, input, transform and action), provides a structured approach for building an alert from the client side (instead of forcing the clients to use xcontent directory)
- fixed some of the tests to already use these builders (I reckon there are still quite a few that need to be converted.. but we'll do that over time).
- moved all integration tests under `test/integration` package.
- changed the `AlertsTests` to **not** be an integration test... it randomizes the alert structure and makes sure that it can serialize & deserialize itself to/from xcontent.
- fixed small bugs found by the tests
Original commit: elastic/x-pack-elasticsearch@94b76b6fc7
Before we shutdown the alert execution threadpool, which caused us to use a hacky workaround to get the thread pool started again when alerts is going to run again.
Clearing the threadpool's queue is sufficient for stopping fired alerts from being ran. Only fired alerts already being executed by TP will won't be stopped.
Also removed the volatile previousFiredAlerts field, because execution the fired alert doesn't need the AlertService anymore the purpose of this field doesn't exist any more.
Original commit: elastic/x-pack-elasticsearch@6a622b5579
- Also, the search template/script are not populated not just by the fired/scheduled time, but also by the payload
Original commit: elastic/x-pack-elasticsearch@7ca8331a1c
```
"input": {
"search": {
"request": {
"body": {
"query": {
"match_all": {}
}
}
}
}
},
"condition": {
"script": {
"script": "return true"
}
},
```
The result of this in the `alert_execution` looks like :
```
"input_result": {
"search": {
"payload": {
"hits": {
"total": 1,
"hits": [
{
"_type": "my-type",
"_source": {
"field": "value"
},
"_id": "AUujS61M4FTW2U3Ztz5U",
"_index": "my-index",
"_score": 0.30685282
}
],
"max_score": 0.30685282
},
"_shards": {
"total": 5,
"failed": 0,
"successful": 5
},
"timed_out": false,
"took": 1823
},
"request": {
"body": {
"query": {
"match_all": {}
}
}
}
}
}
"condition_result": {
"script": {
"met": true
}
}
```
There are two Inputs currently the `SearchInput` as shown above and a `SimpleInput` that just contains a payload that will be returned in the result.
There are three conditions, the `ScriptCondition` as shown above and an `AlwaysTrueCondition` and AlwaysFalseCondition` condition.
Original commit: elastic/x-pack-elasticsearch@0d8ac24c5a
- Added additional user friendly schedules
- `hourly` - a simple to configure schedule that will fire every hour on one or more specific minutes in the hour
- `daily` - a simple to configure schedule that will fire every day on one or more specific times in the day
- `weekly` - a simple to configure schedule that will fire every week on one or more specific days + times in the week
- `monthly` - a simple to configure schedule that will fire every month on one or more specific days + times in the month
- `yearly` - a simple to configure schedule that will fire every year on one or more specific months + days + times in the year
- `interval` - a simple interval based schedule that will fire every fixed configurable interval (supported units are: seconds, minutes, hours, days and weeks)
- Added unit tests to all the schedules and the schedule registry
- Introduced `Scheduler` as an interface and `InternalScheduler` for the quartz implementation. This will help unit testing other dependent services
- `Scheduler` is now independent of `Alert`. It works with `Job` constructs (`Alert` now implements a `Job`).
- Introduced `SchedulerMock` as a simple `Scheduler` implementation that can be used for unit tests - enables manual triggering of jobs.
- introduced `@Slow` test annotation support in the `pom.xml`
Original commit: elastic/x-pack-elasticsearch@94a8f5ddea
- Introduced `Template` & `Template.Parser` interfaces
- There main template implementation is the `ScriptTemplate` and its parser is bound to `Template.Parser`
- There are also xContent templates - YAML & JSON that just render the model as xContent. (used as a fallback in webhook action)
- updated all actions to use the new template infrastructure
Also
- introduced mockito for unit testing
- removed `WebhookTest` as it was effectively testing the template functionality... we'll add a proper test for teh webhook action in a later commit
Original commit: elastic/x-pack-elasticsearch@34a90e8c2f
This avoids that a single thread will be busy during the time that not all primary shards of the alerts and alert history indices are started.
Also the execution of alert history items that were loaded during initialization will be executed once the AlertService goes into started state, before this was executed once the AlertActionService has started, which could load to failures, because there was a small window of time where the alert manager wasn't started. Executing alert history items with the state search_needed requires the alert manager to be started and that isn't yet the case when the AlertActionService has started.
Closeselastic/elasticsearch#75Closeselastic/elasticsearch#76
Original commit: elastic/x-pack-elasticsearch@a799bc34e3
- fixed the use of the found forbidden APIs
- changed `FiredAlert.State` values to lower case (for consistency sake)
Original commit: elastic/x-pack-elasticsearch@9b3f8383d9
- renamed "trigger" notion to "condition"
- the main parts that make an alert are:
- **schedule** - determines when/how often should the alert be checked
- **condition** - determines whether the alert should execute
- **actions** - define what the alert should do
- the lifecycle terminology of a fired alert changed as well, to the following
- **fired** - the schedule fired an event indicating the alert should be **checked**
- **checked** - the condition associated with the alert was checked - either it was met (indicating the the alert should be executed) or it wasn't (indicating the alert should not be executed)
- **throttled** - although the condition was met, the system decided **not** to execute the alert after all based on the throttling logic
- **executed** - the condition of the alert was met, and the system decided it should not throttle it, thefore the actions of the alert were executed.
- `FiredAlert.State` changed to reflect the new lifecycle (as described above)
Original commit: elastic/x-pack-elasticsearch@d67d13d982
- moved alert execution logic to the history service (the history service now listener to schedule events)
- introduced `AlertLockService` - used by both alerts service and history service to lock alerts across services
- the history service is now responsible for executing the previous "not yet executed" fired alerts.
- renamed `AlertContext` to `ExecutionContext`
- renamed `AlertRun` to `AlertExecution`
- improved actions result parsing logic (`success` field is mandatory)
- renamed the alert history type to `fired_alert` (used to be `alerthistory`)
- renamed fired alert `error_msg` to just `message`.
Original commit: elastic/x-pack-elasticsearch@09f26ce3cf
We were using DateTime without a timezone to pick the history index to write the alert runs to.
This caused tests to fail because we use UTC internally (as we should)
Original commit: elastic/x-pack-elasticsearch@6d6f57fb9e
This change fixes the compilation errors in
`EmailTemplateTest` `WebhookTest` `AlertActionsTest` `AbstractAlertingTests` and `ActionHistoryIndexNameTest`.
Fix alert parsing.
Don't attempt to emit a null body template.
Add inject to parser construction.
Fix Alert serialization.
Fix json template to work with the NWO.
Fix ToXContent of Actions.
Add equals methods to Actions and Schedule to facilitate testing.
Changes after rebase to take new EmailAction into account.
Fix `AlertSerializationTest`
Many serialization fixes.
Fix alerthistory template
This change brings the alert history index template uptodate with the code.
Fix createAlertSource
This change brings createAlertSource uptodate with the NWO
Fix Webhook test
Change default template in webhook action to use the simple constructor.
Shutdown the thread pool in the `EmailActionTest`
Don't try to throttle if this alert has never run before.
Add serialization to AlertRun and fix serialization for FiredAlert
This change also makes all trigger and action results serializable and de-serializable.
Parsers now implement parseResult() and the registries for actions and triggers also have matching calls.
Add alert_run to alert history JSON.
Fix logging in index action.
Fix Ack serialization.
Change payload of index action ... IndexResponse isn't serializing properly.
Fix success of index action.
Fix TimeThrottler to use lastExecutedTime instead of lastRunTime.
Fix ThrottleTest
We don't need to assert busy here. The sleeps should be enough. If they aren't something is wrong.
Horrible hack to get around thread pool issues.
Fix Bootstrap test
Also always request version when loading alert history
Fix bootstrap test and set the correct cron into the future.
Original commit: elastic/x-pack-elasticsearch@d3a6c8c3aa
- Removed the the queue reading in the HistoryService.
- Let the HistoryService use the alerts threadpool directly for executing fired alerts, which will use the internal queueing of ThreadPool is all threads are busy.
- Moved the alert thread pool startup to the start of the history service.
- Enforce versioning check if fired alerts are updated.
Closeselastic/elasticsearch#101
Original commit: elastic/x-pack-elasticsearch@39b0de7112
- Introducing the notion of email account (i.e. smtp account). It is now possible to configure multiple email accounts (in node settings) via which the emails will be sent. The email alert action can be configured with an account name, to indicate which account should be used, if no account is configured, the email will be sent with the _default account_. The default account can also be configured using the `default_account` node setting.
- `InternalEmailService` maintains the email sessions and responsible for sending emails.
- the account settings are dynamic (configurable at runtime)
- `Email` class was introduces to abstract away the email structure (`javax.mail`'s `Message` is not the most intuitive construct to deal with. `Email` enables setting both `text` and `html` content and also support normal and inlined attachments.
- "profiles" were added to support different email message formats. Unfortunately the different email systems don't fully comply to the standards and each has their own way of structuring the mime message (especially when it comes to attachments). The `Profile` enum abstracts this by letting the user define what email system structure it wants to support. we define 4 profiles - `GMAIL`, `MAC`, `OUTLOOK` and `STANDARD`. `STANDARD` is the official way of structuring the mime message according to the different RFC standard (it also serves as the default profile).
- The `EmailAction` only task is to create an `Email` based on the action settings and the payload, and send it via the `EmailService`.
Original commit: elastic/x-pack-elasticsearch@2b893c8127
Represents the context of an alert run. It's passed as an argument to all the different constructs that execute during an alert run - trigger, throttler, transform and action. This will provide each execution phase access to to all the results of the previous phase. It also holds the current payload in the execution.
Action results representing failures now hold the `reason` for the failure. This will provide insight on failed action execution as these messages will end up in the fired alert history.
Original commit: elastic/x-pack-elasticsearch@6846a49247
A payload represents a the payload the is originally created by the trigger and passed all the way down to the executing actions. The action may use this payload during their execution, for example, the email action may use this payload as the model behind the email templats.
A transform represents a transformation of a payload. In its core, it accepts a payload applies a transformation to it and outputs the outcome of the transformation as a payload. This simple design makes transforms chainable, meaning, a list of transformations can be applied in a well defined order to a payload.
The transform is applied on the payload initially generated by the trigger. The output of the transformation will be provided to the actions as a payload when they're executed.
Currently we only have two transform types - `noop` and `search`. The former is a transform construct that doesn't actually do any transformation, but instead outputs the same payload it's applied on. The latter (`search`) perform a search on elasticsearch and uses the output of the search (the search response) as the payload it outputs.
Original commit: elastic/x-pack-elasticsearch@6d40337635
- all alerts are now ackable (there's no way to define an "unackable" alert)
- `Alert.Status` now holds an `ack` that represents the ack status
- `Alert.Status` now holds a `lastThrottle` that represents the state of the last throttle (will be `null` if not throttled yet)
- changed the `Alert.Status.Ack.State` to hold more intuitive values - `awaits_execution`, `ackable` and `acked`
- `Alert.Status` is now streamble
- introduced additional info method on `Alert.Status` (e.g. `executed()`, `triggered()`, `ran()`)
Original commit: elastic/x-pack-elasticsearch@3eda1c211a
This change adds a service to hold the dynamically updateable email settings.
Added logging and made inner settings holding class static.
Original commit: elastic/x-pack-elasticsearch@e1690fa292
Create a `HttpClient` in alerts.support to handle http requests.
`HttpClient` is an injectable AbstractComponent.
Original commit: elastic/x-pack-elasticsearch@8e70962ddf
Renamed AlertRecord to FiredAlert
Refactored the persistence part of FiredAlert out of HistoryService to HistoryStore.
Moved AlertActionState to FiredAlert.State
Original commit: elastic/x-pack-elasticsearch@595c733cfc
This change refactors the old AlertActions code into Actions to mirror the triggers code.
This work also includes the configuration changes and webhook changes from master.
TemplateUtils has been renamed to StringTemplateUtils. References to the old AlertActions code have been removed and updated
to reference the new code.
Action.Result now implements ToXContent
This allows the FiredAlerts to track the history of the actions.
Original commit: elastic/x-pack-elasticsearch@a3d5d3bd4d
We don't really need a generic compound throttler. Instead we now have an `AlertThrottler` that can be configured with optional `AckThrottler` and `PeriodThrottler`.
The logic of what throttler is applied first has therefore moved from the `Alert` to the `AlertThrottler` (back to its natural place)
Original commit: elastic/x-pack-elasticsearch@b81e467c97
- Renamed `AlertingModule` to `AlertsModule`
- Started modularizing the code base.. each module has its own guice module and `AlertsModule` spawn all the sub-modules
- Renamed `*Helper` classes to `*Utils` for consistency sake and moved all utilities to `support` package
- Moved `AlertsPlugin` to the base package (no need for `plugin` package... it just creates noise)
- Moved `State` to be inner enum within `AlertsService` (that's where it belongs)
- Moved all the rest actions to `rest.action` package
Original commit: elastic/x-pack-elasticsearch@4ce9bf8dcd
Instead of having another client interface, the alerts client should be a wrapper around the standard es client. This will make sure that whatever logic that is applied on these std clients will also be applied to any requests/actions that are executed in the alerts client.
Using the es client introduces a cyclic dependency for all those services that use the es client and that are also injected into the transport actions. For this reason, instead of using the es client and script service directory, we're using proxies. The proxies are initialized lazily be a new `InitializationService`.
Also introduced the `AlertsClientModule` and `AlertsTransportModule`
Closeselastic/elasticsearch#56
Original commit: elastic/x-pack-elasticsearch@58990a7c85
The setting was mistyped as 'smpt' when it should have been 'smtp', but
it is better to change it to 'email' to be consistent with the other settings.
Original commit: elastic/x-pack-elasticsearch@0e610d89b5
Add transport actions for configuration.
Add Listener so that components can listen for config changes.
Original commit: elastic/x-pack-elasticsearch@bab02770d9
This commit adds the ConfigurationManager which the components use to load configuration from the index.
The configuration manager exposes an isReady method which components should not start until it is returns true.
Original commit: elastic/x-pack-elasticsearch@96a2f9f44f
This gives us more control over interrupting and joining this thread during stopping, so we have a good moment in time to clear the queue.
Original commit: elastic/x-pack-elasticsearch@ed3f85fa75
This commit makes the alert history index a time based index.
The alert history now is a timebased index prefixed with .alert_history_
with the time fomat YYYY-MM-dd.
This commit makes the alert history index a time based index.
Original commit: elastic/x-pack-elasticsearch@df6d6dee29
- Remove synchronized
- Add STOPPING state
- Expose alert state in stats api
- Let the test framework disable alerting before closing the test cluster
Original commit: elastic/x-pack-elasticsearch@5794f5fd8f
uboness
Brian Murphy
Martijn van Groningen
Bill Hwang
Joe Hillenbrand