Version: 7.x-36.0.0

This is a technical preview. Technical preview features are not fully supported, may not be functionally complete, and are not suitable for deployment in production. We encourage you to try them out and provide your feedback, good and bad, on the Search Guard forum. This will help us improve and add any features you might be missing.

Execution chain and execution runtime data

Execution chain: Checks

Each watch can define as many inputs, transformations, calculations and conditions as required, in any order.

Each step in the execution chain is called a check. Example:

{
  "trigger": { ...},
  "checks": [
    {
      "type": "static",
      "name": "constants",
      ...
    },
    {
      "type": "search",
      "name": "avg_ticket_price",
      ...
    },
    {
      "type": "condition.script",
      "name": "low_price"
      ...
    },
    {
      "type": "transform",
      "name": "format_data"
      ...
    },
    {
      "type": "http",
      "name": "add_geo_data"
      ...
    },
    ...    
  ],
  "actions": [ ... ]
}

Execution runtime data

All checks and actions operate on the watch runtime data.

Input 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 transform existing data, Calculations add data based on existing data, and Conditions control the execution flow based on the runtime data.

Actions send out notifications based on the runtime data, or store all or parts of the runtime data on a data sink, like Elasticsearch.

Adding data to the runtime data

Inputs and Transformations fetch data and place it in the runtime data under a name specified by the target of the check. Example:

{
  "trigger": { ...},
  "checks": [
    {
      "type": "search",
      "name": "avg_ticket_price",
      "target": "avg_ticket_price",
      "request": {
        "indices": [
          "kibana_sample_data_flights"
        ],
        "body": {
         "query": { ... }
        }
    }
    ...    
  ],
  "actions": [ ... ]
}

This input executes an Elasticsearch query and stores the result of the query under the name avg_ticket_price. Using the special target name _top places the data at the top level of the runtime data. Any data that was present before gets erased.

Accessing runtime data

Transformations, calculations and conditions access runtime data by using the prefix data followed by the respective property name. The property name is, of course, defined by the target value used in the input before.

{
  "trigger": { ...},
  "checks": [
    {
      "type": "condition.script",
      "name": "low_price",
      "source": "data.avg_ticket_price.aggregations.when.value < data.constants.ticket_price"
    }
    ...    
  ],
  "actions": [ ... ]
}

Format:

data.<target name>.path.to.data

Accessing data in Mustache templates

Actions format their messages by using Mustache templates. Mustache templates have access to the runtime data as well. Example:

{
  "trigger": { ...},
  "checks": [ ... ],
  "actions": [
      {
      "type": "webhook",
      "name": "myslack",
      "throttle_period": "1s",
      "request": {
        "method": "POST",
        "url": "https://hooks.slack.com/services/token",
        "body": "{\"text\": \"Average flight ticket price decreased to  over last \"}",
        "headers": {
          "Content-type": "application/json"
        }
      }
    }  
  ]
}

Format:


{{data.<target name>.path.to.data}}


Not what you were looking for? Try the search.