Commit fff0775d authored by Jochen Kressin's avatar Jochen Kressin
Browse files

formatting

parent 42adf8b1
......@@ -30,8 +30,6 @@ POST /_signals/watch/{watch_id}/_execute
Immediately executes a watch and returns status information in the HTTP response. The watch can be specified in the request body. Alternatively, the watch to be executed can be specified by y the `{watch_id}` path parameter.
## Path Parameters
**{watch_id}** The id of the watch to be executed. Optional. If not specified, the watch needs to be specified in the request body.
......@@ -43,6 +41,7 @@ The request body can contain a JSON document specifying further options for exec
The supported attributes of the JSON document are these:
**record_execution** If true, the result of the execution is stored in the watch log index just like it happens for a normal scheduled execution. Optional. Default: false
**watch** The watch to be executed as JSON document. Must be specified if no `{watch_id}` path parameter is given.
## Responses
......@@ -119,6 +118,9 @@ The watch REST API is tenant-aware. Each Signals tenant has its own separate set
For being able to access the endpoint, the user needs to have the privilege `cluster:admin:searchguard:tenant:signals:watch/execute` for the currently selected tenant.
This permission is included in the following [built-in action groups](security_permissions.md):
* SGS\_SIGNALS\_WATCH\_EXECUTE
## Examples
......
---
title: GET watch
title: Get watch
html_title: Getting a watch with the REST API
slug: elasticsearch-alerting-rest-api-watch-get
category: signals-rest
......@@ -53,8 +53,13 @@ The watch REST API is tenant-aware. Each Signals tenant has its own separate set
## Permissions
For being able to access the endpoint, the user needs to have the privilege `cluster:admin:searchguard:tenant:signals:watch/get` for the currently selected tenant.
To access the endpoint, the user needs to have the privilege `cluster:admin:searchguard:tenant:signals:watch/get` for the currently selected tenant.
This permission is included in the following [built-in action groups](security_permissions.md):
* SGS\_SIGNALS\_ALL
* SGS\_SIGNALS\_WATCH\_MANAGE
* SGS\_SIGNALS\_WATCH\_READ
## Examples
......
---
title: PUT watch
title: Put watch
html_title: Creating a watch with the REST API
slug: elasticsearch-alerting-rest-api-watch-put
category: signals-rest
......@@ -25,7 +25,7 @@ PUT /_signals/watch/{watch_id}
Stores or updates a watch identified by the `{watch_id}` path parameter. By default, the watch will be active and scheduled for execution.
**Important** When a watch is created or updated, a snapshot of the privileges of the user performing the operation will be stored with the watch. When the stored watch is executed, it will have exactly these privileges. If a user modifies a watch created by another user, the user must ensure that they still have enough privileges to allow successful execution of the watch.
**Important** When a watch is created or updated, a snapshot of the privileges of the user performing the operation will be stored with the watch. When the stored watch is executed, it will have exactly these privileges. If a user modifies a watch created by another user, the user must ensure that they still have enough privileges to allow successful execution of the watch. See also the chapter on the [security execution context](security_execution_context.md).
## Path Parameters
......@@ -35,8 +35,6 @@ Stores or updates a watch identified by the `{watch_id}` path parameter. By defa
The watch needs to be specified as JSON document in the request body.
See TODO for details on the structure of watches.
## Responses
### 200 OK
......@@ -75,6 +73,10 @@ The watch REST API is tenant-aware. Each Signals tenant has its own separate set
For being able to access the endpoint, the user needs to have the privilege `cluster:admin:searchguard:tenant:signals:watch/put` for the currently selected tenant.
This permission is included in the following [built-in action groups](security_permissions.md):
* SGS\_SIGNALS\_ALL
* SGS\_SIGNALS\_WATCH\_MANAGE
## Examples
......
......@@ -27,7 +27,7 @@ GET /_signals/watch/_search
POST /_signals/watch/_search
```
Searches for watches. Search criteria and options can be specified in a manner similar to the ElasticSearch document search REST API.
Searches for watches. Search criteria and options can be specified in a manner similar to the Elasticsearch document search REST API.
Both the GET and the POST HTTP method can be used with the same effect.
......@@ -50,6 +50,7 @@ If no request body is specified, all watches configured for the currently select
Important attributes of the request body are:
**query:** An ES document query.
**sort:** Specifies the attributes by which the result shall be sorted.
......@@ -71,6 +72,11 @@ The watch REST API is tenant-aware. Each Signals tenant has its own separate set
For being able to access the endpoint, the user needs to have the privilege `cluster:admin:searchguard:tenant:signals:watch/search` for the currently selected tenant.
This permission is included in the following [built-in action groups](security_permissions.md):
* SGS\_SIGNALS\_ALL
* SGS\_SIGNALS\_WATCH\_MANAGE
* SGS\_SIGNALS\_WATCH\_READ
## Examples
......
......@@ -3,7 +3,7 @@ title: Sample Watches
html_title: Sample Watches of Signals Alerting
slug: elasticsearch-alerting-watches-sample
category: signals
order: 1100
order: 210
layout: docs
edition: preview
description:
......
......@@ -48,8 +48,7 @@ To throttle the execution of an action, you can set a `throttle_period` in the a
In this example, regardless how often the condition in the watch definition fires, the email action will be executed only once per hour.
On other words, if you define a throttle period, the action will not fire if the last execution time is in the time window of the throttle period.
On other words, if you define a throttle period, the action will not fire if the last time the action was executed is withing the timeframe of the throttle period.
## Acknowledgement
......
......@@ -26,4 +26,4 @@ You can use painless scripts to either
* transform your data in any execution context
* calculate values and store them in a new execution context
Both transformations and calculations are implemented as inline or stored painless scripts that operate on the execution context data. You can use the full power of painless to massage the data anyway you want.
\ No newline at end of file
Both transformations and calculations are implemented as inline or stored painless scripts that operate on the execution runtime data. You can use the full power of painless to massage the data any way you want.
\ No newline at end of file
......@@ -24,7 +24,7 @@ A calculation is a script that
As opposed to [Transformations](transformations_transformations.md), Calculation scripts do not have a return statement and do not need to define a target.
Instead, they access and manipulate the watch execution context directly.
Instead, they access and manipulate the watch runtime data directly.
Calculations can be used
......@@ -75,7 +75,7 @@ All scripts have full access to the data stored in the execution context. The da
Caclulations can also be used with actions. Each action can define it's own chain of `check`s, including calculations. The following snippets shows how to combine a calculation and a condition specific to an action. The calculation is the same as above, and the condition will execute the action only if the average memory consumption is above a certain threshold.
Note that you can also use the calculated value in the text_body of the email action. Actions use moustache to render the output. Moustache has the same access to the execution context data as scripts and conditions.
Note that you can also use the calculated value in the text_body of the email action. Actions use Mustache to render the output. Mustache has the same access to the execution context data as scripts and conditions.
```
{
......
......@@ -18,9 +18,9 @@ description:
A transformation is a script that
* has access to the execution context payload data
* has access to the runtime data
* performs one or more painless statements
* replaces the
* replaces the runtime data in the `target` context
As opposed to [Calculations](transformations_calculations.md), Transformation scripts have a return statement and need to define the target context where the transformed values are written back to.
......@@ -29,9 +29,9 @@ If the target context already exists, it is overwritten. If not, a new one is cr
Transformations can be used
* in the `check`s section of a watch definition
* the transformation is executed before any actions are executed. Changes to the execution context payload data are visible for all subsequent steps and for all actions
* the transformation is executed before any actions are executed. Changes to the execution context runtime data are visible for all subsequent steps and for all actions
* in the `check`s section of any action
* the transformation is executed before the action is executed. Changes to the execution context payload data are only applied to the payload for that specific action.
* the transformation is executed before the action is executed. Changes to the execution context runtime data are only applied for that specific action.
## Using inline scripts
......@@ -82,7 +82,7 @@ All scripts have full access to the runtime data. The data in the execution cont
Transformations can also be used with actions. Each action can define it's own chain of `check`s, including transformation.
The next example runs a transformation that extract the hits from an Elasticsearch result set prior to writing it back to another Elasticsearch index via an [Index Action](actions_index.md).
The next example runs a transformation that extracts the hits from an Elasticsearch result set prior to writing it back to another Elasticsearch index via an [Index Action](actions_index.md).
```
{
......
......@@ -112,7 +112,7 @@ To create a weekly trigger, you define the weekday and the time:
"schedule": {
"weekly": {
"on": ["thursday", "friday"],
"at": ["14:40:00", "17:00:00"]
"at": ["14:00:00", "17:00:00"]
}
}
},
......@@ -125,7 +125,7 @@ This trigger will fire each Thursday and Friday at 2pm and 5pm.
### Creating multiple weekly triggers
To create a weekly trigger, you define the weekday and the time:
To create multiple weekly trigger, you define the weekday and the time like:
```json
{
......@@ -234,6 +234,4 @@ This trigger will fire every 10 seconds.
"checks": [],
"actions": [],
}
```
This trigger will fire every 10 seconds.
\ No newline at end of file
```
\ No newline at end of file
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment