```
"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
- 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
