Script condition

A watch condition that evaluates a script. The default scripting 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 used by this condition. For more information, see Scripting.

Using a script condition

The following snippet configures an inline script condition that always returns true:

  1. "condition" : {
  2. "script" : "return true"
  3. }

This example defines a script as a simple string. This format is actually a shortcut for defining an inline script. The 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 language defaults to painless. Elasticsearch supports two types of scripts, inline and stored.

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:

  1. "condition" : {
  2. "script" : {
  3. "source" : "return params.result",
  4. "lang" : "painless",
  5. "params" : {
  6. "result" : true
  7. }
  8. }
  9. }

Inline scripts

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.

  1. "condition" : {
  2. "script" : {
  3. "source" : "return true"
  4. }
  5. }

Stored scripts

Stored scripts refer to scripts that were stored in Elasticsearch. The following snippet shows how to refer to a script by its id:

  1. "condition" : {
  2. "script" : {
  3. "id" : "my_script"
  4. }
  5. }

As with inline scripts, you can also specify the script language and parameters:

  1. "condition" : {
  2. "script" : {
  3. "id" : "my_script",
  4. "lang" : "javascript",
  5. "params" : { "color" : "red" }
  6. }
  7. }

Accessing the watch payload

A script can access the current watch execution context, including the payload data, as well as any parameters passed in through the condition definition.

For example, the following snippet defines a watch that uses a search input and uses a script condition to check if the number of hits is above a specified threshold:

  1. {
  2. "input" : {
  3. "search" : {
  4. "indices" : "log-events",
  5. "body" : {
  6. "size" : 0,
  7. "query" : { "match" : { "status" : "error" } }
  8. }
  9. }
  10. },
  11. "condition" : {
  12. "script" : {
  13. "source" : "return ctx.payload.hits.total > params.threshold",
  14. "params" : {
  15. "threshold" : 5
  16. }
  17. }
  18. }
  19. }

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:

  1. org.elasticsearch.common.joda.time.DateTime.parse(@timestamp)

You can reference the following variables in the watch context:

NameDescription

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.