mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-03-09 14:34:43 +00:00
- 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
= 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[]
Description
Languages
Java
99.5%
Groovy
0.4%