Script Condition

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

"condition" : {
  "script" : "return true"
}

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 three script types: Inline, File, 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:

"condition" : {
  "script" : {
    "inline" : "return result",
    "lang" : "painless",
    "params" : {
      "result" : true
    }
  }
}

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.

"condition" : {
  "script" : {
    "inline" : "return true"
  }
}

File scripts are scripts that are defined in files stored in the config/scripts directory. The following snippet shows how to refer to the my_script.painless file:

"condition" : {
  "script" : {
    "file" : "my_script"
  }
}

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

"condition" : {
  "script" : {
    "file" : "my_script",
    "lang" : "javascript",
    "params" : {
      "result" : true
    }
  }
}

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

"condition" : {
  "script" : {
    "id" : "my_script"
  }
}

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

"condition" : {
  "script" : {
    "id" : "my_script",
    "lang" : "javascript",
    "params" : { "color" : "red" }
  }
}

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:

{
  "input" : {
    "search" : {
      "indices" : "log-events",
      "body" : {
        "size" : 0,
        "query" : { "match" : { "status" : "error" } }
      }
    }
  },
  "condition" : {
    "script" : {
      "inline" : "return ctx.payload.hits.total > threshold",
      "params" : {
        "threshold" : 5
      }
    }
  }
}

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:

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

You can reference the following variables in the watch context: