Skip to content

About the action service

The action service provides tools for responding automatically to changes in your environment. You configure it to examine incoming events, metric data points, or anomaly scores and send notifications (one-way messages) when conditions match the criteria you specify.

The action service relies on the following independent components:

  • A trigger is a set of criteria that identify conditions or entities in your environment.

  • The target of an action (recipient of a notification) is a destination.

  • A rule combines one or more triggers with one or more destinations and a customized message.

The following diagram shows an example set of relationships among triggers, destinations, and rules.

  • Rule A combines Trigger 1, Trigger 2, and Destination 1.
  • Rule B combines Trigger 2, Trigger 3, Destination 1, Destination 2, and Destination 3.

You must have the Manager role to create and manage triggers, destinations, and rules.

Triggers

A trigger is a set of criteria that identify conditions or entities in your environment. The ideal trigger is specific enough to identify a particular type of change in your environment, or one or more entities, but no more. Too specific and you risk missing important changes; too broad and you risk sending misleading notifications.

Triggers cannot initiate actions. Only rules can initiate actions.

Typically, trigger criteria include queries, which range from simple comparisons ("event status equal to open") to complex series of comparisons with subordinate (child) clauses. For more information, see Trigger queries.

Trigger criteria vary by type:

  • Event triggers rely on queries and many event fields can be used in query comparisons.

  • Metric triggers always include a metric name and threshold, but queries are optional. You include a query to narrow the scope to one or more entities that use the metric.

  • Anomaly triggers rely on queries to identify entities and include a threshold for anomaly scores.

Destinations

A destination specifies the target of an action, the receiving application of a notification. Zenoss Cloud supports the following destinations:

Destinations cannot initiate actions. Only rules can initiate actions. A destination may be used in any number of rules. Slack destinations rely on the Zenoss Slack app, which you install when you configure a destination.

Rules

Tip

Create triggers and destinations before creating rules.

A rule combines one or more triggers with one or more destinations and a customized message. When conditions match any trigger in a rule, Zenoss Cloud sends a message to all the destinations in the rule. Only rules can initiate actions.

You can configure a rule to repeat its action each time a trigger matches and to send updates if conditions change significantly.

  • A repeat can be configured with a delay, so that notifications are suppressed until the delay elapses. If you configure a delay of zero, then no notifications are suppressed, which might be required for integrations with other applications.

  • Updates help you track when the conditions that previously matched a trigger are no longer present. For example, when an event is closed, acknowledged, or changes severity.

You can include information from the context of an action in a rule's message. For more information, see Message templates.

Note

Slack and Webhook destinations receive the customized message defined in a rule, while email destinations receive the message defined in the Subject and Message body fields of a destination.