50f4a1c0e3
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 |
||
|---|---|---|
| dev-tools | ||
| src | ||
| LICENSE.txt | ||
| README.asciidoc | ||
| all-signatures.txt | ||
| core-signatures.txt | ||
| pom.xml | ||
| test-signatures.txt | ||
| tests.policy | ||
README.asciidoc
= Elasticsearch Alerts Plugin
This plugins adds alerting features to elasticsearch
You can build the plugin with `mvn package`.
The documentation is put in the `docs/` directory.
== Core Concepts
Alert :: a tuple of: *Schedule*, *Condition* and a list of *Action*s, where the schedule defines when the alert is checked
(see below), the condition checks whether the alert should be executed and the actions define what happens when the alert
is executed.
Schedule :: defines when and how often should the alert be checked (e.g. every 5 minutes, every
first wednesday of the month at noon, etc..)
Input :: defines the source of a payload that can be associated with an alert and is loaded prior to condition check.
The condition can then be checked agaist this data
Condition :: represents a condition based on which a decision is made to execute the alert or not
Action :: defines the actions that are taken when the alert executes
== Alert Events
`checked` :: the `Scheduler` fired an event that caused the condition of the alert to be evaluated
`throttled` :: the alert's condition was checked and met, but a decision was made **not** to **execute* the alert.
This can be based on the throttle period that is associated with the alert, or based on the fact that the
alert was `acked`
`executed` :: the alert's condition was checked and met and no throttling took place - the actions were executed.
`acked` :: the user acked the alert, causing it to stop executing its action until it's condition is not met anymore
== Alert Run Process
image:docs/alert-run.png[]