- 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
- 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
- Introduced `Template` & `Template.Parser` interfaces
- There main template implementation is the `ScriptTemplate` and its parser is bound to `Template.Parser`
- There are also xContent templates - YAML & JSON that just render the model as xContent. (used as a fallback in webhook action)
- updated all actions to use the new template infrastructure
Also
- introduced mockito for unit testing
- removed `WebhookTest` as it was effectively testing the template functionality... we'll add a proper test for teh webhook action in a later commit
Original commit: elastic/x-pack-elasticsearch@34a90e8c2f
This avoids that a single thread will be busy during the time that not all primary shards of the alerts and alert history indices are started.
Also the execution of alert history items that were loaded during initialization will be executed once the AlertService goes into started state, before this was executed once the AlertActionService has started, which could load to failures, because there was a small window of time where the alert manager wasn't started. Executing alert history items with the state search_needed requires the alert manager to be started and that isn't yet the case when the AlertActionService has started.
Closeselastic/elasticsearch#75Closeselastic/elasticsearch#76
Original commit: elastic/x-pack-elasticsearch@a799bc34e3
- fixed the use of the found forbidden APIs
- changed `FiredAlert.State` values to lower case (for consistency sake)
Original commit: elastic/x-pack-elasticsearch@9b3f8383d9
- renamed "trigger" notion to "condition"
- the main parts that make an alert are:
- **schedule** - determines when/how often should the alert be checked
- **condition** - determines whether the alert should execute
- **actions** - define what the alert should do
- the lifecycle terminology of a fired alert changed as well, to the following
- **fired** - the schedule fired an event indicating the alert should be **checked**
- **checked** - the condition associated with the alert was checked - either it was met (indicating the the alert should be executed) or it wasn't (indicating the alert should not be executed)
- **throttled** - although the condition was met, the system decided **not** to execute the alert after all based on the throttling logic
- **executed** - the condition of the alert was met, and the system decided it should not throttle it, thefore the actions of the alert were executed.
- `FiredAlert.State` changed to reflect the new lifecycle (as described above)
Original commit: elastic/x-pack-elasticsearch@d67d13d982
- moved alert execution logic to the history service (the history service now listener to schedule events)
- introduced `AlertLockService` - used by both alerts service and history service to lock alerts across services
- the history service is now responsible for executing the previous "not yet executed" fired alerts.
- renamed `AlertContext` to `ExecutionContext`
- renamed `AlertRun` to `AlertExecution`
- improved actions result parsing logic (`success` field is mandatory)
- renamed the alert history type to `fired_alert` (used to be `alerthistory`)
- renamed fired alert `error_msg` to just `message`.
Original commit: elastic/x-pack-elasticsearch@09f26ce3cf
We were using DateTime without a timezone to pick the history index to write the alert runs to.
This caused tests to fail because we use UTC internally (as we should)
Original commit: elastic/x-pack-elasticsearch@6d6f57fb9e
This change fixes the compilation errors in
`EmailTemplateTest` `WebhookTest` `AlertActionsTest` `AbstractAlertingTests` and `ActionHistoryIndexNameTest`.
Fix alert parsing.
Don't attempt to emit a null body template.
Add inject to parser construction.
Fix Alert serialization.
Fix json template to work with the NWO.
Fix ToXContent of Actions.
Add equals methods to Actions and Schedule to facilitate testing.
Changes after rebase to take new EmailAction into account.
Fix `AlertSerializationTest`
Many serialization fixes.
Fix alerthistory template
This change brings the alert history index template uptodate with the code.
Fix createAlertSource
This change brings createAlertSource uptodate with the NWO
Fix Webhook test
Change default template in webhook action to use the simple constructor.
Shutdown the thread pool in the `EmailActionTest`
Don't try to throttle if this alert has never run before.
Add serialization to AlertRun and fix serialization for FiredAlert
This change also makes all trigger and action results serializable and de-serializable.
Parsers now implement parseResult() and the registries for actions and triggers also have matching calls.
Add alert_run to alert history JSON.
Fix logging in index action.
Fix Ack serialization.
Change payload of index action ... IndexResponse isn't serializing properly.
Fix success of index action.
Fix TimeThrottler to use lastExecutedTime instead of lastRunTime.
Fix ThrottleTest
We don't need to assert busy here. The sleeps should be enough. If they aren't something is wrong.
Horrible hack to get around thread pool issues.
Fix Bootstrap test
Also always request version when loading alert history
Fix bootstrap test and set the correct cron into the future.
Original commit: elastic/x-pack-elasticsearch@d3a6c8c3aa
- Removed the the queue reading in the HistoryService.
- Let the HistoryService use the alerts threadpool directly for executing fired alerts, which will use the internal queueing of ThreadPool is all threads are busy.
- Moved the alert thread pool startup to the start of the history service.
- Enforce versioning check if fired alerts are updated.
Closeselastic/elasticsearch#101
Original commit: elastic/x-pack-elasticsearch@39b0de7112
- Introducing the notion of email account (i.e. smtp account). It is now possible to configure multiple email accounts (in node settings) via which the emails will be sent. The email alert action can be configured with an account name, to indicate which account should be used, if no account is configured, the email will be sent with the _default account_. The default account can also be configured using the `default_account` node setting.
- `InternalEmailService` maintains the email sessions and responsible for sending emails.
- the account settings are dynamic (configurable at runtime)
- `Email` class was introduces to abstract away the email structure (`javax.mail`'s `Message` is not the most intuitive construct to deal with. `Email` enables setting both `text` and `html` content and also support normal and inlined attachments.
- "profiles" were added to support different email message formats. Unfortunately the different email systems don't fully comply to the standards and each has their own way of structuring the mime message (especially when it comes to attachments). The `Profile` enum abstracts this by letting the user define what email system structure it wants to support. we define 4 profiles - `GMAIL`, `MAC`, `OUTLOOK` and `STANDARD`. `STANDARD` is the official way of structuring the mime message according to the different RFC standard (it also serves as the default profile).
- The `EmailAction` only task is to create an `Email` based on the action settings and the payload, and send it via the `EmailService`.
Original commit: elastic/x-pack-elasticsearch@2b893c8127
Represents the context of an alert run. It's passed as an argument to all the different constructs that execute during an alert run - trigger, throttler, transform and action. This will provide each execution phase access to to all the results of the previous phase. It also holds the current payload in the execution.
Action results representing failures now hold the `reason` for the failure. This will provide insight on failed action execution as these messages will end up in the fired alert history.
Original commit: elastic/x-pack-elasticsearch@6846a49247
A payload represents a the payload the is originally created by the trigger and passed all the way down to the executing actions. The action may use this payload during their execution, for example, the email action may use this payload as the model behind the email templats.
A transform represents a transformation of a payload. In its core, it accepts a payload applies a transformation to it and outputs the outcome of the transformation as a payload. This simple design makes transforms chainable, meaning, a list of transformations can be applied in a well defined order to a payload.
The transform is applied on the payload initially generated by the trigger. The output of the transformation will be provided to the actions as a payload when they're executed.
Currently we only have two transform types - `noop` and `search`. The former is a transform construct that doesn't actually do any transformation, but instead outputs the same payload it's applied on. The latter (`search`) perform a search on elasticsearch and uses the output of the search (the search response) as the payload it outputs.
Original commit: elastic/x-pack-elasticsearch@6d40337635
- all alerts are now ackable (there's no way to define an "unackable" alert)
- `Alert.Status` now holds an `ack` that represents the ack status
- `Alert.Status` now holds a `lastThrottle` that represents the state of the last throttle (will be `null` if not throttled yet)
- changed the `Alert.Status.Ack.State` to hold more intuitive values - `awaits_execution`, `ackable` and `acked`
- `Alert.Status` is now streamble
- introduced additional info method on `Alert.Status` (e.g. `executed()`, `triggered()`, `ran()`)
Original commit: elastic/x-pack-elasticsearch@3eda1c211a
This change adds a service to hold the dynamically updateable email settings.
Added logging and made inner settings holding class static.
Original commit: elastic/x-pack-elasticsearch@e1690fa292
Create a `HttpClient` in alerts.support to handle http requests.
`HttpClient` is an injectable AbstractComponent.
Original commit: elastic/x-pack-elasticsearch@8e70962ddf
Renamed AlertRecord to FiredAlert
Refactored the persistence part of FiredAlert out of HistoryService to HistoryStore.
Moved AlertActionState to FiredAlert.State
Original commit: elastic/x-pack-elasticsearch@595c733cfc
This change refactors the old AlertActions code into Actions to mirror the triggers code.
This work also includes the configuration changes and webhook changes from master.
TemplateUtils has been renamed to StringTemplateUtils. References to the old AlertActions code have been removed and updated
to reference the new code.
Action.Result now implements ToXContent
This allows the FiredAlerts to track the history of the actions.
Original commit: elastic/x-pack-elasticsearch@a3d5d3bd4d
We don't really need a generic compound throttler. Instead we now have an `AlertThrottler` that can be configured with optional `AckThrottler` and `PeriodThrottler`.
The logic of what throttler is applied first has therefore moved from the `Alert` to the `AlertThrottler` (back to its natural place)
Original commit: elastic/x-pack-elasticsearch@b81e467c97
- Renamed `AlertingModule` to `AlertsModule`
- Started modularizing the code base.. each module has its own guice module and `AlertsModule` spawn all the sub-modules
- Renamed `*Helper` classes to `*Utils` for consistency sake and moved all utilities to `support` package
- Moved `AlertsPlugin` to the base package (no need for `plugin` package... it just creates noise)
- Moved `State` to be inner enum within `AlertsService` (that's where it belongs)
- Moved all the rest actions to `rest.action` package
Original commit: elastic/x-pack-elasticsearch@4ce9bf8dcd
Instead of having another client interface, the alerts client should be a wrapper around the standard es client. This will make sure that whatever logic that is applied on these std clients will also be applied to any requests/actions that are executed in the alerts client.
Using the es client introduces a cyclic dependency for all those services that use the es client and that are also injected into the transport actions. For this reason, instead of using the es client and script service directory, we're using proxies. The proxies are initialized lazily be a new `InitializationService`.
Also introduced the `AlertsClientModule` and `AlertsTransportModule`
Closeselastic/elasticsearch#56
Original commit: elastic/x-pack-elasticsearch@58990a7c85
Martijn van Groningen
uboness
Brian Murphy