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
Martijn van Groningen
uboness
Brian Murphy