What trigger type to choose
There is no single answer when selecting which trigger type is best. It depends on several factors, including:
Handling of ingest delay
What should happen when the alert or scheduled search triggers? Should it be paused for a time period?
Retry, which is specific to each type of trigger
If the use case is to find infrequent events, so that it would rarely elicit actions, then an alert might be the best solution, as they can set off actions as soon as the data is available for searching in LogScale. But it could also be handled by a scheduled search running very frequently.
If your query is frequently getting results, then an alert running over 1 hour with a 1 hour throttle period will behave similar to a scheduled search running over 1 hour every hour. Both will elicit actions every hour. In this case, you should use a scheduled search.
To choose between a filter alert and an aggregate alert:
If your query is a filter query, use a filter alert.
If your query uses joins, use a scheduled search.
Otherwise, use an aggregate alert.
When choosing whether to use a scheduled search or an alert, consider where the data is coming from and how quickly you want to perform your query. The following table shows some examples of different query types and which automation to use, as well as general comparision of the four trigger types.
Feature | Scheduled Search | Aggregate alert | Filter alert | Legacy alert |
---|---|---|---|---|
Needs time window | Yes | Yes | No | Yes |
Instant notification of matching events | No | Yes, but only if not throttled | Yes, but only if not throttled | Yes, but only if not throttled |
Supports aggregates | Yes | Yes | No | Yes |
Supports joins | Yes | No | No | Yes, but with Errors when Using Live join() Functions |
Supports explicit bucketing | Yes | No | No | Yes |
Timestamp used | @ingesttimestamp (default) or @timestamp | @ingesttimestamp (default) or @timestamp | @ingesttimestamp | @timestamp |
Ingest delay | Affected by ingest delay both inside and outside of LogScale when running on @timestamp, but can be handled by configuring Delay run. When running on @ingesttimestamp, only affected by ingest delay inside LogScale, but can be handled by setting Max wait time. | If run on @ingesttimestamp, only affected by ingest delay inside LogScale. If run on @timestamp, affected by ingest delay both inside and outside of LogScale. | Automatically handled in LogScale; unaffected by ingest delay outside LogScale | Affected by ingest delay both inside and outside of LogScale. |
Is triggered by | Aggregate result | Aggregate result | Single event | Aggregate result |
Retries after failure | Yes, using Backfill Limit or Max wait time | Up to 24 hours | Up to 24 hours | As long as the query produces the same result |
Can be throttled | No | Yes; up to 24 hours; required | Yes; up to 1 week; optional | Yes; up to 1 week; required |
Supports searching time windows larger than 24 hours | Yes | No | No | No |