2019-09-10 13:32:51 -04:00
|
|
|
[role="xpack"]
|
2017-03-28 17:23:01 -04:00
|
|
|
[[condition-script]]
|
2019-09-30 13:18:50 -04:00
|
|
|
=== Script condition
|
2017-03-28 17:23:01 -04:00
|
|
|
|
2019-09-30 13:18:50 -04:00
|
|
|
A watch <<condition,condition>> that evaluates a script. The default scripting
|
2017-03-28 17:23:01 -04:00
|
|
|
language is `painless`. You can use any of the scripting languages supported by
|
|
|
|
Elasticsearch as long as the language supports evaluating expressions to Boolean
|
|
|
|
values. Note that the `mustache` and `expression` languages are too limited to be
|
2019-09-30 13:18:50 -04:00
|
|
|
used by this condition. For more information, see <<modules-scripting>>.
|
2017-03-28 17:23:01 -04:00
|
|
|
|
2019-09-30 13:18:50 -04:00
|
|
|
==== Using a script condition
|
2017-03-28 17:23:01 -04:00
|
|
|
|
|
|
|
The following snippet configures an inline `script` condition that always returns
|
|
|
|
`true`:
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
|
|
|
"condition" : {
|
|
|
|
"script" : "return true"
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
2018-06-22 21:09:37 -04:00
|
|
|
// NOTCONSOLE
|
2017-03-28 17:23:01 -04:00
|
|
|
|
|
|
|
This example defines a script as a simple string. This format is actually a
|
2019-09-30 13:18:50 -04:00
|
|
|
shortcut for defining an <<condition-script-inline,inline>> script. The
|
2017-03-28 17:23:01 -04:00
|
|
|
formal definition of a script is an object that specifies the script type and
|
|
|
|
optional language and parameter values. If the `lang` attribute is omitted, the
|
2017-05-18 14:18:11 -04:00
|
|
|
language defaults to `painless`. Elasticsearch supports two types of scripts,
|
2019-09-30 13:18:50 -04:00
|
|
|
<<condition-script-inline,inline>> and <<condition-script-stored,stored>>.
|
2017-03-28 17:23:01 -04:00
|
|
|
|
|
|
|
For example, the following snippet shows a formal definition of an `inline`
|
|
|
|
script that explicitly specifies the language and defines a single script
|
|
|
|
parameter, `result`:
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
|
|
|
"condition" : {
|
|
|
|
"script" : {
|
2018-03-16 12:57:29 -04:00
|
|
|
"source" : "return params.result",
|
2017-03-28 17:23:01 -04:00
|
|
|
"lang" : "painless",
|
|
|
|
"params" : {
|
|
|
|
"result" : true
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
2018-06-22 21:09:37 -04:00
|
|
|
// NOTCONSOLE
|
2017-03-28 17:23:01 -04:00
|
|
|
|
|
|
|
[[condition-script-inline]]
|
2019-09-30 13:18:50 -04:00
|
|
|
==== Inline scripts
|
2017-03-28 17:23:01 -04:00
|
|
|
|
|
|
|
Inline scripts are scripts that are defined in the condition itself. The
|
|
|
|
following snippet shows the formal configuration of a simple painless script that
|
|
|
|
always returns `true`.
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
|
|
|
"condition" : {
|
|
|
|
"script" : {
|
2017-06-09 11:29:36 -04:00
|
|
|
"source" : "return true"
|
2017-03-28 17:23:01 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
2018-06-22 21:09:37 -04:00
|
|
|
// NOTCONSOLE
|
2017-03-28 17:23:01 -04:00
|
|
|
|
|
|
|
[[condition-script-stored]]
|
2019-09-30 13:18:50 -04:00
|
|
|
==== Stored scripts
|
2017-03-28 17:23:01 -04:00
|
|
|
|
2019-09-30 13:18:50 -04:00
|
|
|
Stored scripts refer to scripts that were
|
|
|
|
<<modules-scripting-stored-scripts,stored>> in Elasticsearch. The following
|
|
|
|
snippet shows how to refer to a script by its `id`:
|
2017-03-28 17:23:01 -04:00
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
|
|
|
"condition" : {
|
|
|
|
"script" : {
|
|
|
|
"id" : "my_script"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
2018-06-22 21:09:37 -04:00
|
|
|
// NOTCONSOLE
|
2017-03-28 17:23:01 -04:00
|
|
|
|
2019-09-30 13:18:50 -04:00
|
|
|
As with <<condition-script-inline,inline>> scripts, you can also specify the
|
|
|
|
script language and parameters:
|
2017-03-28 17:23:01 -04:00
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
|
|
|
"condition" : {
|
|
|
|
"script" : {
|
|
|
|
"id" : "my_script",
|
|
|
|
"lang" : "javascript",
|
|
|
|
"params" : { "color" : "red" }
|
|
|
|
}
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
2018-06-22 21:09:37 -04:00
|
|
|
// NOTCONSOLE
|
2017-03-28 17:23:01 -04:00
|
|
|
|
|
|
|
[[accessing-watch-payload]]
|
2019-09-30 13:18:50 -04:00
|
|
|
==== Accessing the watch payload
|
2017-03-28 17:23:01 -04:00
|
|
|
|
|
|
|
A script can access the current watch execution context, including the payload
|
|
|
|
data, as well as any parameters passed in through the condition definition.
|
|
|
|
|
2019-09-30 13:18:50 -04:00
|
|
|
For example, the following snippet defines a watch that uses a
|
|
|
|
<<input-search,`search` input>> and uses a `script` condition to check if the
|
|
|
|
number of hits is above a specified threshold:
|
2017-03-28 17:23:01 -04:00
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
|
|
|
{
|
|
|
|
"input" : {
|
|
|
|
"search" : {
|
|
|
|
"indices" : "log-events",
|
|
|
|
"body" : {
|
|
|
|
"size" : 0,
|
|
|
|
"query" : { "match" : { "status" : "error" } }
|
|
|
|
}
|
|
|
|
}
|
|
|
|
},
|
|
|
|
"condition" : {
|
|
|
|
"script" : {
|
2018-03-16 12:57:29 -04:00
|
|
|
"source" : "return ctx.payload.hits.total > params.threshold",
|
2017-03-28 17:23:01 -04:00
|
|
|
"params" : {
|
|
|
|
"threshold" : 5
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
2018-06-22 21:09:37 -04:00
|
|
|
// NOTCONSOLE
|
2017-03-28 17:23:01 -04:00
|
|
|
|
|
|
|
When you're using a scripted condition to evaluate an Elasticsearch response,
|
|
|
|
keep in mind that the fields in the response are no longer in their native data
|
|
|
|
types. For example, the `@timestamp` in the response is a string, rather than a
|
|
|
|
`DateTime`. To compare the response `@timestamp` against the `ctx.execution_time`,
|
|
|
|
you need to parse the `@timestamp` string into a `DateTime`. For example:
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
|
|
|
org.elasticsearch.common.joda.time.DateTime.parse(@timestamp)
|
|
|
|
--------------------------------------------------
|
2018-06-22 21:09:37 -04:00
|
|
|
// NOTCONSOLE
|
2017-03-28 17:23:01 -04:00
|
|
|
|
|
|
|
You can reference the following variables in the watch context:
|
|
|
|
|
|
|
|
[options="header"]
|
|
|
|
|======
|
|
|
|
| Name | Description
|
|
|
|
| `ctx.watch_id` | The id of the watch that is currently executing.
|
|
|
|
| `ctx.execution_time` | The time execution of this watch started.
|
|
|
|
| `ctx.trigger.triggered_time` | The time this watch was triggered.
|
|
|
|
| `ctx.trigger.scheduled_time` | The time this watch was supposed to be triggered.
|
|
|
|
| `ctx.metadata.*` | Any metadata associated with the watch.
|
|
|
|
| `ctx.payload.*` | The payload data loaded by the watch's input.
|
|
|
|
|======
|