Query Context

CrowdStrike Query Language (CQL) is used in a variety of situations across the product. Each use is a different context, and each context has different parameters and limitations that affect not only the operation, but also the supported functions and syntax that can be used within the context.

These contexts do not alter or modify the rules already in place for functions.

AttributeQueryLive QueryAggregate AlertFilter AlertLegacy AlertParserFilter QueryNon-aggregate Query
Description Standard query through the UI or API Live query executed during ingestion Aggregate alerts are based on aggregating queries for monitoring aggregated values Filter alerts are designed notify an action based on a specific value at least once Legacy alerts support most query syntax but have limitations for joins Parsers are designed to process incoming data and do not support joins or aggregate functions Filter queries are used in functions where a filter is required on the events during processing by the function Non-aggregate query is used to filter or process data within a function
Syntax None None None None None None None None
Function types not allowed None None Aggregate functions , Join functions Aggregate functions None Aggregate Functions , Join Functions , Widget Functions Non-aggregate functions Non-aggregate functions
Functions not allowed   bucket(), defineTable(), end(), join(), match(), now(), selfJoin(), selfJoinFilter(), start(), timeeChart()beta:repeating(), copyEvent(), defineTable(), join(), match(), selfJoin(), selfJoinFilter() bucket(), defineTable(), join(), match(), sankey(), selfJoin(), selfJoinFilter(), timeeChart(), worldMap()  
Data Sources None Old data None None None None None None

Query

Description Standard query through the UI or API
Syntax None
Function types not allowed None
Functions not allowed  
Data Sources None

The primary context of a query is execution either through the UI or the API. In this context, all functions and syntax are available, and limitations to the execution of queries are governed by the standard limit rules.

Live Query

Description Live query executed during ingestion
Syntax None
Function types not allowed None
Functions not allowed  
Data Sources Old data

A live query is executed on data while the data is being ingested. Because the event set is based on data that has not yet been written down on disk, there are limits to the processing that can be performed.

Live queries require more memory, more processing, and may limit or increase the ingest rate. This is because live queries apply additional processing on top of the main ingest function. If a live query includes joins, the live query may be restarted to ensure that the joined data is updated.

For a technical overview of how live queries are executed, see Live Queries.

Aggregate Alert

Description Aggregate alerts are based on aggregating queries for monitoring aggregated values
Syntax None
Function types not allowed Aggregate functions , Join functions
Functions not allowed bucket(), defineTable(), end(), join(), match(), now(), selfJoin(), selfJoinFilter(), start(), timeeChart()
Data Sources None

This context is used when the system is executing aggregate alerts. As a query context it is designed to execute a query based on an aggregate function, but is restricted in terms of joins and ad-hoc tables. Because the query is executed based on a timing interval, functions that control or set query time are also not supported.

The following CQL constructs are not supported:

Aggregate alerts must include:

For more information, see Aggregate alerts.

Filter Alert

Description Filter alerts are designed notify an action based on a specific value at least once
Syntax None
Function types not allowed Aggregate functions
Functions not allowed beta:repeating(), copyEvent(), defineTable(), join(), match(), selfJoin(), selfJoinFilter()
Data Sources None

As a query context, filter alerts are part of the triggers system, and are similarly limited as aggregate alerts. Filter alerts do not support the following functions:

For more information, see Filter alerts.

Legacy Alert

Description Legacy alerts support most query syntax but have limitations for joins
Syntax None
Function types not allowed None
Functions not allowed  
Data Sources None

Unlike filter and aggregate alerts, legacy alerts have fewer restrictions and limitations. Like aggregate alerts, the output of the query in this context should be an aggregate result.

Like a standard query, legacy alerts automatically include a tail() at the end of the query if an aggregate function is not already included.

Parser

Description Parsers are designed to process incoming data and do not support joins or aggregate functions
Syntax None
Function types not allowed Aggregate Functions , Join Functions , Widget Functions
Functions not allowed bucket(), defineTable(), join(), match(), sankey(), selfJoin(), selfJoinFilter(), timeeChart(), worldMap()
Data Sources None

When a query is being used to parse and extract data from an ingested event log line, the parser context is used. When parsing, query constructs that aggregate or join data are unavailable, because data is expected to be ingested for processing during a query, and raw event data is required for ingestion. This means that operations normally used for reporting or summarizing information are unavailable.

In a parser context, the use of subqueries is not supported.

Filter Query

Description Filter queries are used in functions where a filter is required on the events during processing by the function
Syntax None
Function types not allowed Non-aggregate functions
Functions not allowed  
Data Sources None

A filter query is one of LogScale's Subqueries, and is defined more specifically as a filter subquery. In this context, the the query can only contain filter syntax and functions that operate as a filter.

Non-aggregate Query

Description Non-aggregate query is used to filter or process data within a function
Syntax None
Function types not allowed Non-aggregate functions
Functions not allowed  
Data Sources None

Similar to the Filter Query context, the non-aggregate query context is a form of subquery that allows for the execution of most functions and syntax, except operations that aggregate content or bucket the content.