User Guide

API Reference

Overview

The Tornado API lets you automate all the tasks that are available for execution over the WEB-GUI by calling the endpoints directly. In this section we will go over all the available endpoints and how to use them to query and modify the Tornado Processing Tree.

All available endpoints can be found by default under http://tornado.neteyelocal:4748/api/v2_beta/

Authorization

To perform any action in Tornado you need to provide an authorization token with the correct permissions.The token is a base64 encoded JSON object, which contains the username as well as a map of available authorizations.

Permissions

To interact with any parts of the tree you need to be granted a corresponding permission. The following permissions are available in NetEye:

Permission

Description

view

Allows you to retrieve any information about the active Processing Tree

edit

Allows you to modify drafts

test_event_execute_actions

Allows you to execute action when sending test events

admin

Gives you full access to all features of the Tornado api

Authorization Token

An Authorization Token can contain multiple authorizations. The Authorization is composed of a set of permission as well as a path for which those permissions apply. The path needs to start with root and gives the path to any node in the Processing Tree. Each following node must then be a new element in the list. The api-user is then prohibited to modify any node outside of that base-path.

The roles property of the authotization is a set of Permissions to which the api-user is restricted.

{
    "user": "<my-tornado-user>",
    "auths": {
        "my-auth": {
            "path": [ "root", "master", "email" ],
            "roles": [ "view", "edit" ]
        }
    }
}

Note

The name in the authorization MUST not be empty. An empty name will result in the 401 HTTP error.

To see how to generate the token, take a look at the Getting Started section.

Best practices

Give every api-user a distinct and recognizible name. This lets you track changes and detect clashes during the editing of the draft.

Give every api-user the minimal permission necessary to perform its task. For example, if a api client only needs to read / export config from one specific tenant, give the client only read permissions for their specific tenant node.

Common Request Types

Name

Source

Description

param_auth

Path

The authorization from the header to use.

node_path

Path

A comma separated list of node name that points to a specific node, starting from the root node of the tenant.

rule_name

Path

The name of the Rule you want to access

draft_id

Path

The id of the draft you want to take over for your user

Limitations

Tornado does not yet support Multitenancy for the draft editing. Your Tornado installation has exactly one active Processing Tree and zero to one drafts with a dedicated owner of said draft. If another user already owns the draft or another api-client or user takes over the draft, during execution, then future requests will be rejected by the endpoint.

There is no reliable way right now to detect whether a draft contains any changes to the current active Processing Tree. So you might need to take over the existing draft, overwrite it, or ask the user to deploy and delete the current draft before you can continue.

Getting Started

This section will help to get started with using the Tornado API to edit the Processing Tree through the whole life cycle of a draft. First we’ll create a draft, add a node, edit that node and then deploy the draft so that our changes will end up in the actual environment.

First of all, we need an authorization token, so that Tornado lets us use the API. That token contains a unique name and its permissions. The name for our client will be api-filter-manager, since it will create a new filter for the master tenant. Since we are only operating on the master node, we restrict the token to that path, so we can’t accidentally edit something else.

TOKEN_CONTENT='{"user":"api-filter-manager","auths":{"master-auth":{"path":["root","master"],"roles":["view","edit"]}}}'
AUTH_TOKEN=$(echo "$TOKEN_CONTENT" | base64 --wrap=0)

Before we can edit the draft, we need to make sure that the draft is not being edited at the moment by another user. To do that we make a request to check that no drafts are currently present:

curl -XGET \
    -H "Authorization: Bearer $AUTH_TOKEN" \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/drafts/master-auth"

This request should return an empty array. If not, it’s safest to ask the user to deploy and/or delete the current draft before continuing, so that the execution does not interfere with any ongoing modifications to the draft.

Now that we are sure we have a clean slate to work on, we first need to create our own draft. For this, we make a POST request to the appropriate endpoint:

RESULT=$(curl -XPOST \
    -H "Authorization: Bearer $AUTH_TOKEN" \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/drafts/master-auth")
DRAFT_ID=$(echo $RESULT | jq .id --raw-output)

We now have successfully created the draft we want to work on. Next we are going to actually create a new node in the Processing Tree and then edit it. First, we make a POST request to create a new filter node as a child of the master tenant. We just provide the new name for now.

curl -XPOST \
    -H "Authorization: Bearer $AUTH_TOKEN" \
    -H "Content-type: application/json" \
    --data '{"type": "Filter","name":"meaning_of_life","active":true,"description":"","filter":null}' \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/draft/tree/details/master-auth/$DRAFT_ID/master"

Next, let’s add a filter to the filter node, so that the children only receive the event designated to them. We’ll do that by first fetching the data for that node from the API, editing it and then send the edited node to Tornado. The creation could be done in one step, but this helps to better illustrate the interaction between the APIs.

FILTER_NODE=$(curl -XGET \
    -H "Authorization: Bearer $AUTH_TOKEN" \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/draft/tree/details/master-auth/$DRAFT_ID/master,meaning_of_life")

FILTER_NODE=$(echo "$FILTER_NODE" | jq '.filter = {"type":"AND","operators":[{"type":"equals","first":"${event.payload.meaning_of_life}","second":42}]}')

curl -XPUT \
    -H "Authorization: Bearer $AUTH_TOKEN" \
    -H "Content-type: application/json" \
    --data "$FILTER_NODE" \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/draft/tree/details/master-auth/$DRAFT_ID/master,meaning_of_life"

Now that we have the node ready for use, we can import some base config we want the filter node to have. We assume this configuration is located in the file filter-base-config.json located in the current working directory.

curl -XPOST \
    -H "Authorization: Bearer $AUTH_TOKEN" \
    -F 'file=@filter-base-config.json' \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/draft/tree/import/master-auth/$DRAFT_ID/master,meaning_of_life"

Now we finally configured our new filter how we wanted. The last step is just to deploy the whole configuration so that it can pick up work in the active production environment. After the deploy, we will remove the old draft so that the next user has a clean slate, when he wants to further edit the Tornado config.

curl -XPOST \
    -H "Authorization: Bearer $AUTH_TOKEN" \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/drafts/master-auth/$DRAFT_ID/deploy"

curl -XDELETE \
    -H "Authorization: Bearer $AUTH_TOKEN" \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/drafts/master-auth/$DRAFT_ID"

With that we have completed the life cycle of a Tornado config draft. The new filter is now ready to process events for Tornado. For further use, check out all the following Documented API endpoints.

Active Processing Tree

The Tornado API provides you an easy way to traverse your Processing Tree.

Get Tree Info

This endpoint lets you fetch a small summary about the subtree of the tenant.

Url: GET <base-url>/config/active/tree/info/{param_auth}

Required Permission: view

Parameters: See Common Request Types

Example:

curl "http://tornado.neteyelocal:4748/api/v2_beta/config/active/tree/info/my-auth" \
    -H "Authorization: Bearer <auth-token>"

Result

This endpoint returns a JSON object with the following properties:

Property

Type

Description

filters_count

Integer

The total number of filters in the whole subtree

iterators_count

Integer

The total number of iterators in the whole subtree

rules_count

Integer

The total number of rules in the whole subtree

Get Node Details

This endpoints lets you fetch all information about a single node in the currently active Processing Tree.

Url: GET <base-url>/config/active/tree/details/{param_auth}/{node_path}

Required Permission: view

Parameters: See Common Request Types

Example

curl "http://tornado.neteyelocal:4748/api/v2_beta/config/active/tree/details/my-auth/root,master" \
    -H "Authorization: Bearer <auth-token>"

Result: This endpoint returns a JSON object of type NodeDetails if a node exists in the given path and the api-user has permission to access it.

Get Child Nodes

This endpoints lets you fetch basic information about all the child nodes of a specific filter node.

Url: GET <base-url>/config/active/tree/details/{param_auth}/{node_path}

Required Permission: view

Parameters: See Common Request Types

Example

curl "http://tornado.neteyelocal:4748/api/v2_beta/config/active/tree/details/my-auth/root,master" \
    -H "Authorization: Bearer <auth-token>"

Result: This endpoint returns a JSON list of NodeInfo if the node selected is a filter node and the api-user has permission to access it.

Get Rule

This endpoints lets you fetch all information about a single Rule in the currently active Processing Tree.

Url: GET <base-url>/config/active/rule/details/{param_auth}/{ruleset_path}/{rule_name}

Required Permission: view

Parameters: See: Common Request Types

Example

curl "http://tornado.neteyelocal:4748/api/v2_beta/config/active/rule/details/my-auth/root,master,my_ruleset" \
    -H "Authorization: Bearer <auth-token>"

Result: This endpoint returns a Rule from the Processing Tree if the node selected is a Ruleset node, a rule with the given name exists and the api-user has the necessary permissions to access it.

Draft Processing Tree

Creating a Draft

This endpoint lets you create a new draft for the current active Processing Tree.

Warning

If a draft already exists, this endpoint will overwrite the current draft. Make sure there’s no currently active draft, before creating a new one.

Url: POST <base-url>/config/drafts/{param_auth}

Required Permission: edit

Parameters: See Common Request Types

Example

curl "http://tornado.neteyelocal:4748/api/v2_beta/config/drafts/my-auth" \
    -XPOST \
    -H "Authorization: Bearer <auth-token>"

Result

This endpoint returns the draft_id for the created draft.

Property

Type

Description

id

String

The id for the newly created draft.

Retrieving All Available Drafts

This endpoint lets you list out all available drafts for a specific authorization.

Url: GET <base-url>/config/drafts/{param_auth}

Required Permission: view

Parameters: See Common Request Types

Example:

curl "http://tornado.neteyelocal:4748/api/v2_beta/config/drafts/my-auth" \
    -XGET \
    -H "Authorization: Bearer <auth-token>"

Result: This endpoint returns a list of draft_ids available for the selected authorization.

Taking Over Draft

This endpoint lets you take over the ownership of a draft from another user.

Url: POST <base-url>/config/drafts/{param_auth}/{draft_id}/takeover

Required Permission: edit

Parameters: See Common Request Types

Example:

curl "http://tornado.neteyelocal:4748/api/v2_beta/config/drafts/my-auth/draft_001/takeover" \
    -XPOST \
    -H "Authorization: Bearer <auth-token>"

Result: This endpoint returns nothing if the takeover succeeded, otherwise it returns an error.

Deploying a Draft

This endpoint lets you deploy a draft to be the new active Processing Tree. Note that this endpoint only deploys the draft, and doesn’t delete it automatically

Url: POST <base-url>/config/drafts/{param_auth}/{draft_id}/deploy

Required Permission: edit

Parameters: See Common Request Types

Example:

curl "http://tornado.neteyelocal:4748/api/v2_beta/config/drafts/my-auth/draft_001/deploy" \
    -XPOST \
    -H "Authorization: Bearer <auth-token>"

Result: This endpoint returns nothing if the deploy succeeded, otherwise it returns an error.

Deleting a Draft

This endpoint allows you to delete an existing draft.

Url: DELETE <base-url>/config/drafts/{param_auth}/{draft_id}

Required Permission: edit

Parameters: See Common Request Types

Example:

curl "http://tornado.neteyelocal:4748/api/v2_beta/config/drafts/my-auth/draft_001" \
    -XDELETE \
    -H "Authorization: Bearer <auth-token>"

Result: This endpoint returns nothing if the deploy succeeded, otherwise it returns an error.

Get Draft Node Details

Same as Get Node Details, but for a draft.

Url: GET <base-url>/config/draft/tree/details/{param_auth}/{draft_id}/{node_path}

Required Permission: view

Get Draft Node Children

Same as Get Child Nodes, but for a draft.

Url: GET <base-url>/config/draft/tree/children/{param_auth}/{draft_id}/{node_path}

Required Permission: view

Create Node in Draft

Create a new child node of an existing node in the draft.

Url: POST <base-url>/config/draft/tree/details/{param_auth}/{draft_id}/{node_path}

Required Permission: edit

Parameters

Type

Source

Description

NodeDetails

Body

Pass the configuration of the node to create

See also: Common Request Types

Example

curl -XPOST \
    -H "Authorization: Bearer <auth-token>" \
    -H "Content-type: application/json" \
    --data '{"type": "Filter","name":"tenantA","active":true,"description":"","filter":{"type":"equals","first":"${event.metadata.tenant_id}","second":"tenantA"}}' \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/draft/tree/details/my-auth/draft_001/root"

Result: This endpoint returns nothing if the deploy succeeded, otherwise it returns an error.

Import Child Node

Import an exported configuration as a new child node.

Url: POST <base-url>/config/draft/tree/import/{param_auth}/{draft_id}/{node_path}

Required Permission: edit

Parameters

Name

Source

Description

file

Body

A file to upload

Example

curl -XPOST \
    -H "Authorization: Bearer <auth-token>" \
    -F 'file={"version":"1.0","Ruleset":{"name":"my_ruleset","rules":[]}}' \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/draft/tree/import/my-auth/draft_001/root"

Result: Same as Create Node in Draft

Import Node to Replace

This endpoint lets you replace an entire subtree with an exported version of the Tornado Processing Tree.

Url: PUT <base-url>/config/draft/tree/import/{param_auth}/{draft_id}/{node_path}

Required Permission: edit

Parameters: Same as Import Child Node

Edit Node in Draft

To edit a node in the draft you can use this endpoint. The endpoint however only lets you edit some details of the node. The operation will neither affect the children of the node, nor the node’s type.

Warning

You always have to supply the full config of the node every time, even for editing just the node name. All the data will be overwritten every time.

Url: PUT <base-url>/config/draft/tree/details/{param_auth}/{draft_id}/{node_path}

Required Permission: edit

Parameters

Type

Source

Description

NodeDetails

Body

Pass the configuration of the node to create

Example

curl -XPOST \
    -H "Authorization: Bearer <auth-token>" \
    --data '{"name":"my_ruleset2"}' \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/draft/tree/details/my-auth/draft_001/root,master,my_ruleset"

Result: This endpoint returns nothing if the edit operation succeeds, otherwise it returns an error.

Get Rule

Same as Get Rule, but for a draft.

Url: GET <base-url>/config/draft/rule/details/{param_auth}/{draft_id}/{ruleset_path}/{rule_name}

Required Permission: view

Parameters: See: Common Request Types

Example

curl "http://tornado.neteyelocal:4748/api/v2_beta/config/draft/rule/details/my-auth/draft_001/root,master,my_ruleset/my_rule" \
    -H "Authorization: Bearer <auth-token>"

Result: This endpoint returns a Rule from the draft if the node selected is a Ruleset node, a rule with the given name exists and the api-user has the necessary permissions to access it.

Create Rule

Create a new rule in an existing ruleset.

Url: POST <base-url>/config/draft/rule/details/{param_auth}/{draft_id}/{ruleset_path}

Required Permission: edit

Parameters

Type

Source

Description

Rule

Body

Path to the existing ruleset where to create the new rule

See also: Common Request Types

Example

curl -XPOST \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/draft/rule/details/my-auth/draft_001/root,master,my_ruleset" \
    -H "Authorization: Bearer <auth-token>" \
    -H "Content-type: application/json" \
    -d '{"name":"my_rule","description":"","continue":true,"active":true,"constraint":{"WHERE":{"type":"AND","operators":[{"type":"contains","first":"${event.type}","second":"mail"}]},"WITH":{}},"actions":[{"id":"archive","payload":{"archive_type":"ARCHIVE TYPE","event":"${event}"}}]}'

Result: This endpoint returns nothing if the add operation succeeds, otherwise it returns an error.

Edit Rule

Edit an existing rule.

Url: PUT <base-url>/config/draft/rule/details/{param_auth}/{draft_id}/{ruleset_path}/{rule_name}

Required Permission: edit

Parameters

Type

Source

Description

Rule

Body

Path to the existing ruleset where to find the rule to edit

See also: Common Request Types

Example

curl -XPUT \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/draft/rule/details/my-auth/draft_001/root,master,my_ruleset/my_rule" \
    -H "Authorization: Bearer <auth-token>" \
    -H "Content-type: application/json" \
    -d '{"name":"my_rule","description":"","continue":true,"active":true,"constraint":{"WHERE":{"type":"AND","operators":[{"type":"contains","first":"${event.type}","second":"mail"}]},"WITH":{}},"actions":[{"id":"archive","payload":{"archive_type":"ARCHIVE TYPE","event":"${event}"}}]}'

Result: This endpoint returns nothing if the edit operation succeeds, otherwise it returns an error.

Delete Rule

Delete an existing rule.

Url: DELETE <base-url>/config/draft/rule/details/{param_auth}/{draft_id}/{ruleset_path}/{rule_name}

Required Permission: edit

Parameters See: Common Request Types

Example

curl -XDELETE \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/draft/rule/details/my-auth/draft_001/root,master,my_ruleset/my_rule" \
    -H "Authorization: Bearer <auth-token>"

Result: This endpoint returns nothing if the delete operation succeeds, otherwise it returns an error.

Reorder Rule in Ruleset

Reorder an existing rule in relation of the other rules of the same ruleset.

Url: PUT <base-url>/config/draft/rule/move/{param_auth}/{draft_id}/{ruleset_path}/{rule_name}

Required Permission: edit

Parameters

Type

Source

Description

ruleset_path

URL

Path to the existing ruleset where to create the new rule

RulePosition

Body

New position of the rule in the ruleset

Example

curl -XPUT \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/draft/rule/move/my-auth/draft_001/root,master,my_ruleset/my_rule" \
    -H "Authorization: Bearer <auth-token>" \
    -H "Content-type: application/json" \
    -d '{"position":"3"}'

Result: This endpoint returns nothing if the edit operation succeeds, otherwise it returns an error.

Export Subtree

With this Enpoint you can export a subtree of tornado, starting from a given base node.

Url: PUT <base-url>/config/draft/tree/export/{param_auth}/{draft_id}/{node_path}

Required Permission: view

Parameters: See Common Request Types

Example

curl -XGET \
    -H "Authorization: Bearer <auth-token>" \
    -o export.json \
    "http://tornado.neteyelocal:4748/api/v2_beta/config/draft/tree/export/my-auth/draft_001/root"

Result: Returns a HTTP file attachment containing the config of the entire subtree.

Delete Draft Node

Delete a Node in the Draft, along with all of its children.

Url: DELETE <base-url>/config/draft/tree/details/{param_auth}/{draft_id}/{node_path}

Required Permission: edit

Result: This endpoint returns nothing if the request succeeded, otherwise it returns an error.

Test Event API

Send Test Event To Active Processing Tree

This endpoint lets you process a test event with the current active Tornado Processing Tree.

Url: POST /api/v2_beta/event/active/{param_auth}

Required Permissions: view OR edit

Optional Permissions: test_event_execute_actions to execute the actions if they match

Parameters

Name

Source

Description

param_auth

Path

The authorization from the header to use.

event

Body

A tornado event to process with the Processing Tree

process_type

Body

Either SkipActions or Full. Whether the actions should be executed. If this is set, then the api user MUST have the test_event_execute_actions permission

Example

curl "http://tornado.neteyelocal:4748/api/v2_beta/event/active/my-auth" \
-H "Authorization: Bearer <auth-token>" \
-XPOST \
--data '{"event":{"type":"the_event_type","created_ms":123456,"payload":{}},"process_type":"Full"}'

Result

Property

Type

Description

event

The Event Type

The initial event that was sent over the request

result

ProcessedNode

The Processing Tree, starting from the auth root, enriched with data about how the event was processed.

Send Test Event To Draft Processing Tree

Process a test event with a draft Tornado Processing Tree.

Url: POST /api/v2_beta/event/draft/{param_auth}/{draft_id}

Required Permissions: view OR edit

Optional Permissions: test_event_execute_actions to execute the actions if they match

Parameters: Same as Send Test Event To Active Processing Tree

Example

curl "http://tornado.neteyelocal:4748/api/v2_beta/event/draft/my-auth/draft_001" \
-H "Authorization: Bearer <auth-token>" \
-XPOST \
--data '{"event":{"type":"the_event_type","created_ms":123456,"payload":{}},"process_type":"Full"}'

Result: Same as Send Test Event To Active Processing Tree

Test Event Types

ProcessedNode

The content of the processed node vary by node type.

Property

Type

Description

type

String

Either Filter or Ruleset

name

String

The name of the node

ProcessedFilterNode

Property

Type

Description

filter.status

String

On of Matched, NotMatched or Ignored

nodes

ProcessedNode[]

A list of the filters child nodes. (Only populated if filter status is Matched)

ProcessedRulesetNode

Property

Type

Description

rules.rules

ProcessedRule[]

A list of all the rules in the ruleset with extra processing information.

rules.extracted_vars

Object

A map of all extracted variables

ProcessedRule

Property

Type

Description

name

String

The name of the Rule

status

String

On of Matched, NotMatched, PartiallyMatched or NotProcessed

action

Action[]

A list of all actions performed by the rule

message (Optional)

String

An error message if a rule was only partially matched

meta.actions (Optional)

Object[]

A list of resolved rules, with extra metadata for the processing

Troubleshooting

Should any error occur, you can consult the Tornado logs to see what went wrong. You can find out how to do this on the page Activate Debug Logging for Tornado.

Tornado API Common Types

In this section you can find all types that are either accepted or returned by the Tornado Api.

Rule

Property

Type

Description

name

String

The name of the rule

description

String

A short description of the rule provided by the user

continue

Boolean

Determines whether the rule processing should be terminated if the rule matches

active

Boolean

Determines whether the rule is active at the moment

constraint

[]

A list of all the constraint that determine the actions to be performed or not

actions

[]

A list of all the actions of the rule

Example:

{
    "name": "vmdevents",
    "description": "Log and propagate vmd-alarms.",
    "continue": true,
    "active": true,
    "constraint": {
        "WHERE": {
            "type": "AND",
            "operators": [
                {
                    "type": "equals",
                    "first": "${event.payload.foo}",
                    "second": "bar"
                }
            ]
        },
        "WITH": {
            "variable_1": {
                "from": "${event.payload}",
                "regex": {
                    "type": "Regex",
                    "match": ".*",
                    "group_match_idx": null,
                    "all_matches": false
                },
                "modifiers_post": [
                    {
                        "type": "Lowercase"
                    },
                    {
                        "type": "ReplaceAll",
                        "find": "foo",
                        "replace": "bar",
                        "is_regex": false
                    }
                ]
            }
        }
    },
    "actions": [
        {
            "id": "elasticsearch",
            "payload": {
                "auth": {
                    "jwc": true
                },
                "data": {
                    "id": 2
                },
                "endpoint": "elasticsearch.neteyelocal",
                "index": "foobar"
            }
        }
    ]
}

RuleDetails

Property

Type

Description

name

String

The name of the rule

description

String

A short user provided description of the rule

continue

Boolean

Determines whether the rule processing should be terminated if the rule matches

active

Boolean

Determines whether the rule is active at the moment

actions

String[]

A list of the names of all actions the rule will perform

Example:

{
    "name": "vmdevents",
    "description": "Log and propagate vmd-alarms.",
    "continue": true,
    "active": true,
    "actions":[ "archive", "script" ]
}

RulePosition

Property

Type

Description

position

Integer

The new position of the rule in the ruleset

Example:

{
    "position": "3"
}

Operator

The operators are the same as in the config. You can learn all about them in the Tornado WHERE Conditions section of the userguide

NodeInfo

The node info gives a quick summary of a node in the Processing Tree. To distinguish between the node types, the NodeDetails Type always contains the property type that can be one of Ruleset, Iterator or Filter. Depending on this value the type can have the following properties:

Property

Type

Description

name

String

The name of the filter

rules_count

Integer

The total number of rules in all the subtree

description (Filter/Iterator)

String

A short description of the node provided by the user

children_count (Filter/Iterator)

Integer

The number of direct children of the node

has_iterator_ancestor (Filter)

Boolean

Whether the filter is a child or descendant of an iterator node at any point in the processing tree

active (Filter/Iterator)

Boolean

Determines whether the node is active at the moment

Example:

{
    "type":"Filter",
    "name":"api_neteye_cloud",
    "rules_count":1,
    "children_count":1,
    "description":"Used for signaling failures in the api.neteye.cloud endpoint",
    "active":true
}

NodeDetails

The node details can either be details for a Ruleset, an Iterator or a Filter. To distinguish between the two, the NodeDetails Type always contains the property type that can be Ruleset, Iterator or Filter respectively. Depending on this value the type can have the following properties:

FilterNodeDetails

Property

Type

Description

type

String

Always set to Filter

name

String

The name of the filter

description

String

AA short description of the filter provided by the user

active

Boolean

Determines whether the filter is active at the moment

filter (Optional)

Operator

The operators the rule matches against

Example:

{
    "type": "Filter",
    "name": "master",
    "description": "Events from tenant: master. [..]",
    "active": true,
    "filter": {
        "type":"equals",
        "first":"${event.metadata.tenant_id}",
        "second":"master"
    }
}

IteratorNodeDetails

Property

Type

Description

type

String

Always set to Iterator

name

String

The name of the iterator

description

String

A short description of the iterator provided by the user

active

Boolean

Determines whether the iterator is active at the moment

target

String

An Accessor Expression defines the field of an event to iterate over

Example:

{
    "type": "Iterator",
    "name": "Iterator_Node",
    "description": "Iterates over all alerts",
    "active": true,
    "target": "${event.payload.data.alerts}"
}

RulesetNodeDetails

Property

Type

Description

type

String

Always set to Ruleset

name

String

The name of the filter

rules

RuleDetails

A list containing basic information on the rules in the Ruleset.

Example:

{
    "type": "Ruleset",
    "name": "api_neteye_cloud",
    "rules": [
        {
            "name": "foobar",
            "description": "",
            "continue": true,
            "active": true,
            "actions": [
                "elasticsearch"
            ]
        },
        {
            "name": "foo",
            "description": "",
            "continue": true,
            "active": true,
            "actions": [
                "script"
                "archive"
            ]
        }
    ]
}

Action

Property

Type

Description

id

String

The action name to execute

payload

Object

The contents of the action

Example:

{
    "id":"archive",
    "payload":{
        "archive_type":"vmd",
        "event":"${event.payload}"
    }
}