Filter Alerts

Filter alerts are designed to be triggered when the corresponding query filters an event; each matching event triggers the alert. Filter alerts have the following attributes and behaviour:

  • An alert is triggered for each matching event.

  • Events processed through a filter alert are recorded by the system so that they triggered only once during execution.

  • Filter alerts do not support either aggregate queries or joins.

  • The @id and @ingesttimestamp should be preserved during the filter query execution and thus cannot be overwritten or removed.

  • The _bucket field, if present in the query result will be removed when the alert query executes.

  • Filter alerts will process events, including catching up for past events, for up to 24 hours. This allows filter alerts to account for ingest and delays in processing actions. While catching up, the alert will not process new events; if a single event is causing the alert of actions to fail, the alert does not trigger until that event is outside the catch-up limit.

    The configuration value FILTER_ALERTS_MAX_CATCH_UP_LIMIT can be used to set the catch-up period using Relative Time Syntax.

  • Filter alerts will wait 10 minutes for query warnings about missing data to disappear. If they do not disappear within this time limit, the alert will give up and the data will not be triggered on.

    The configuration parameter FILTER_ALERTS_MAX_WAIT_FOR_MISSING_DATA can be used to set the wait time using Relative Time Syntax.

  • Throttle limits for filter alerts are not supported.

  • The environment variable ENABLE_FILTER_ALERTS must be set to true on every host in the cluster.