Skip to main content

Actions

Types of Actions

An Action is an entity assigned to a monitor and responsible for performing a specific operation once the monitor detects a defined condition. Actions are the response mechanism of the monitoring system, enabling automated reactions to events.

Depending on configuration, an action can:

  • Send a notification or message.
  • Restart a connector.
  • Execute another user-defined operation.

An action cannot exist independently, it must always be linked to a monitor. This relationship ensures that every action is triggered by a monitored event or condition, forming a complete workflow: the monitor observes → the action responds.

All available types of Actions are presented in the table below.

IconDisplay NameNameDescription
Connector State iconMail Instant ActionMAIL_INSTANT_ACTION

Sends email notifications to selected recipients.

Kafka State iconRestart Connector Scheduled Action

RESTART_CONNECTOR_SCHEDULED_ACTION

Restarts the selected connector.

Time Range iconConnector Scheduled Action

CONNECTOR_SCHEDULED_ACTION

Executes selected operations on the connector.

warning

Deleting a connector linked to an action does not remove the action itself. The action remains stored in the system configuration but may not function correctly until a working connector is reassigned.

Mail Instant Action

The Mail Instant Action is responsible for sending an email notification to a specified recipient or a mailing group. Its purpose is to immediately inform users about events detected by a monitor.

When a monitor meets its condition and triggers this action, the system automatically sends an email to the configured address list. This ensures that stakeholders are promptly notified about important changes, issues, or system events without requiring manual checks.

By attaching a Mail Instant Action to a monitor, users can establish a reliable alerting mechanism that helps maintain awareness and supports fast response to operational events.

When creating a Mail Instant Action, several fields must be defined to describe its behavior. These include:

Field NameRequriedDescription

Action Pause Period

YesThe time in seconds that the system waits after a trigger is activated before executing the action. This delay allows users to control the timing of the action’s execution, ensuring it does not start immediately after the event is detected.

Mailings

NoAllows users to select mailing groups. When a group is chosen, all email addresses from that group are automatically added to the Email Addresses field. This simplifies configuration by ensuring that recipients from predefined groups are included without manually entering each address.

Email Addresses

YesDefines the list of recipients for the notification. These are the email addresses to which the system will send the alert when the action is triggered. The field can contain one or multiple addresses, including individual users or mailing groups, ensuring that the right audience is promptly informed about the event.

Restart Connector Scheduled Action

The Restart Connector Scheduled Action is designed to restart a connector when the monitor assigned to this action detects a relevant event. This action allows automated recovery of connectors, helping to maintain system stability and reduce manual intervention.

A key configuration parameter for this action is the number of restart attempts, which defines how many times the system will try to restart the connector if the initial attempt fails. By controlling the number of retries, users can balance recovery efforts with system safety and avoid excessive repeated restarts.

When properly configured, this action ensures that connectors can be automatically restarted in response to failures or state changes detected by the monitor.

When creating a Restart Connector Scheduled Action, several fields must be defined to describe its behavior. These include:

Field NameRequriedDescription

Action Pause Period

YesThe time in seconds that the system waits after a trigger is activated before executing the action. This delay allows users to control the timing of the action’s execution, ensuring it does not start immediately after the event is detected.

Max Retries

YesDefines the maximum number of attempts the system will make to restart a connector when the Restart Connector Scheduled Action is triggered.

Interval

YesSpecifies the time period between successive restart attempts. If a restart fails, the system waits for the defined interval before trying again.

Connector Scheduled Action

The Connector Scheduled Action is designed to perform various operations on a connector when triggered by an associated monitor. This action allows users to automate routine connector management tasks, reducing manual intervention and ensuring consistent operation.

Supported operations include:

  • Create – creates a new connector.
  • Update – updates the configuration of an existing connector.
  • Resume – resumes a paused connector.
  • Pause – temporarily suspends a running connector.
  • Restart – stops and then starts a connector.
  • Delete – removes a connector from the system.

By attaching a Connector Scheduled Action to a monitor, users can automate operational workflows, respond to system events, and maintain the health and stability of their data pipelines.

When creating a Connector Scheduled Action, several fields must be defined to describe its behavior. These include:

Field NameRequriedDescription

Interval

YesSpecifies the time period between successive operation attempts. If a operation fails, the system waits for the defined interval before trying again.

Max Retries

YesDefines the maximum number of attempts the system will make to perform operation on a connector when the action is triggered.

Max Retries On Error

YesThe maximum number of attempts the system will make to execute the action if an error occurs. Setting this value allows controlled retries, ensuring that the action is retried a limited number of times in case of failures.

Action Pause Period

YesThe time in seconds that the system waits after a trigger is activated before executing the action. This delay allows users to control the timing of the action’s execution, ensuring it does not start immediately after the event is detected.

Connector Operation

YesSpecifies the type of operation to be performed on the connector when the action is triggered. Available operations include CREATE, UPDATE, RESUME, PAUSE, RESTART, and DELETE. This parameter defines exactly what task the system will execute on the selected connector, allowing users to automate connector management in response to monitored events.

Config Store Name

YesUsed when the Connector Operation is set to CREATE or UPDATE. This parameter allows the user to select a previously saved configuration from the configuration store, which will be applied to the connector during the operation. It ensures that connectors are created or updated consistently using predefined settings.

Manual Connector Config

YesApplicable when the Connector Operation is set to CREATE or UPDATE. This field allows users to provide the connector configuration directly in JSON format, overriding or complementing any predefined settings from the configuration store. It enables precise and customized configuration for the connector during creation or update.