Alerts

The "Alerts" section allows the user to obtain a high-level analysis over the active processes and receive smart alerts/notifications. Different alerts may be configured based on the use case, the available alerts are: - grid-density - flow-control - follow-track - filter-search

The user can obtain information about each one of the different alert types via GET /alert_description, using the alert name as the only needed input parameter.

Create an Alert

Alerts can be created to run on all processes (via POST /alert) or a specific process (via POST /alert/{process_uuid}). Alerts created using the POST /alert endpoint are applied not only to currently active processes, but also to any new processes started after the alert is created.

Each case uses a different endpoint, however, both of them take the same Request Body. A sample body to create an alert looks like this:

{
  "alias": "example-alert",
  "output": [
    {
      "config": {
        "host": "localhost",
        "topic": "alert/example"
      },
      "type": "mqtt"
    }
  ],
  "type": "grid-density"
}

Get the alerts information

List all the Alerts (GET /alerts)

This endpoint lists all registered alerts, whether they are currently active or not.

The response shows the alert information (type, UUID and alias) as well as its configuration parameters, trigger conditions and which output method has been configured, alongside its information.

Access the OpenAPI Swagger Docs to view an example of a Response schema.

List the active Alerts (GET /active/alerts)

This endpoint lists all currently active alerts. It shows the same information as the GET /alerts endpoint regarding the alerts themselves, but it also provides information about the process to which they are paired.

One-off alerts (created via POST /alert/{process_uuid}) are not persisted, so this listing is the only way to look up their configuration after launch.

Access the OpenAPI Swagger Docs to view an example of a Response schema.

Update an alert (PATCH /alert/{alert_uuid})

An alert's configuration or status can be modified at any time via this endpoint. Any field of the request body that is omitted is left untouched. Chaging the configuration of an alert restarts the alert aswell.

To stop an active alert just set its status to inactive. Set that alert's status to active to start it again. This will enable it on all running processes.

When changing any of the configuration fields (trigger, region, filter, parameters or output) will replace the whole configuration for that field. To keep part of the current configuration it must be resent alongside the newly changed values.

Configuration changes only take effect on the next pipeline launch; pass force as true to stop and relaunch the running pipelines immediately with the new configuration.

Access the OpenAPI Swagger Docs to view an example of a Request Body.

Delete an alert (DELETE /alert/{alert_uuid})

Delete an alert permanently, stopping it on every process first. One-off alerts (POST /alert/{process_uuid}) are not persisted, so this listing is the only way to look up their configuration after launch — e.g. what filter a follow-track pipeline is following.