🔎 Open source distributed and RESTful search engine.
Go to file
uboness f6c17bd802 Added a transform construct to actions
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
2015-03-04 03:20:17 +01:00
dev-tools Add missing license check files. 2014-11-07 10:57:59 +00:00
src Added a transform construct to actions 2015-03-04 03:20:17 +01:00
LICENSE.txt Initial X-Pack commit 2018-04-20 14:16:58 -07:00
README.asciidoc Update README.asciidoc 2015-02-21 13:03:13 +01:00
all-signatures.txt [cleanup] - added forbidden apis mvn plugin 2015-02-17 16:31:18 +01:00
core-signatures.txt [cleanup] - added forbidden apis mvn plugin 2015-02-17 16:31:18 +01:00
pom.xml [email] fixed bugs and added unit tests 2015-02-24 12:27:13 +02:00
test-signatures.txt [cleanup] - added forbidden apis mvn plugin 2015-02-17 16:31:18 +01:00
tests.policy Build: Configure randomizedtesting properly 2014-11-07 14:24:56 +01:00

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[]