Splunk online course

Using Pipes to Chain Search Commands in Splunk

Learn how Splunk pipes connect SPL commands to filter, sort, limit, calculate, aggregate, and prepare search results for visualization.

Splunk Search Processing Language (SPL) lets you search, transform, and analyze indexed data. A pipe is the vertical bar character |. It passes the results from one stage of a search to the next command.

This lesson explains how to build a search pipeline, how command order changes results, and how to use commands such as search, head, sort, and stats.

What Is a Splunk Pipe?

A pipe connects consecutive SPL commands. The command on the right receives the events or transformed results produced by the stage immediately to its left.

base search | command1 | command2

For example:

index=main error | search host=web01

The base search first finds error-related events in the main index. The later search command then filters those results to events whose host field is web01.

A piped SPL query is therefore a search pipeline: an ordered series of a base search and one or more processing stages. It is not one flat expression that performs every operation simultaneously.

The Left-to-Right Processing Model

  1. Splunk uses the selected time range and the initial search criteria to retrieve matching events.
  2. The first command after a pipe receives those retrieved events.
  3. Each later command receives the output of the preceding stage.
  4. The final stage produces the results shown in the Search interface or used by a visualization.

The initial search expression is the base search. It commonly specifies an index, terms, field values, or other criteria. Commands added after a pipe further filter, transform, summarize, order, or format the current result set.

The time range picker matters before pipe processing begins. If the selected interval excludes an event, that event is unavailable to every later command. See Time Range Picker for more about setting the search interval.

Basic Pipe Syntax

Place a pipe between the base search and each subsequent command. Spaces around the pipe make a query easier to read, although the essential requirement is that the pipe separates stages.

index=main | command1 arguments | command2 arguments

Multiple pipes are allowed in one search:

index=main error | search host=web01 | head 50 | sort host

In this example, the initial search identifies matching events, the second stage narrows them by host, head limits the current results, and sort orders the retained events.

What Piped Commands Can Do

Commands operate on fields and results supplied by earlier stages. Depending on the command, a pipeline can:

  • Filter previously retrieved events with search or where.
  • Expose, select, or process fields extracted from events.
  • Create calculated fields with commands such as eval.
  • Aggregate events into summary rows with stats.
  • Order results with sort.
  • Limit displayed results with head.
  • Prepare tabular results for charts and other visualizations.

A field is a named value associated with an event or result. Fields can be default metadata fields, extracted fields, or calculated fields. The host field is a common metadata field and can be used for sorting and aggregation.

For background on field behavior, see Fields.

Limiting Results with head

The head command keeps the first specified number of results supplied by the previous stage.

index=main | head 50

The base search retrieves events from the main index. The pipe sends those events to head 50, which retains 50 results.

“First” means first according to the current ordering of the input. If the input is in the default event order, head selects the first results in that order. If a preceding command has reordered the results, head selects the first results in the new order.

Use head when you need a manageable subset for inspection or when the workflow intentionally limits the result set.

Sorting Piped Results

The sort command orders the results it receives by one or more fields.

index=main | sort host

This sends all matching results to sort, which orders them using the host field. Sorting is meaningful only when the field exists and contains useful, consistently extracted values.

Sorting and limiting are not interchangeable. These two searches process different sets:

index=main | head 50 | sort host

This first keeps the initial 50 results and then sorts only those retained events.

index=main | sort host | head 50

This first sorts the matching results and then keeps the first 50 results in that sorted order.

Query patternWhat is limitedWhat is sortedExpected outcome
search | head 50 | sort hostThe initial result streamOnly the retained 50 resultsA limited subset displayed in host order
search | sort host | head 50The sorted result streamAll results passed to sortThe first 50 results according to host order

Combining Several Commands

Consider this three-stage pipeline:

index=main | head 50 | sort host
  1. Base search: index=main retrieves matching events from the selected time range.
  2. Limit: head 50 keeps the first 50 events received from the base search.
  3. Sort: sort host orders those 50 retained events by the host field.
Pipeline stageExample syntaxInputOutput
Base searchindex=mainIndexed data in the selected time rangeMatching events
Limithead 50Matching eventsAt most 50 events
Sortsort hostThe retained eventsThose events ordered by host

When building a pipeline, ask what each stage receives and what it should return. A command that produces summary rows, such as stats, changes the type of result available to later stages.

Aggregating Results with stats

The stats command transforms individual events into aggregated rows. For example:

index=main | stats count by host

Splunk counts the matching events and creates one result row for each distinct host value. The output is no longer a raw event list; it is a summary table.

This kind of table is useful for reports, charts, and visualizations. Other commands can calculate fields or reshape data before an aggregation, provided the needed fields are available.

CommandPrimary useTypical inputExample
searchFurther filteringEvents or prior results| search host=web01
evalCreating calculated fieldsEvents with usable fields| eval duration_ms=duration*1000
statsAggregationEvents or rows with fields| stats count by host
sortOrdering resultsEvents or tabular rows| sort host
headLimiting resultsOrdered or unordered results| head 50
chart or timechartPreparing chart-oriented tablesEvents with dimensions or time values| timechart count by host

For focused examples, see Stats Command and Sort Command.

Filtering at a Later Pipeline Stage

A later search command can narrow results after the base search has identified a broader set:

index=main error | search host=web01

The first stage searches for events containing error. The second stage keeps only those events with host=web01. This makes the two filtering intentions visible as separate stages.

Filtering commands depend on the fields and values available at that point in the pipeline. If a field was not extracted, or if an earlier command removed or transformed it, a later filter may return no results.

Time Range, Fields, and Pipeline Input

The time range picker defines the interval from which the base search can retrieve events. It does not merely filter the final display; it determines the initial event population that later commands receive.

  • Default fields: Fields Splunk provides as event metadata, such as host.
  • Extracted fields: Fields identified from event data by Splunk's extraction rules or configuration.
  • Calculated fields: Fields created during the search, commonly with eval.

Before sorting or aggregating by a field, confirm that the field is present and populated for the relevant events. A missing or inconsistent host value can make sorting appear ineffective or group events unexpectedly.

To review prerequisites, see Access Splunk Web Interface, Example Search, and What Is An Index.

Troubleshooting Piped Searches

The query returns an unexpected set of 50 results

The likely cause is the position of head and sort. Decide whether you want to sort only an initial subset or sort all matching results before selecting 50. Place the commands accordingly.

A later command produces no results

The preceding search may have removed every matching event, or the referenced field may be absent. Run the pipeline incrementally: execute the base search, add one pipe, inspect the results, and then add the next command. Verify field names and values.

Sorting is not meaningful

The selected field may be missing, inconsistent, or unavailable for the events. Inspect the fields in the current results and confirm that extraction is working before using sort host.

Fewer events appear than expected

Check the time range picker first. Then temporarily remove later pipeline stages to identify whether a filter, head, aggregation, or another command reduced the results.

A command is treated as search text

A pipe may be missing or incorrectly placed. Use one pipe between the base search and each processing command:

base search | command1 | command2

Exam-Relevant Notes

  • The pipe character | passes results from the stage on its left to the command on its right.
  • The base search retrieves events; commands after the first pipe process those events or transformed results.
  • Pipeline stages execute conceptually from left to right.
  • head 50 | sort host sorts a limited subset, while sort host | head 50 selects 50 results after sorting.
  • stats count by host converts individual events into grouped summary rows.
  • The selected time range controls which events are available to the base search.
  • Commands can use default, extracted, and calculated fields, but a referenced field must be available at that stage.

Practice Checklist

  1. Run index=main with an appropriate time range.
  2. Add | head 50 and confirm that the result count is limited.
  3. Compare index=main | head 50 | sort host with index=main | sort host | head 50.
  4. Add a later filter such as | search host=web01 and observe how the result set changes.
  5. Run index=main | stats count by host and identify how raw events become summary rows.