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.
All terms that start with foo, except foobar.
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 about a month ago