5.2 The Search Pipeline

Splunk Core Certified User Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts & Logistics 1.2 Study Strategy & Learning Path

2 Splunk Basics

2.1 Splunk Components 2.2 Uses of Splunk 2.3 Splunk Apps 2.4 User Settings & Basic Navigation

3 Basic Searching

3.1 Running Basic Searches 3.2 Setting Time Ranges 3.3 Contents of Search Results 3.4 Refining Searches 3.5 Using the Timeline 3.6 Working with Events 3.7 Controlling Search Jobs 3.8 Saving Search Results

4 Using Fields in Searches

4.1 Understanding Fields 4.2 Using Fields in Searches 4.3 The Fields Sidebar

5 Search Language Fundamentals

5.1 Basic Search Commands & Practices 5.2 The Search Pipeline 5.3 Specifying Indexes in Searches 5.4 table, rename, fields, dedup, and sort

6 Using Basic Transforming Commands

6.1 The top Command 6.2 The rare Command 6.3 The stats Command

7 Creating Reports and Dashboards

7.1 Saving and Editing Reports 7.2 Statistical Table Reports 7.3 Chart Visualization Reports 7.4 Creating Dashboards and Adding Reports 7.5 Editing Dashboards

8 Creating and Using Lookups

8.1 Lookup Concepts and File Examples 8.2 Creating Lookup Files and Definitions 8.3 Configuring Automatic Lookups 8.4 Using Lookups in Searches

9 Creating Scheduled Reports and Alerts

9.1 Scheduled Reports 9.2 Describing and Creating Alerts 9.3 Viewing Fired Alerts

5.2 The Search Pipeline

Key Takeaways Explain This Topic AI

SPL pipelines separate stages with the pipe character |, which passes left-side results to the next command.

Terms before the first pipe are an implicit search command that retrieves matching events.

Pipelines process left to right; command order changes both correctness and efficiency.

After transforming commands such as stats or top, downstream commands operate on aggregated tables—not the original raw events.

Read each stage as producing a new result set that becomes the sole input to the following stage.

Last updated: August 2026

5.2 The Search Pipeline

Objective 4.2 asks you to examine the search pipeline . In Splunk Processing Language (SPL), the pipeline is how a search progresses through stages separated by the pipe character | . Understanding left-to-right flow is essential before you memorize individual commands, because command order changes both results and performance.

What “Pipeline” Means in Splunk

An SPL search is a sequence of stages:

An initial search retrieves events (implicit search command before the first pipe).

Each | command receives the output of the previous stage.

That command emits a new result set to the next stage.

The final stage’s output is what you see in Events, Statistics, or Visualization tabs. <object search stage> | <command A> | <command B> | <command C>

• Example: index=web sourcetype=access_combined status=500
• | fields host, status, clientip
• | stats count BY host
• | sort - count

Pipeline reading in plain language:

Find web access events with status 500.

Keep only host/status/clientip fields (plus essential internals as applicable).

Count those events by host.

Sort the counts descending.

The Pipe Character |

The pipe is the stage boundary. It does not mean OR. It means “take results on the left and feed them to the command on the right.”

• Symbol Role in SPL Common confusion
• | pipe Passes results to the next command Beginners sometimes think it means OR
• OR Boolean operator inside a search expression Not a pipeline stage marker
• Space / implied AND Combines constraints in the search stage Not a pipe

If you need OR logic, write OR inside a search expression. If you need another processing step, write | command .

• Search → Commands: Two Major Phases
• Phase A — Search (event retrieval)

Everything before the first pipe is the search expression. Splunk treats it as an implicit search command. This phase:

• Applies index/time constraints
• Applies keywords and field filters
• Returns matching events from indexers index=security sourcetype=linux_secure action=failed user=admin*

No pipe yet—this entire string is one search stage.

You can also write the search command explicitly after a pipe: | search index=security action=failed

In normal interactive searching, Users type the implicit form in the search bar.

Phase B — Piped commands (process the retrieved set)

After events are retrieved, commands reshape them:

• Command type (User view) Examples Output shape
• Filtering / field control fields , search , dedup Still event-oriented or reduced events
• Ordering sort Reordered rows
• Tabular presentation table , rename Table-friendly fields
• Transforming (Domain 5) stats , top , rare Aggregated statistics

Once a transforming command runs, downstream commands operate on the statistical table , not the original raw event list.

Left-to-Right Processing (Non-Negotiable Rule)

SPL evaluates stages strictly left to right . Later commands cannot “reach back” around earlier ones. Consequences:

Order matters — | sort | dedup is not automatically identical in intent to | dedup | sort for every goal.

Filters after transforms are late — | stats count BY status | search status=500 aggregates first, filters second.

Fields removed early stay gone — if | fields - clientip runs before a command that needs clientip , that later command cannot use it.

Renames affect downstream names — after | rename clientip AS src_ip , later commands must use src_ip .

• Same commands, different order, different efficiency index=web sourcetype=access_combined
• | stats count BY host, status
• | search status=500
• | sort - count
• versus index=web sourcetype=access_combined status=500
• | stats count BY host
• | sort - count

Both may produce host-centered failure counts, but the second pipeline filters earlier and aggregates less waste. Left-to-right thinking makes that difference obvious.

• Anatomy Diagram (Text) [Time picker + index/sourcetype/field search]
• |
• v
• Matching events
• |

| fields ...

• |
• Reduced field set
• |

| stats / top / table ...

• |
• Tables or transformed rows
• |

| sort / rename ...

• |
• Final displayed results
• Implicit Search Command — Exam Phrasing
• You may see questions like: “What command is implied at the beginning of a search?”

Answer shape: the search command.

That is why these are equivalent in concept: index=main error | search index=main error

Users almost always write the first form; architects and docs sometimes show the second to emphasize pipeline uniformity.

Streaming Through Stages: What Each Stage “Sees”

Each command sees only what the previous stage emitted.

• Worked trace: index=web sourcetype=access_combined status=404 OR status=500
• | dedup clientip
• | table _time, clientip, status, uri_path
• | sort - _time

• Stage output What exists
• After search All matching 404/500 events in range
• After dedup clientip At most one event per clientip (first retained per dedup rules)
• After table Only listed columns in a table view
• After sort Same table rows reordered by time descending

If you mistakenly put table before dedup but omit clientip , dedup cannot key on a removed field. Pipeline literacy prevents that class of error.

Pipeline vs Boolean Expressions Inside One Stage

Keep these layers distinct when reading exam stems:

Layer Example Question to ask

Boolean logic inside search (status=500 OR status=503) host=web01 Which events qualify?

Pipeline stages ... | stats count BY host | sort - count How are qualified events processed next?

A search can have complex Boolean logic and still be a single stage until the first pipe appears.

• Practical Pipeline Patterns for Users
• Pattern: Filter → select fields → present index=web sourcetype=access_combined status=5*
• | fields _time, host, clientip, status, uri_path
• | table _time, host, clientip, status, uri_path
• | sort - _time
• Pattern: Filter → aggregate → sort index=security action=failed
• | stats count BY user
• | sort 10 - count
• Pattern: Filter → dedup → table index=vpn sourcetype=vpn_logs action=login
• | dedup user
• | table _time, user, src_ip
• | sort - _time

Each pattern starts with a selective search stage, then applies only the commands needed—another restatement of filter-early discipline inside pipeline structure.

Exam Traps for Objective 4.2

• Trap Correction
• Thinking | means OR Pipe passes data to the next command
• Believing commands run right-to-left Processing is left-to-right
• Ignoring that transforms change result type After stats / top , you have tables, not raw events
• Putting necessary filters after expensive commands Move known event filters to the search stage
• Forgetting the implicit search command Terms before the first pipe are a search stage
• Why Pipelines Matter Beyond Syntax

Dashboards, reports, alerts, and lookups (later blueprint domains) all reuse the same pipeline mental model: a search produces a result set, then commands shape it into the artifact you save or schedule. If you can read a multi-pipe search left to right and explain each stage’s output, you are ready for objective 4.2 and better prepared for 4.4’s command drill.