Commit db44d8a6 authored by Nils Bandener's avatar Nils Bandener
Browse files

Further improvements and cleanups

parent 340e5cb0
......@@ -7,7 +7,7 @@ subcategory: actions
order: 700
layout: docs
edition: beta
description:
description:
---
<!--- Copyright 2019 floragunn GmbH -->
......@@ -31,7 +31,7 @@ Actions are generally invoked if all checks configured for a watch ran with a po
Still, it is possible to configure further action-specific checks. This way, it is for example possible to configure different escalation levels: Certain actions will only be triggered when certain values exceed a further threshold. Also, action-specific checks can be used to prepare further runtime data for the action. Modifications of the runtime data done by action-specific checks are always scoped to this action and are invisible to other actions.
**Note:** By using the severity feature, you can configure actions to be executed only if a certain problem severity was determined before. Also, you can configure resolve actions which get executed if the problem severity decreased. See [Severity](severity.md) for details.
**Note:** By using the severity feature, you can configure actions to be executed only if a certain problem severity was determined before. Also, you can configure resolve actions which get executed if the problem severity decreased. See [Severity](severity.md) for details.
......@@ -51,13 +51,17 @@ These actions are available at the moment:
In order to avoid getting spammed or flooded by automatic notifications caused by actions, Signals provides two mechanisms: Throttling automatically suppresses the repeated execution of actions for a configurable amount of time. Furthermore, users can acknowledge actions which suppresses action execution until the checks of a watch change their state.
For each action, a throttle period can be configured. Throttle periods are time durations during which execution of the particular action will be suppressed after the it was executed. This way, a watch can be configured to be run very frequently in order to get quickly notified about newly commencing situations. Yet, actions would be triggered less frequently – in the frequency configured by the throttle period.
For each action, a `throttle_period` can be configured. Throttle periods are time durations during which execution of the particular action will be suppressed after the it was executed. This way, a watch can be configured to be run very frequently in order to get quickly notified about newly commencing situations. Yet, actions would be triggered less frequently – in the frequency configured by the throttle period.
If actions are throttled, the watches are still executed. The watch log will contain information about the execution and list the respective actions as throttled.
Throttle periods can be either constant time values like `1h` (1 hour) or `10m` (10 minutes). Alternatively, you can specify throttle periods which increase while the situation recognized by the watch persists. These throttle periods are called exponential periods. You also use the `throttle_period` attribute for configuring exponential periods. The initial throttling and the increase is configured using a special syntax of the value. The syntax is `duration ** basis of exponentiation | maximum duration`. For example, the value `1m**2|1h` would pause notifications after the initial notification for these durations: 1 minute, 2 minutes, 4 minutes, 8 minutes, 16 minutes, 32 minutes, 60 minutes. Afterwards, notifications are repeated every 60 minutes until the situation which causes the action is resolved. The specification of a maximum duration is optional, so you can also just write `1m**2`. The maximum duration then defaults to one day.
Supported units for simple throttle periods and exponential throttle periods are m (minutes), h (hours), d (days), w (weeks).
A throttle period can be also specified on the level of a watch. This then serves as a default throttle period for all actions. Actions can still define specific throttle periods, though.
If no explicit throttle period is configured, a default throttle period of 10 seconds is used.
If no explicit throttle period is configured, a default throttle period of 10 seconds is used. This default can be adjusted using the Signals settings. See the section on [Administration](administration.md) for details.
## Acknowledging Actions
......@@ -78,6 +82,7 @@ Especially for notification actions, the first approach is strongly recommended.
For achieving this, you can use for example loops in Mustache templates. This might look like this:
<!-- {% raw %} -->
```json
{
"checks": [
......@@ -101,13 +106,15 @@ For achieving this, you can use for example loops in Mustache templates. This mi
]
}
```
<!-- {% endraw %} -->
In some cases, however, it will get necessary to execute the action for each element of a collection. This can be achieved by setting the `foreach` attribute of an action to a Painless expression producing a collection. The action will be then executed for each element of that collection. To access the current element of the collection, use the property called `item`. The `data` property is still providing a view of the complete runtime data.
In some cases, however, it will get necessary to execute the action for each element of a collection. This can be achieved by setting the `foreach` attribute of an action to a Painless expression producing a collection. The action will be then executed for each element of that collection. To access the current element of the collection, use the property called `item`. The `data` property is still providing a view of the complete runtime data.
In order to avoid actions being accidentially executed on very large collections, the amount of iterations is limited. By default, an action is only executed for the first 100 elements of a collection. This limit can be changed by setting the `foreach_limit` property of an action.
A watch using the `foreach` property might look like this:
<!-- {% raw %} -->
```json
{
"checks": [
......@@ -136,6 +143,7 @@ A watch using the `foreach` property might look like this:
]
}
```
<!-- {% endraw %} -->
## Common Action Properties
......@@ -143,20 +151,17 @@ All action types share a set of common configuration properties. Consider the fo
```json
{
...
"actions": [
{
"type": "email",
"name": "my_email_action",
"checks": [
"checks": [
{
"type": "condition.script",
"source": "data.bad_weather_flights.hits.total.value > 100"
}
],
"throttle_period": "1h",
...
}
]
}
......@@ -164,9 +169,23 @@ All action types share a set of common configuration properties. Consider the fo
The common configuration attributes are:
| Name | Description |
|---|---|
| type | The type of the action. Required. Can be index, email, slack or webhook right now. |
| name | A name identifying this action. Required. |
| checks | Further checks which can gather or transform data and decide whether to execute the actual action. Optional. |
| throttle_period | The throttle period. Optional. Specify the time duration using an *amount*, followed by its *unit*. Supported units are m (minutes), h (hours), d (days), w (weeks). For example, `1h` means one hour. |
**type:** The type of the action. Required. Can be index, email, slack or webhook right now.
**name:** A name identifying this action. Required.
**checks:** Further checks which can gather or transform data and decide whether to execute the actual action. Optional.
**foreach:** Executes the action for each element of a collection. The collection to use is identified by the Painless expression specified for this attribute. Optional see [Processing Collections of Objects in Actions](#Processing Collections of Objects in Actions) for details.
**foreach_limit:** Specifies the maximum allowed number of iterations performed when using `foreach`. Optional. Defaults to 100.
Alert actions (i.e., non-resolve actions) additionally support these properties:
**throttle_period:** The throttle period. Optional. Specify the time duration using an *amount*, followed by its *unit*. Alternatively, specify an exponential throttle period using the syntax *duration*`**`*basis of exponentiation*`|` *maximum duration*. Supported units are m (minutes), h (hours), d (days), w (weeks). For example, `1h` means one hour.
**severity:** Selects the severity levels in which this action shall be executed. Optional. An array of `info`, `warning`, `error`, `fatal`. See the section on [Severity](severity.md) for details.
Resolve actions additionally support these properties:
**resolves_severity:** Selects the severity levels which need to be resolved in order to execute this action. Mandatory. An array of `info`, `warning`, `error`, `fatal`. See the section on [Severity](severity.md) for details.
......@@ -6,7 +6,7 @@ category: actions
order: 200
layout: docs
edition: beta
description:
description:
---
<!--- Copyright 2019 floragunn GmbH -->
......@@ -20,16 +20,15 @@ Use e-mail actions to send e-mail notifications from watches. You can use Mustac
## Prerequisites
In order to use e-mail actions, you need to configure an SMTP server using the [accounts registry](accounts.md) of Signals.
In order to use e-mail actions, you need to configure an SMTP server using the [accounts registry](accounts.md) of Signals.
## Basic Functionality
A basic e-mail action looks like this:
<!-- {% raw %} -->
```json
{
/* ... */
"actions": [
{
"type": "email",
......@@ -43,6 +42,7 @@ A basic e-mail action looks like this:
]
}
```
<!-- {% endraw %} -->
The basic configuration attributes are:
......@@ -62,10 +62,4 @@ The basic configuration attributes are:
**subject:** Defines the subject of the mail. Mustache templates can be used to render attributes from the watch runtime data. Required.
**text_body:** Defines the content of the mail. Mustache templates can be used to render attributes from the watch runtime data. Optional.
## Technical Preview Limitations
* HTML mails are not supported
* Attachements are not supported
**text_body:** Defines the content of the mail. Mustache templates can be used to render attributes from the watch runtime data. Optional.
......@@ -6,7 +6,7 @@ category: actions
order: 100
layout: docs
edition: beta
description:
description:
---
<!--- Copyright 2019 floragunn GmbH -->
......@@ -24,8 +24,6 @@ A typical index action looks like this:
```json
{
/* ... */
"actions": [
{
"type": "index",
......@@ -47,7 +45,7 @@ Therefore, as shown in the example above, index actions are typically accompanie
## Specifying the Document ID
Normally, documents will be indexed with an automatically generated ID. You can however also explicitly define the ID of the document by providing an additional attribute in the runtime data called `_id`.
Normally, documents will be indexed with an automatically generated ID. You can however also explicitly define the ID of the document by providing an additional attribute in the runtime data called `_id`.
## Indexing Multiple Documents
......@@ -55,8 +53,6 @@ If you want to index multiple documents by one action execution, you need to pre
```json
{
/* ... */
"actions": [
{
"type": "index",
......@@ -81,10 +77,6 @@ The index operation will be executed with the privileges the user had when creat
Further configuration attributes are:
**refresh:** The Elasticsearch index [refresh policy](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-refresh.html). One of `false`, `true` or `wait_for`. Optional; default is `false`.
**refresh:** The Elasticsearch index [refresh policy](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-refresh.html). One of `false`, `true` or `wait_for`. Optional; default is `false`.
**timeout:** If the index operation does not complete in the specified time (in seconds), it will be aborted. Optional; default is 60 seconds.
## Technical Preview Limitations
* It's not possible yet to write the data back to a remote Elasticsearch cluster
\ No newline at end of file
......@@ -6,7 +6,7 @@ category: actions
order: 400
layout: docs
edition: beta
description:
description:
---
<!--- Copyright 2019 floragunn GmbH -->
......@@ -27,10 +27,9 @@ In order to use Slack actions, you need to configure a Slack webhook using the a
A basic Slack action looks like this:
<!-- {% raw %} -->
```json
{
/* ... */
"actions": [
{
"type": "slack",
......@@ -42,6 +41,7 @@ A basic Slack action looks like this:
]
}
```
<!-- {% endraw %} -->
The basic configuration attributes are:
......
......@@ -6,7 +6,7 @@ category: actions
order: 300
layout: docs
edition: beta
description:
description:
---
<!--- Copyright 2019 floragunn GmbH -->
......@@ -22,10 +22,9 @@ Use webhook actions to call arbitrary HTTP endpoints from watches. You can use M
A basic webhook action looks like this:
<!-- {% raw %} -->
```json
{
/* ... */
"actions": [
{
"type": "webhook",
......@@ -43,6 +42,7 @@ A basic webhook action looks like this:
]
}
```
<!-- {% endraw %} -->
The basic configuration attributes are:
......@@ -56,18 +56,30 @@ The basic configuration attributes are:
**request.url:** The URL of the HTTP endpoint. Required.
**request.body:** The body of the HTTP request. Optional. Mustache templates can be used to render attributes from the watch runtime data.
**request.path:** Overrides the path of the specified URL. Can be used to specify dynamic paths using Mustache templates. Optional.
**request.query_params:** Overrides the query part of the specified URL. Can be used to specify dynamic queries using Mustache templates. Optional.
**request.body:** The body of the HTTP request. Optional. Mustache templates can be used to render attributes from the watch runtime data.
**request.headers:** Specifies HTTP headers to be sent along the request. Optional.
**request.auth:** Optional. The authentication method for the HTTP request. See [Authentication](#authentication) for details.
**tls:** Configuration for TLS connections. See [TLS](#tls) for details.
**connection_timeout:** Specifies the time after which the try to create an connection shall time out. Optional. Specified in seconds.
**read_timeout:** Specifies the timeout for reading the response data after a connection has been already established. Optional. Specified in seconds.
## Dynamic Endpoints
The HTTP endpoint in the `request.url` attribute cannot be changed dynamically directly. However, you can use the configuration attributes `request.path` and `request.query_params` to define the respective parts of the URL using Mustache templates. The resulting path and/or query parameters then override the respective parts of the URL defined in `request.url`.
<!-- {% raw %} -->
```json
{
/* ... */
"actions": [
{
"type": "webhook",
......@@ -82,45 +94,73 @@ The HTTP endpoint in the `request.url` attribute cannot be changed dynamically d
]
}
```
<!-- {% endraw %} -->
## Authentication
You can use the `auth` attribute to specify HTTP basic auth data.
Right now, Signals directly supports [basic authentication](#basic-authentication) and [TLS client certificate authentication](#tls) when connecting to HTTP resources. If you need a token-based authentication scheme, you should be able use the `request.headers` option to set the appropriate HTTP headers.
### Basic Authentication
Basic authentication credentials are configured in the `auth` section if the `request` configuration. Configuring basic auth looks like this:
```json
{
/* ... */
"actions": [
{
"type": "webhook",
"name": "my_webhook_action",
"throttle_period": "10m",
"request": {
"method": "POST",
"url": "https://my.test.web.hook/",
"auth": {
"type": "basic",
"username": "test",
"password": "test"
}
}
}
]
{
"actions": [{
"type": "webhook",
"name": "my_webhook_action",
"request": {
"url": "https://my.test.web.hook/",
"method": "POST",
"auth": {"type":"basic","username":"admin","password":"admin"}
}
}]
}
```
**Note:** In the current version of the tech preview, the password is stored unencrypted and returned in verbatim when the watch is retrieved using the REST API. Future versions will provide a more secure way of storing authentication data.
**Note:** In the current version, the password is stored unencrypted and returned in verbatim when the watch is retrieved using the REST API. Future versions will provide a more secure way of storing authentication data.
## Advanced Functionality
## TLS
Furthermore, webhook actions provide these configuration options:
You can configure both the trusted certificates and client certificates that shall be used when creating TLS connections.
**connection_timeout:** Specifies the time after which the try to create an connection shall time out. Optional. Specified in seconds.
If you do not provide an explicit configuration, the defaults configured for the JVM in which ES is running will be used.
**read_timeout:** Specifies the timeout for reading the response data after a connection has been already established. Optional. Specified in seconds.
**Note:** Right now, certificates have to be specfied in PEM format in-line in the watch configuration. Future versions will provide a more secure way of storing certificates.
## Security Considerations
A TLS configuration might look like this:
Keep in mind that webhook actions allow to send arbitrary HTTP requests from Elasticsearch nodes. We are still working on mechanisms to define restrictions on the use of webhook actions and the allowed endpoints.
```json
{
"actions": [{
"type": "webhook",
"name": "my_webhook_action",
"request": {
"url": "https://my.test.web.hook/",
"method": "POST",
},
"tls": {
"trusted_certs": "-----BEGIN CERTIFICATE-----\n....\n-----END CERTIFICATE-----\n",
"client_auth": {
"certs": "-----BEGIN CERTIFICATE-----\n....\n-----END CERTIFICATE-----\n",
"private_key": "-----BEGIN ENCRYPTED PRIVATE KEY-----\n...\n-----END ENCRYPTED PRIVATE KEY-----\n",
"private_key_password": "secret"
}
}
}]
}
```
**tls.trusted_certs:** An array of certificats in PEM format. If you only have one cert, you can also specify it directly as string without an array. Optional.
**tls.client_auth:** If you want to use TLS client certificate authentication, you have to specify the certificate, its private key and the password for the private key here. Optional.
**tls.verify_hostnames:** If true, it is checked that a presented certificate actually belongs to the name of the host we are connecting to. Optional, defaults to false.
**tls.trust_all:** Trust any presented certificate. Thus, the authenticity of the host we are connecting to won't be verified. *This option should be only used for testing purposes, as the security of the connection cannot be guaranteed.* Optional, defaults to false.
## Security Considerations
Keep in mind that webhook actions allow to send arbitrary HTTP requests from Elasticsearch nodes. This can be limited using the Signals setting `http.allowed_endpoints`. See the section on [Administration](administration.md) for details.
......@@ -6,7 +6,7 @@ category: conditions
order: 100
layout: docs
edition: beta
description:
description:
---
<!--- Copyright 2019 floragunn GmbH -->
......@@ -26,11 +26,7 @@ If used in a watch, depending on the return value of the script, execution of th
If used in an action, depending on the return value of the script, the action is either executed or skipped. A condition in one action does not affect execution of other actions.
A script can be defined as an line script or as a stored script. Inline scripts are added to the condition definition directly, while stored scripts are stored in Elasticsearch and referred to by their id.
## Inline scripts
The following condition tests whether the total hits of a search, stored in the execution context under the name `mysearch`, is higher than zero:
The following condition tests whether the total hits of a search, stored in the execution context under the name `mysearch`, is higher than zero:
```
{
......@@ -47,25 +43,6 @@ The following condition tests whether the total hits of a search, stored in the
| source | The script to execute. Mandatory |
| lang | The scripting language to be used. Optional, defaults to painless. Other scripting languages may be provided by Elasticsearch plugins. |
## Stored scripts
To run a stored script, refer to it by using it's id:
```
{
"type": "condition.script",
"name": "mycondition",
"script_id": "mystoredscript"
}
```
| Name | Description |
|---|---|
| type | condition.script, defines this conditions as script condition. Mandatory. |
| name | name of this condition. Can be chosen freely. Mandatory. |
| script_id | The ID of the stored script. Mandatory |
**Note:** When using stored scripts, keep in mind that stored scripts are not subject to multi-tenancy or Signals permissions and may be thus changed independently of the watch. Thus, you should review whether the ability to edit scripts is adequately restricted.
## Accessing the runtime data
......@@ -76,7 +53,7 @@ The runtime data is available via the `data` prefix.
For example, the following watch runs a query against the serverlogs index to find entries where the statuscode is 500. The target property of the input is configured to be `http_error_500`; thus the document read by the input is put under this property name into the runtime data. The script condition accesses the data by using the `data.http_error_500` prefix and only continues if the total hits is above 10.
```
{
{
"trigger":{},
"checks":[
{
......@@ -102,17 +79,18 @@ For example, the following watch runs a query against the serverlogs index to fi
## Using script conditions with actions
A script condition can also be used to control the execution of an action. Each action can define it's own chain of `check`s, including conditions.
A script condition can also be used to control the execution of an action. Each action can define it's own chain of `check`s, including conditions.
Continuing on the example above, the following snippet will send an email to the administrator if the watch fires.
Continuing on the example above, the following snippet will send an email to the administrator if the watch fires.
A second action will send an additional email to a manager if the total number of hits is above 100. This is controlled by the script condition in the action definition:
<!-- {% raw %} -->
```
{
{
"trigger":{},
"checks":[],
"actions":[
"actions":[
{
"type":"email",
"name":"standard_admin",
......@@ -138,4 +116,5 @@ A second action will send an additional email to a manager if the total number o
}
]
}
```
\ No newline at end of file
```
<!-- {% endraw %} -->
......@@ -6,7 +6,7 @@ category: signals
order: 250
layout: docs
edition: beta
description:
description:
---
<!--- Copyright 2019 floragunn GmbH -->
......@@ -59,9 +59,9 @@ Each step in the execution chain is called a *check*. Example:
## Execution runtime data
All checks and actions operate on the watch runtime data.
All checks and actions operate on the watch runtime data.
[Input](inputs.md) checks can add data to the context; either under a specific property name or at the top level, replacing all data that was possibly stored before.
[Input](inputs.md) checks can add data to the context; either under a specific property name or at the top level, replacing all data that was possibly stored before.
[Transformations](transformations_transformations.md) transform existing data, [Calculations](transformations_calculations.md) add data based on existing data, and [Conditions](conditions.md) control the execution flow based on the runtime data.
......@@ -128,7 +128,7 @@ data.<target name>.path.to.data
Actions format their messages by using Mustache templates. Mustache templates have access to the runtime data as well. Example:
<!-- {% raw %} -->
```
{
"trigger": { ...},
......@@ -150,12 +150,14 @@ Actions format their messages by using Mustache templates. Mustache templates ha
]
}
```
<!-- {% endraw %} -->
Format:
<!-- {% raw %} -->
```
{% raw %}
{{data.<target name>.path.to.data}}
{% endraw %}
```
<!-- {% endraw %} -->
......@@ -6,7 +6,7 @@ category: signals
order: 200
layout: docs
edition: beta
description:
description:
---
<!--- Copyright 2019 floragunn GmbH -->
......@@ -32,11 +32,11 @@ You can use Signals to:
* run an aggregation periodically on the logs index that counts the number of errors in the last 5 minutes
* implement a condition that checks whether the error level is above a certain threshold
* if the condition is met, send out notifications via Email or Slack to inform your DevOps team.
* if the condition is met, send out notifications via Email or Slack to inform your DevOps team.
## Audit logging example
Assume you use the [Search Guard audit log feature](audit-logging-compliance) and want to be able to detect brute-force attempts to your cluster.
Assume you use the [Search Guard audit log feature](audit-logging-compliance) and want to be able to detect brute-force attempts to your cluster.
You can use Signals to
......@@ -57,23 +57,23 @@ These three elements also form the three major building blocks of a Signals watc
* **Checks** are constructs meant for analyzing the situation to be watched. For doing so, Signals offers
* *[Inputs](inputs.md)* which pull in data from a source such as an Elasticsearch index or an HTTP service;
* *[Conditions](conditions.md)* to analyze the gathered data using scripts and decide whether to proceed with execution or to abort;
* *[Transformations and calculations](transformations.md)* to transform the gathered data into a format that subsequent operations may require.
* *[Transformations and calculations](transformations.md)* to transform the gathered data into a format that subsequent operations may require.
* Each watch can have several checks, which are executed as a chain. Each action of a watch can also have a chain of checks.
* **[Actions](actions.md)** are executed if all preceding conditions are met.
* Actions can be used to alert users via [Email](actions_email.md), [Slack](actions_slack.md), or PagerDuty (coming soon).
* Actions can be used to write the runtime data back to data sinks like an [Elasticsearch index](actions_index.md).
* Using the [Webhook action](actions_webhook.md), it is possible to invoke any HTTP service as a result of a Signals watch.
* Each watch can have several actions. Action-specific checks can be used to decide which actions are executed in which situation.
Optionally, you can use a **[Severity Mapping](severity.md)** in order to map the data gathered by the checks to a simple severity scale (consisting of the levels info, warning, error, critical). If you do so, you can configure actions to be executed only for specific severity levels. This can greatly simplify the definition of conditions for actions if you are modeling escalation schemes or similar structures.
* Each watch can have several actions. Action-specific checks can be used to decide which actions are executed in which situation.
Optionally, you can use a **[Severity Mapping](severity.md)** in order to map the data gathered by the checks to a simple severity scale (consisting of the levels info, warning, error, critical). If you do so, you can configure actions to be executed only for specific severity levels. This can greatly simplify the definition of conditions for actions if you are modeling escalation schemes or similar structures.
Using a severity mapping also enables you to define **Resolve Actions**. These actions can be used to trigger notifications in case the severity determined by a watch decreases - or in other words - the watch finds that a previously discovered situation does not exist any more.
The Signals dashboard also displays the current severity levels determined by the configured watches. Opposed to watches without a severity mapping, this gives you a clearer and quicker way to see what is happening right now.
## Watch Runtime Data
All watches operate on the so-called watch runtime data. Inputs put the gathered data into the runtime data; conditions can read it and transforms can modify it. Actions read from the runtime data as well.
The runtime data is formed like a hierarchical key/value document, quite similar to a document stored in an Elasticsearch index.
The runtime data is formed like a hierarchical key/value document, quite similar to a document stored in an Elasticsearch index.
The checks of a watch subsequently modify the runtime data. If action-specific checks are defined, these will be operating on isolated copies of the runtime data. So, modifications of the runtime data for one action have no effect on the runtime data visible for other actions.
......@@ -86,6 +86,7 @@ The checks of a watch subsequently modify the runtime data. If action-specific c
## Sample Watch
<!-- {% raw %} -->
```
{
"trigger": {
......@@ -152,9 +153,11 @@ The checks of a watch subsequently modify the runtime data. If action-specific c
]
}
```
<!-- {% endraw %} -->
## Sample Watch with Severity Mapping
<!-- {% raw %} -->
```
{
"trigger": {
......@@ -255,4 +258,4 @@ The checks of a watch subsequently modify the runtime data. If action-specific c
]
}
```
<!-- {% endraw %} -->
......@@ -6,7 +6,7 @@ category: inputs
order: 300
layout: docs
edition: beta
description:
description:
---
<!--- Copyright 2019 floragunn GmbH -->
......@@ -17,17 +17,16 @@ description:
{% include toc.md %}
An HTTP input pulls in data by accessing an HTTP endpoint. Most commonly, this will be a REST API.
An HTTP input pulls in data by accessing an HTTP endpoint. Most commonly, this will be a REST API.
All data from all inputs can be combined by using [Transformation](transformations_transformations.md) and [Calculations](transformations_calculations.md), used in [Conditions](conditions.md) and pushed to [action endpoints](actions.md).
For example, if you aggregate data from the [Search Guard Audit Log](auditlog), you can use an HTTP input to retrieve Geo Data information for the logged IP adresses and enrich the data from the audit log.
For example, if you aggregate data from the [Search Guard Audit Log](auditlog), you can use an HTTP input to retrieve Geo Data information for the logged IP addresses and enrich the data from the audit log.