.. _concepts_alerts: ************************** |c3-short| Alerts for |cp| ************************** |c3-short| enables you to detect anomalous events in the monitoring data and configure alerts to occur when those events are detected. For example, you can detect when a cluster goes down and configure an email to be sent. .. note:: When |rbac| is enabled in |c3-short|, there are some nuances to trigger, action, and alert access. For details, see :ref:`c3_rbac_alerts_access`. To learn how to access the **Alerts** page, see :ref:`c3_alerts_navigation`. Triggers and actions ==================== An alert consists of a trigger and one or more actions. The component type you can choose for a Trigger, and the metrics you can define for the trigger depends on whether you are running |c3-short| in :ref:`Normal mode ` or :ref:`Reduced infrastructure mode `. When you create a trigger, incompatible component types and metrics are filtered out. Trigger component types that are only compatible with :ref:`Normal mode `: - Topics - Brokers Trigger component types compatible with both :ref:`Normal mode ` mode and :ref:`Reduced infrastructure mode `: - Consumer groups - Clusters Each trigger is based on a metric with condition value criteria that determines when the trigger should fire. For more about Triggers, see :ref:`trigger_mgmnt`. Any actions associated with the trigger are executed when the criteria is met. Supported actions for a trigger include: - Sending an email notification to one or more accounts - Sending a Slack webhook notification - Sending a PagerDuty webhook notification that creates an incident ticket A trigger can be associated with any number of defined actions. For more about actions, see :ref:`actions_mgmnt`. To learn how to configure some example triggers and actions, see :ref:`examples_c3_alert_actions_triggers`. When a trigger fires, it executes all its associated enabled actions for which the ``Max send rate`` has not been exceeded. If the ``Max send rate`` of a particular action has been exceeded, the trigger event is added to a queue associated with the action and is included in the action event the next time it is executed (actions can report a set of triggers, not just one trigger). .. note:: Queuing does not occur when alerts (actions) are :ref:`paused ` because triggers are ignored during that interim. The maximum triggered events per alert (default: 1000) is controlled by the ``confluent.controlcenter.max.trigger.events.per.alert.config`` option. Detection of anomalous events (*triggering* criteria) is decoupled from the alert *actions* that are taken when a triggering event occurs. This means that triggers and actions are defined independently, which provides flexibility when setting one or more actions to perform when a trigger fires. Each time interceptor data is received by |c3-short|, metric values (such as consumption difference and latency) of the corresponding time windows are updated to reflect the new data. All newly updated metric values are then checked against all configured triggers to determine whether a trigger should fire. .. note:: Interceptors can conceivably report data related to any time - alerting works across all time windows, not just those near real time. .. _buffer_cg_triggers: Buffer for consumer group triggers (deprecated) ************************************************ .. tip:: The buffer feature for this trigger has been deprecated. It will be removed from |c3-short| in a future release. Do not rely on the buffer value. Triggers for consumer groups have an associated *buffer* value. The buffer enables you to require an alertable state to persist for a configurable period of time to alleviate prematurely activating a :ref:`consumer group trigger `. Additional resources ====================== - :ref:`troubleshoot_alerts` - :ref:`c3_alerts_pagerduty_email_integration` - :ref:`integration_alerts`