a632d57803
Today every `watch` is associated with a `schedule`. When the watch is added to the system, its schedule is registered with the `scheduler` that is responsible to trigger the watch based on the schedule. This is effectively time based triggering of a `watch`. Thinking about it further, triggering a watch is a higher abstraction than the schedule. Many things can potentially trigger a watch - a schedule (or time based triggering) is just one example of such trigger. A `Trigger` was added to provide this abstraction. A `watch` is associated with a `trigger` not with a `schedule` directly. One type of `trigger` that can be set on a watch is a `schedule`. This abstraction will enable us much flexibility in the future as we'll be able to add other types of triggers that are not necessarily based on time. 3 examples: - we're planning to have a API that executes triggers on demand (rather than waiting for them to be triggered "naturally"). We could have a `"passive"` trigger with the intention to have a watch that can only be executed on demand. Today (with schedule only) you can achieve this by setting a `cron` schedule that is set to trigger very far in the future - but it's a hack. - In the future we plan to have changes API in elasticsearch. An interesting trigger that we might want to add is `"changes"` - an ESP (event-stream processing) trigger that listens to all (data) events in the changes API, processes them and using some sort of state machine decides to trigger a watch based on some condition. - With Shield we have audit trails. currently the only audit trail that is supported is log based (access logs). Another audit trail we'll add soon will be index based (indexing the audit info to elasticsearch). In the future, we might want to have `watcher` extend shield and add a `"watcher"` audit trail. this will effectively be a `"audit"` trigger that will trigger watches based on events arriving in the audit trail (think about notifying at real-time about a potential DDoS attack) To support this change, we needed to change existing and introduce new constructs: - A `Trigger` defines the logic of when a watch should be triggered - A `TriggerEngine` is responsible for executing the logic defined by the `Trigger` - A `TriggerEvent` is created whenever the engine triggers the trigger. The event holds relevant information (may be different for every trigger depending on its type and nature). - A `TriggerService` manages trigger engines. We currently have a single engine implementation - a `"scheduler"` trigger - `ScheduleTrigger` defines a clock/calendar based schedule on which a watch should be triggered - `QuartzScheduleEngine` a trigger engine that runs quartz scheduler which triggers the registered schedules. - `ScheduleTriggerEvent` holds the `triggered_time` (the time the trigger was actually triggered) and the `scheduled_time` (the time the trigger was scheduled to trigger) - Updated the docs Closes elastic/elasticsearch#158 Original commit: elastic/x-pack-elasticsearch@5be20917cc |
||
|---|---|---|
| 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.