Expressions are valid units of code that resolve to a value. Every syntactically valid expression resolves to some value, but conceptually, there are two types of expressions: those that assign value to a variable (a.k.a., with side effects), and those that evaluate to a value.
|Assigning a value||Evaluating to a value|
Filters are used in Routes to select a stream of the data flow, and in Functions to scope or narrow down the applicability of a Function. Filters are expressions that must evaluate to either
true (or truthy) or
false (or falsy). Keep this in mind when creating Routes or Functions. For example:
sourcetype=='access_combined' && host.startsWith('web')
source.endsWith('.log') || sourcetype=='aws:cloudwatchlogs:vpcflow'
Value expressions are typically used in Functions to assign a value – for example, to a new field. For example:
In a value expression, ensure that the source variable is not
empty. For example, assume you want to have a field called
len, to be assigned the length of a second field called
employeeID. But you're not sure if
employeeIDexists. Instead of
employeeID.length, you can use a safer shorthand, such as:
(employeeID || '').length.
If a field does not exist (undefined), and you're doing a comparison with its properties, then the boolean expression will always evaluate to false. For example, if
employeeIDis undefined, then both of these expressions will evaluate to false:
employeeID.length > 10, and
employeeID.length < 10.
==means "equal to," while
===means "equal value and equal type." For example,
5 == 5evaluates to true, while
5 === "5"evaluates to false.
A ternary operator is a very powerful way to create conditional values. For example, if you wanted to assign either
adultto a field
groupAge, based on the value of
age, you could do:
(age >= 18) ? 'adult' : 'minor'.
If there are fields whose names include non-alphanumeric characters – e.g.,
kubernetes.namespace_name – you can access them using
__e['<field-name-here>']. (Note the single quotes.) More details here.
In any other place where the field is referenced – e.g., in the Eval function's field names – you should use a single-quoted literal, of the form:
Wildcard Lists, as their name implies, accept strings with asterisks (
*) to represent one or more terms. They also accept strings that start with an exclamation mark (
!) to negate one or more terms.
Wildcard Lists are order-sensitive only when negated terms are used. This allows for implementing any combination of allowlists and blocklists.
|List 1||All terms that start with foo, except foobar.|
|List 2||All terms, except for those that start with foo.|
You cannot use wildcards to target LogStream internal fields that start with
__(double underscore). You must specify these fields individually. For example,
__foobartabcannot be removed by specifying
Updated 4 months ago