The `AlertSourceBuilder` along with a set of source builder for all the different constructs that make an alert (condition, input, transform and action), provides a structured approach for building an alert from the client side (instead of forcing the clients to use xcontent directory)
- fixed some of the tests to already use these builders (I reckon there are still quite a few that need to be converted.. but we'll do that over time).
- moved all integration tests under `test/integration` package.
- changed the `AlertsTests` to **not** be an integration test... it randomizes the alert structure and makes sure that it can serialize & deserialize itself to/from xcontent.
- fixed small bugs found by the tests
Original commit: elastic/x-pack-elasticsearch@94b76b6fc7
Before we shutdown the alert execution threadpool, which caused us to use a hacky workaround to get the thread pool started again when alerts is going to run again.
Clearing the threadpool's queue is sufficient for stopping fired alerts from being ran. Only fired alerts already being executed by TP will won't be stopped.
Also removed the volatile previousFiredAlerts field, because execution the fired alert doesn't need the AlertService anymore the purpose of this field doesn't exist any more.
Original commit: elastic/x-pack-elasticsearch@6a622b5579
tableizing means evaluation is strictly linear time O(inputLength),
but costs #states * alphabet in ram. alphabet here is unicode (64k) so it blows up huge.
With tableize=false, it just means evaluation is O(inputLength * log(numIntervals)).
This is plenty fast for our purposes.
For these same reasons lucene only tableizes ByteRunAutomaton (alphabet size=256)
by default, for CharRunAutomaton it defaults to false.
Ban the trappy RunAutomaton ctor that tableizes. Fix tests using it.
Closeselastic/elasticsearch#739.
Original commit: elastic/x-pack-elasticsearch@28ab66b0ee
A large number of recent test failures have been caused by failure to bind
a port in the range 32900 to 32999. The ports are now tested to see if they
can be bound by this JVM and if not tries to bind another port. This will
decrease the likelihood of a port bind failure but another application could
still bind a port before the node starts up.
Closeselastic/elasticsearch#737
Original commit: elastic/x-pack-elasticsearch@aaf098758f
- 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
REST tests that use expressions as the script language requires the
lucene-expressions library to be loaded.
Original commit: elastic/x-pack-elasticsearch@c0f2b8a4b2
```
"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
This adds a second mode of operation to the ldap realm. This mode of operation
allows for single bind user to be specified. This bind user will be used to
search for user DNs starting from a base DN. The user DN will then be used to
authenticate via a bind operation. The bind user will then search for the user's
groups.
Closeselastic/elasticsearch#552Closeselastic/elasticsearch#323
Original commit: elastic/x-pack-elasticsearch@3338730a64
- 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
If tests are run on the same machine as the ldap server a bind may be
succesfull. This adds a search to the test which should take longer than
1 millisecond for the server to respond.
Original commit: elastic/x-pack-elasticsearch@f37fb912e8
This removes the logging of an exception at the default log level when a incoming request in
the http transport is unencrypted and the http transport expects traffic to be encrypted.
Closeselastic/elasticsearch#561
Original commit: elastic/x-pack-elasticsearch@0cf23e8e9d
This migrates all of the LDAP code off of JNDI and makes use of the UnboundID
SDK to perform LDAP communication. As much as possible the behavior has
remained consistent. The minimum ldap search timeout is now 1s as UnboundID
only accepts this timeout in seconds; previously a value in milliseconds could be
specified.
Closeselastic/elasticsearch#694
Original commit: elastic/x-pack-elasticsearch@dd1c92bf91
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
uboness
Martijn van Groningen
Robert Muir
jaymode
Brian Murphy
Alexander Reelsen