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 event and metric data 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 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 in your environment.

  • Conditions are inferred by comparing incoming event and metric data with values of specific event fields (for event triggers) or with data point thresholds (for anomaly and metric triggers).

  • You define the scope of your environment with queries. A scope can be as broad as all entities or as narrow as a single entity.

Trigger criteria vary by type:

  • Event triggers combine event and entity fields in the same query.

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

  • Metric triggers always include a metric name and threshold, but entity scope queries are optional.

  • Likewise, anomaly triggers include a threshold for anomaly scores and use optional queries to identify an entity scope.

The ideal trigger criteria are specific enough to identify particular conditions and particular 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.

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 in your workspace the first time you configure a Slack 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, the action service sends a message to all the destinations in the rule. Only rules can initiate actions.

You can include information from the context of an action in a rule's message with templates. However, several destinations include message fields that replace the message defined in a rule. You can still include a rule's message by using the {{{rule.message}}} template in destination message fields.

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.