Filters and Value Expressions

​

Let’s consider evaluation expressions before assignment expressions.

Filters

​

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'

This table shows examples of truthy and falsy values.

Value Expressions

​

Value expressions are typically used in Functions to assign a value – for example, to a new field. For example:

• Math.floor(_time/3600)
• source.replace(/.{3}/, 'XXX')

Best Practices for Creating Predictable Expressions

​

• In a value expression, ensure that the source variable is not null, undefined, or 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 employeeID exists. 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 employeeID is 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 == 5 and 5 == "5" each evaluate 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 minor or adult to a field groupAge, based on the value of age, you could do: (age >= 18) ? 'adult' : 'minor'.

Fields with Non-Alphanumeric Characters

​

If there are fields whose names include non-alphanumeric characters – e.g., @timestamp or user‑agent or 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: '<field-name-here>'.

Wildcard Lists

​

Wildcard Lists are used throughout the product, especially in various Functions, such as Eval, Mask, Publish Metrics, Parser, etc.

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. This allows for implementing any combination of allowlists and blocklists.

Wildcard Lists are order-sensitive, evaluated from left to right. This is especially relevant when you use negated terms. For negations to take precedence over wildcards when evaluated, you must list negations before wildcards.

Some examples:

You cannot use wildcards to target Cribl Stream internal fields that start with __ (double underscore). You must specify these fields individually. For example, __foobartab cannot be removed by specifying __foo*.