VMware ESXi and vSphere Cluster Management

Splunk where Command: Filter Search Results with Eval Expressions

Learn how to use Splunk's where command to filter events and pipeline results with numeric, string, Boolean, and eval-based conditions.

The Splunk where command filters search results with an eval expression. It keeps only events or rows for which the expression evaluates to true; results evaluating to false are removed before the next pipeline command runs.

A field is a named value extracted from an event or created during the search. An eval expression can use fields, literals, comparison operators, logical operators, functions, and parentheses. Because its result is typically true or false, it is also called a Boolean expression.

Purpose of the where Command

Use where when filtering depends on an expression rather than only a simple search term. It is especially useful after a base search, an event-generating command, or a command such as eval that creates a value for each result.

index=web | where status > 200

In this example, Splunk first searches the web index. The where command then evaluates status > 200 for each result. Only results with a status value greater than 200 continue through the pipeline.

Basic Syntax

| where <eval-expression>

The expression must produce a true or false outcome. A typical expression contains a field reference, a comparison operator, and a literal value.

Filtering Numeric Field Values

HTTP status codes are normally numeric values, so they can be compared with numeric operators.

index=web | where status > 200

This keeps results with status codes such as 201, 404, and 500, but not 200 or lower. The field must exist and contain a usable numeric value for the comparison to behave as intended.

index=web | where status >= 400

This keeps client-error and server-error responses, including 400 and 500. Use > instead of >= when the boundary value should be excluded.

If a field was extracted as text, inspect its values and data type. A field that looks numeric may need conversion before comparison, for example with an earlier calculation such as eval numeric_status=tonumber(status), followed by a filter on numeric_status.

Combining Conditions

AND for a range

AND requires every condition to be true. Use it to define a range.

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

This is an exclusive range: it keeps values from 201 through 499. To include a boundary, use >= or <=.

OR for alternatives

OR keeps a result when at least one condition is true.

index=web | where method="GET" OR method="POST"

This retains results whose method is either GET or POST.

NOT for exclusions

NOT negates a condition.

index=web | where NOT method="HEAD"

This excludes results where the method equals HEAD. Missing values should be handled explicitly when that distinction matters.

Parentheses for complex logic

Use parentheses to make the intended grouping unambiguous, especially when combining AND and OR.

index=web | where (status >= 400 AND status < 600) OR status=302

This keeps error responses in the 400–599 range or redirects with status 302. Without parentheses, the expression may be harder to read and easier to misinterpret while troubleshooting.

Strings, Numbers, and Field References

String literals normally require quotation marks:

| where method="GET"

Numeric literals are normally written without quotation marks:

| where status >= 400

Use the extracted field name directly in the expression. Field availability depends on the search and commands that ran before where.

For field names containing spaces or special characters, use the field-name syntax supported in eval expressions, commonly single quotes around the field name:

| where 'response status' >= 400

Prefer simple field names such as status, method, and user when designing extractions or calculated fields. They are easier to read and less likely to require special quoting.

Using Eval Functions in where

Because where accepts eval expressions, it can use supported eval functions. The following patterns cover common filtering tasks without attempting to list every available function.

Match a pattern

Use a pattern-matching function when exact equality is not sufficient.

| where match(uri, "^/api/")

This keeps results whose uri begins with /api/. Inspect the actual field values before choosing a pattern.

Test for missing or present values

A null value is a missing or undefined field value. Use an explicit null test when a field is optional.

index=web | where isnotnull(user)

This retains results for which user is present. The inverse pattern is isnull(user).

Check membership in a set

For several accepted values, use the in function instead of repeating many OR conditions.

| where in(method, "GET", "POST", "PUT")

This is equivalent in intent to checking each permitted method with OR.

Pipeline Placement and Result Behavior

A pipeline is the ordered sequence of SPL commands connected by pipe characters. A where command can follow a search that returns events with a field:

index=web | where status > 200

It can also follow a command that creates or calculates a field:

index=web | eval response_class=if(status>=500,"server_error","other") | where response_class="server_error"

The eval command must appear before where because response_class does not exist until eval creates it. Filtering earlier can reduce the number of results processed by later commands, provided the fields needed by the condition already exist.

Commands that produce rows, such as transforming commands, can also be followed by where when the resulting rows contain the referenced fields. Always check the output of the preceding command before choosing a field.

where Versus Search Filtering

A base search uses terms such as an index, source, event text, or simple field matching to find candidate events. The search command is the explicit pipeline form of search filtering:

index=web method=GET | search status>=400

where is different in purpose. It evaluates an eval-style expression and is well suited to calculated comparisons, functions, Boolean grouping, and filtering results produced earlier in the pipeline.

index=web | eval duration_ms=duration*1000 | where duration_ms > 1000

Field extraction and command order matter for both commands. If status has not been extracted, or if a calculated field is created after where, the condition cannot filter the intended value.

Validation and Troubleshooting

No results are returned

• Run the search without where and inspect the available fields and their values.
• Verify the field name, including capitalization and spelling.
• Confirm that the required field extraction occurred before where.
• Check whether a numeric comparison is being applied to a field stored as text.
• Test one condition at a time before combining conditions.

index=web | table status method user

Displaying relevant fields can reveal whether the field is absent, differently named, empty, or formatted differently than expected.

Unexpected values appear in a range

• Check whether the boundary should use > or >=, and similarly for < and <=.
• Use AND for a range that must satisfy both boundaries. Using OR usually makes the condition much less restrictive.
• Add parentheses around grouped conditions.
• Test the lower and upper boundary conditions separately.

A text comparison does not match

• Put string literals in quotation marks.
• Check capitalization and whitespace in the stored value.
• Inspect the raw field value for prefixes, suffixes, or unexpected formatting.
• Use an appropriate string or pattern-matching function when exact equality is not the right test.

A calculated field cannot be filtered

Place the command that creates the field before where, then inspect the calculated value:

index=web | eval response_class=if(status>=500,"server_error","other") | table status response_class | where response_class="server_error"

For a simpler diagnostic, temporarily omit where and display the calculated field. This confirms whether the expression produces the value you expect.

Practical Patterns

index=web | where status > 200

Retains HTTP responses above 200.

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

Retains statuses from 201 through 499.

index=web | where status >= 400

Retains client-error and server-error responses.

index=web | where method="GET" OR method="POST"

Retains either of two request methods.

index=web | where (status >= 400 AND status < 600) OR status=302

Retains errors plus a specific redirect response.

index=web | where isnotnull(user)

Retains results where the optional user field is present.

Exam-Relevant Notes

• where retains results only when its eval expression is true.
• Use quoted literals for strings and unquoted literals for ordinary numeric values.
• Use AND to require multiple conditions and OR for alternatives.
• Use parentheses when mixing logical operators or when the intended grouping needs to be explicit.
• A field must exist before where can use it; place eval before where for calculated fields.
• When filtering produces no results, first inspect the fields and values without the filter.

For related filtering examples, see the Splunk where command reference.