Splunk online course

Splunk where Command: Filter Search Results with Eval Expressions

Learn how to use Splunk's where command to filter events and transformed results with numeric comparisons, logical conditions, eval expressions, and aggregate values.

The Splunk where command filters search results by evaluating an expression for each event or result. Only results for which the expression evaluates to the boolean value true remain in the search pipeline.

The expression used by where is an eval expression: a condition built from fields, operators, and SPL functions. You can use it after a base search returns events, or after a transforming command such as stats creates a new set of results.

This lesson assumes familiarity with SPL searches, fields, and the pipe character. See Splunk pipes, Splunk fields, and Splunk example searches for related fundamentals.

What the where Command Does

A search pipeline is the sequence of SPL commands connected by pipe characters. Each command receives the results produced by the command before it.

base search | where <eval-expression>

For every result, Splunk evaluates the expression after where. A true result continues through the pipeline; a false result is removed. If the expression evaluates to null rather than true, the result is not retained either.

For example, a web log event might contain a field named status with an HTTP status code. The following search keeps only events whose status is greater than 200:

index=<index_name> | where status > 200

HTTP status codes are numeric response codes. Common classifications include successful responses in the 200 range, client errors in the 400 range, and server errors in the 500 range.

Basic where Syntax

The general syntax is:

| where <eval-expression>

A field is referenced by its field name, without a dollar sign or quotation marks. String values, however, must be quoted. For example:

index=web sourcetype=access_combined | where status = 404

This compares the value of status with the numeric value 404. The field must exist in the events and contain values that can be compared as numbers.

Numeric Comparisons

Use comparison operators to test numeric fields such as HTTP status codes, response times, byte counts, or event counts.

Use numeric comparisons when the field represents a number. A field extracted as text can produce surprising results if values are compared lexically rather than numerically. Check the extracted field and normalize it when necessary, for example by creating a numeric value with an appropriate conversion function before filtering.

Filtering an HTTP Status Range

To keep responses greater than 200 and less than 500, both comparisons must be true:

index=<index_name> | where status > 200 AND status < 500

This excludes 200 and 500 because the operators are strict. To include a boundary, use >= or <=:

index=<index_name> | where status >= 200 AND status <= 499

Combining Conditions

Logical operators combine boolean conditions. AND requires every connected condition to be true. OR requires at least one condition to be true. NOT reverses a condition.

Parentheses make the intended grouping explicit, especially when an expression mixes AND and OR. For example, this search keeps both client errors and server errors:

index=<index_name> | where (status >= 400 AND status < 500) OR status >= 500

The same condition can be written more simply as status >= 400, but the grouped version demonstrates how to combine alternative ranges. Parentheses are valuable when each alternative has several conditions.

To exclude successful responses, you could write:

index=<index_name> | where NOT (status >= 200 AND status < 300)

When in doubt, use parentheses rather than relying on operator precedence. They make searches easier to review and reduce logic errors.

Eval Expression Behavior

where uses the same general expression style as eval. Expressions can contain field references, comparison operators, logical operators, and functions such as isnull, isnotnull, and conditional functions.

Fields and Strings

Field names are referenced directly. Quoted literals represent strings:

| where method = "POST"

Numeric literals are not quoted:

| where response_time > 2.5

String comparison is different from numeric comparison. A string comparison compares text values, while a numeric comparison compares numbers. Do not quote a value merely because it came from a log; verify how the field was extracted and what type of comparison the condition requires.

Missing and Null Values

A null value is a missing or undefined field value. A comparison involving a missing field does not produce true, so an event without status will not pass a condition such as status > 200.

Require the field to exist explicitly when that is the desired behavior:

index=<index_name> | where isnotnull(status) AND status > 200

Use isnull when you need to find events where the field is absent or null:

index=<index_name> | where isnull(status)

Decide whether missing values should be excluded, retained separately, or assigned a category. Do not assume that a missing field is equivalent to zero or an empty string.

Using where in a Search Pipeline

A where command can follow a base search that returns raw events:

index=<index_name> sourcetype=access_combined
| where status >= 400

When appropriate, filtering earlier reduces the number of events passed to later commands. This can reduce later processing and make the search easier to understand. Put conditions that can be expressed as base-search terms or ordinary search filters as early as practical, but use where when the condition needs an eval expression, function, calculated field, or aggregate.

Filtering raw events is different from filtering transformed results. Commands such as stats, chart, and some other transforming commands replace the original event stream with rows containing the fields they generate. A later where must reference fields that still exist in those rows.

Filtering Results from stats and Other Commands

where can filter an aggregate produced by stats. This example counts events by host and keeps only hosts with more than a chosen threshold:

index=<index_name>
| stats count by host
| where count > <threshold>

Here, count and host are fields in the transformed results. The original event fields are no longer automatically available. If the aggregate uses an alias, reference that alias:

index=<index_name>
| stats count AS event_count by host
| where event_count > 100

The same principle applies to fields created by eval, chart, or similar commands. For example, calculate a response class and then retain only server errors:

index=<index_name>
| eval response_class=case(status >= 500, "server_error", status >= 400, "client_error", true(), "other")
| where response_class="server_error"

eval creates or changes fields. where does not create a field; it retains or removes results according to a condition.

Choosing a Splunk Filtering Method

Use base-search terms when they express the restriction you need and can limit the initial data set. Use search for straightforward search-style filtering. Use where when you need a calculation, an eval function, a comparison between fields, a null check, or a condition on an aggregate.

Practical Patterns

HTTP Responses Above a Threshold

index=<index_name> | where status > 200

This retains responses with status values 201 and higher, assuming status is a numeric field.

Client or Server Errors

index=<index_name> | where (status >= 400 AND status < 500) OR status >= 500

This separates the two error ranges while retaining both. If all status codes from 400 onward are sufficient, | where status >= 400 is shorter.

Filtering a Calculated Value

index=<index_name>
| eval duration_seconds=duration_ms / 1000
| where duration_seconds > 2

This pattern is useful when the condition depends on a value that did not exist in the original event.

Troubleshooting where Searches

No Results

• Verify that the field name matches the extracted field exactly. Use table or fields to inspect available fields.
• Check representative values before applying the condition.
• Confirm that the field exists on the events selected by the base search.
• Review the comparison value and logical grouping.
• Check whether an earlier aggregation removed or renamed the field.

Unexpected Numeric Range Results

• Check whether the field is extracted as text instead of a number.
• Use explicit parentheses around combined AND and OR conditions.
• Check boundary operators. > excludes the boundary, while >= includes it; the same distinction applies to < and <=.

Filtering After stats Fails

• Inspect the fields produced by stats.
• Reference the aggregate field, such as count or an alias such as event_count.
• Remember that fields not included in the aggregation may no longer be available after stats.

Events Missing status Disappear

This is expected when a comparison with a missing value does not evaluate to true. Use isnull(status) or isnotnull(status) intentionally, depending on whether missing fields should be found or excluded.

Exam-Relevant Notes

• where filters; it does not create or modify fields.
• The condition after where is an eval expression.
• Only results whose expression evaluates to true remain.
• Use parentheses to make mixed logical conditions unambiguous.
• After stats, filter the fields generated by the aggregation, not fields that existed only in the original events.
• Missing fields generally do not pass comparisons, so handle null values explicitly when required.