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