script.asciidoc 4.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155
  1. [role="xpack"]
  2. [[condition-script]]
  3. === Script condition
  4. A watch <<condition,condition>> that evaluates a script. The default scripting
  5. language is `painless`. You can use any of the scripting languages supported by
  6. Elasticsearch as long as the language supports evaluating expressions to Boolean
  7. values. Note that the `mustache` and `expression` languages are too limited to be
  8. used by this condition. For more information, see <<modules-scripting>>.
  9. ==== Using a script condition
  10. The following snippet configures an inline `script` condition that always returns
  11. `true`:
  12. [source,js]
  13. --------------------------------------------------
  14. "condition" : {
  15. "script" : "return true"
  16. }
  17. --------------------------------------------------
  18. // NOTCONSOLE
  19. This example defines a script as a simple string. This format is actually a
  20. shortcut for defining an <<condition-script-inline,inline>> script. The
  21. formal definition of a script is an object that specifies the script type and
  22. optional language and parameter values. If the `lang` attribute is omitted, the
  23. language defaults to `painless`. Elasticsearch supports two types of scripts,
  24. <<condition-script-inline,inline>> and <<condition-script-stored,stored>>.
  25. For example, the following snippet shows a formal definition of an `inline`
  26. script that explicitly specifies the language and defines a single script
  27. parameter, `result`:
  28. [source,js]
  29. --------------------------------------------------
  30. "condition" : {
  31. "script" : {
  32. "source" : "return params.result",
  33. "lang" : "painless",
  34. "params" : {
  35. "result" : true
  36. }
  37. }
  38. }
  39. --------------------------------------------------
  40. // NOTCONSOLE
  41. [[condition-script-inline]]
  42. ==== Inline scripts
  43. Inline scripts are scripts that are defined in the condition itself. The
  44. following snippet shows the formal configuration of a simple painless script that
  45. always returns `true`.
  46. [source,js]
  47. --------------------------------------------------
  48. "condition" : {
  49. "script" : {
  50. "source" : "return true"
  51. }
  52. }
  53. --------------------------------------------------
  54. // NOTCONSOLE
  55. [[condition-script-stored]]
  56. ==== Stored scripts
  57. Stored scripts refer to scripts that were
  58. <<modules-scripting-stored-scripts,stored>> in Elasticsearch. The following
  59. snippet shows how to refer to a script by its `id`:
  60. [source,js]
  61. --------------------------------------------------
  62. "condition" : {
  63. "script" : {
  64. "id" : "my_script"
  65. }
  66. }
  67. --------------------------------------------------
  68. // NOTCONSOLE
  69. As with <<condition-script-inline,inline>> scripts, you can also specify the
  70. script language and parameters:
  71. [source,js]
  72. --------------------------------------------------
  73. "condition" : {
  74. "script" : {
  75. "id" : "my_script",
  76. "lang" : "javascript",
  77. "params" : { "color" : "red" }
  78. }
  79. }
  80. --------------------------------------------------
  81. // NOTCONSOLE
  82. [[accessing-watch-payload]]
  83. ==== Accessing the watch payload
  84. A script can access the current watch execution context, including the payload
  85. data, as well as any parameters passed in through the condition definition.
  86. For example, the following snippet defines a watch that uses a
  87. <<input-search,`search` input>> and uses a `script` condition to check if the
  88. number of hits is above a specified threshold:
  89. [source,js]
  90. --------------------------------------------------
  91. {
  92. "input" : {
  93. "search" : {
  94. "indices" : "log-events",
  95. "body" : {
  96. "size" : 0,
  97. "query" : { "match" : { "status" : "error" } }
  98. }
  99. }
  100. },
  101. "condition" : {
  102. "script" : {
  103. "source" : "return ctx.payload.hits.total > params.threshold",
  104. "params" : {
  105. "threshold" : 5
  106. }
  107. }
  108. }
  109. }
  110. --------------------------------------------------
  111. // NOTCONSOLE
  112. When you're using a scripted condition to evaluate an Elasticsearch response,
  113. keep in mind that the fields in the response are no longer in their native data
  114. types. For example, the `@timestamp` in the response is a string, rather than a
  115. `DateTime`. To compare the response `@timestamp` against the `ctx.execution_time`,
  116. you need to parse the `@timestamp` string into a `DateTime`. For example:
  117. [source,js]
  118. --------------------------------------------------
  119. org.elasticsearch.common.joda.time.DateTime.parse(@timestamp)
  120. --------------------------------------------------
  121. // NOTCONSOLE
  122. You can reference the following variables in the watch context:
  123. [options="header"]
  124. |======
  125. | Name | Description
  126. | `ctx.watch_id` | The id of the watch that is currently executing.
  127. | `ctx.execution_time` | The time execution of this watch started.
  128. | `ctx.trigger.triggered_time` | The time this watch was triggered.
  129. | `ctx.trigger.scheduled_time` | The time this watch was supposed to be triggered.
  130. | `ctx.metadata.*` | Any metadata associated with the watch.
  131. | `ctx.payload.*` | The payload data loaded by the watch's input.
  132. |======