Basic Search Commands and the Pipeline. This is the engine that powers every Splunk search you will ever run. If you can understand how commands connect with the pipe symbol, you can slice through terabytes of machine data to find exactly what you need — and that is the core skill tested in the SPLK-1002 exam.
Jump to a section
A simple way to picture Basic Search Commands and the Pipeline
A head chef running a busy restaurant kitchen. The chef stands at a long counter with a stack of order tickets coming in. Each ticket is a search request. The chef starts by taking the first ticket and reading it — that is the initial search command. Then the chef hands the ticket to a sous-chef who chops vegetables. That sous-chef passes the chopped vegetables to another chef who grills the meat. Each step in the kitchen is a command in a pipeline. The output of one chef becomes the input for the next. If the chef wants only the grilled chicken orders, they put a filter step in the middle. The ticket never goes back to the start — it flows one way down the bench. At the end, the finished plate is the final result. If the chef changes an earlier step, they must start a new ticket. This is exactly how Splunk search works: you write a search, then pipe the results through commands one after another. Each command transforms the data and passes it forward. You cannot go backwards in a pipeline — just like a plate cannot un-grill itself. The kitchen pipeline is fast, organised, and powerful, just like Splunk’s search processing language.
When you log into Splunk for the first time, you see a search bar. That bar is your starting point. Every search you type is a series of instructions, and each instruction is called a command. Commands tell Splunk what to do with your data. For example, the command 'search' finds events that match keywords. The command 'top' shows the most common values in a field. The command 'stats' calculates numbers like averages or counts.
But here is the important part: commands do not work alone. They work in a chain. The way you connect them is with the pipe symbol '|'. The pipe symbol looks like a vertical bar, and you find it on your keyboard above the backslash key. When you put a pipe between two commands, you are telling Splunk: 'Take the results from the first command, and send them directly into the second command as input.' That flow from left to right is called a pipeline.
Let me give you a real example. Suppose you want to find the most common error codes in your web server logs. You could type:
search error | top status_code
Here is what happens step by step:
The 'search error' command looks through all your data and finds every event that contains the word 'error'.
That set of events — maybe thousands or millions — becomes the new dataset.
The pipe symbol sends that dataset into the 'top' command.
The 'top' command counts how many times each unique status_code appears and shows you the most frequent ones.
Without the pipe, Splunk would run each command separately. You would have to write two searches and compare them by hand. The pipeline makes it automatic.
Why does this matter for the SPLK-1002 exam? Because the exam tests whether you can read and write pipelined searches correctly. You will see questions that give you a search with multiple pipes and ask what the final output looks like. You will also see questions where you must choose the right command to add at the end of a pipeline.
There are several common commands you must know for the exam. Here are the essential ones:
search: The default command. If you just type keywords without a command, Splunk automatically uses 'search'. It filters events to those matching your keywords.
top: Finds the most common values of a field. It returns a table with the field value, its count, and its percentage.
rare: The opposite of top. It finds the least common values of a field.
stats: Performs statistical calculations. You can use functions like count(), avg(), sum(), min(), max().
table: Displays results as a table with only the fields you specify.
fields: Removes fields you do not need, making the results cleaner and faster.
dedup: Removes duplicate events based on one or more fields.
sort: Orders results by a specific field, either ascending or descending.
eval: Creates new fields or modifies existing ones using expressions.
rex: Extracts fields using regular expressions.
Each of these commands can sit at any point in a pipeline. The order matters. For example, if you use 'top' first and then 'search', you will be searching only the small top results, not the original data. So you must think carefully about the sequence.
The pipeline also affects performance. Each command reduces the amount of data or refines it. If you put an expensive command like rex early in the pipeline, it will process a huge amount of data and slow you down. If you first filter with 'search' to reduce the dataset, then run rex, it will be much faster. This concept is called 'search optimisation', and the exam may test your understanding of why ordering matters.
In summary, the pipeline is the backbone of Splunk search. It lets you chain simple commands into powerful data analysis workflows. On the exam, you will need to identify the correct command for a given task, recognise the output of a pipelined search, and understand how the order of commands affects the final result. Practise writing small pipelines until it feels natural.
Write the initial search
Type keywords or a search command in the search bar to pull events from the index. For example, 'search error' finds all events containing the word 'error'. This step defines your starting dataset.
Add the first pipe symbol
Press the pipe key '|' after your initial search. This tells Splunk that the next command will use the results from the previous step as its input. The pipe must be placed exactly between two commands.
Add a transformation command
After the pipe, type a command like 'top status_code' or 'stats count by host'. This command transforms the data — for example, it counts frequencies or calculates averages. The output of this command will be a new dataset, often smaller and more structured.
Add subsequent pipes and commands
You can add more pipes and commands to refine further. For instance, after 'top status_code', add '| search status_code=500' to filter the top results to only one status. Each new pipe passes the current results forward.
Review and finalise the output
When you run the search, Splunk executes the pipeline from left to right and displays the final output. Check that the results make sense. If they do not, adjust the order or choice of commands. You cannot edit the pipeline midway — you must rewrite it from the start.
An IT professional working as a site reliability engineer at an online retailer uses Splunk pipelines every day. One morning, the monitoring system alerts that customer checkout times have spiked. The engineer needs to find out why.
Here is what they actually do step by step in Splunk:
First, they start with a broad search to get the relevant data for the last hour. They type:
search sourcetype=access_combined checkout | table _time, status, response_time, user_agent
This search pulls events from the web server logs that mention 'checkout' and shows the timestamp, HTTP status, response time, and browser info. The pipe sends the results into the 'table' command, which arranges the data neatly in columns.
The engineer sees that response_time values are all over the place. To find patterns, they use the 'stats' command to calculate averages by status code. They type:
search sourcetype=access_combined checkout | stats avg(response_time) as avg_time, count by status
The 'search' command gathers the events. The pipe sends them to 'stats', which calculates the average response time for each HTTP status code (200, 500, etc.). The 'as avg_time' renames the calculated field. The 'by status' groups the results by the status field.
The table shows that status 500 errors have an average response time of 12 seconds. That is clearly the problem. But the engineer needs to know which specific server or endpoint is failing. So they add another command:
search sourcetype=access_combined checkout | stats avg(response_time) as avg_time, count by status, uri_path
Now the results are grouped by both status and URI path. The engineer sees that /checkout/payment is returning status 500 with high response times. This narrows the culprit down to the payment service.
Next, they want to see the actual error messages. They run:
search sourcetype=access_combined checkout status=500 | table _time, uri_path, response_time
The 'search' command now includes 'status=500' to filter only errors. The pipe passes those events to 'table', showing only the timestamp, URI path, and response time. The engineer spots that errors started 15 minutes ago and have been increasing.
To confirm the root cause, they might use the 'rex' command to extract a specific error code from a message field, or 'sort' to order by response time descending. Each step refines the data and brings the engineer closer to the answer.
Finally, they document the findings and escalate to the development team. The entire investigation took five minutes because the pipeline allowed them to drill down from millions of events to a handful of specific error cases without ever leaving the search bar.
In a real business, this ability to rapidly narrow down issues means less downtime, fewer lost sales, and happier customers. The pipeline is not just an exam concept — it is the tool you will use daily in any Splunk-related job.
The SPLK-1002 exam tests Basic Search Commands and the Pipeline in several specific ways. Here is exactly what you need to know.
First, the exam expects you to know the function of each common command. You will see multiple-choice questions that say: 'Which command would you use to find the most common values of a field?' The correct answer is 'top'. They might ask: 'Which command removes duplicate results?' The answer is 'dedup'. Memorise this list:
top: finds most common values
rare: finds least common values
stats: performs calculations (count, avg, sum, etc.)
table: displays specified fields as a table
fields: keeps or removes fields
dedup: removes duplicates
sort: orders results
eval: creates or modifies fields
rex: extracts fields with regular expressions
search: filters events by keywords
Second, the exam tests your understanding of pipeline order. A common trap question gives you a search with three or four pipes and asks what the final output contains. For example:
search error | top user | search admin
What does this return? It first finds events with 'error', then finds the most common users among those events, then filters that small table to only show rows where the user contains 'admin'. The key trap is that the second 'search' operates on the output of 'top', not the original data. Beginners often think the final 'search' applies to all original data, but it does not. The pipe chain is strict.
Third, the exam loves to test the difference between 'search' and 'where'. The 'where' command is like 'search' but it works on calculated fields and uses comparison operators. For instance, 'where response_time > 1000' is valid, but 'search response_time > 1000' may not work as expected because 'search' treats '>' as a literal character. This nuance appears in at least one exam question.
Fourth, expect a question about the default command. If you type just 'error 500' without any explicit command, Splunk treats it as 'search error 500'. The exam may ask: 'What command is implied when you type keywords alone?' The answer is always 'search'.
Fifth, the exam tests 'eval' basics. You might see a question: 'Which command creates a field called latency by subtracting start_time from end_time?' The correct answer is 'eval latency = end_time - start_time'. They test that you know the syntax: eval newfield = expression.
Sixth, the exam often includes a question about 'table' versus 'fields'. 'table' displays only the fields you list and makes a table. 'fields' can either keep or remove fields, but it does not format the output as a table. Knowing this distinction can save you a point.
Finally, exam questions sometimes give you the output and ask you to pick the search that produced it. For example, a table with columns 'user' and 'count' probably came from 'stats count by user'. You need to reverse-engineer the pipeline from the result. Practise by looking at sample outputs and thinking about what commands would create them.
To summarise the exam traps:
Trap 1: Thinking a pipe resets the data to the original source. It does not — it uses the previous command's output.
Trap 2: Confusing 'search' with 'where' for numeric comparisons.
Trap 3: Forgetting that 'search' is the implicit default command.
Trap 4: Mixing up 'table' and 'fields'.
Trap 5: Not recognising that 'top' and 'rare' return counts and percentages, not raw events.
Study these patterns. They appear repeatedly in the exam.
The pipe symbol '|' sends the output of one command as input to the next command in a left-to-right sequence.
Each command in a pipeline operates only on the data received from the preceding command, not on the original full dataset.
The 'search' command is implicit when you type keywords alone — it is the default command that filters events by your keywords.
The 'top' command returns the most common values of a field along with their count and percentage, not the raw events.
Use the 'where' command for numeric comparisons (e.g., where response_time > 1000) because the 'search' command treats operators as literal text.
The 'eval' command creates temporary calculated fields in search results and never modifies the original data in the index.
The 'table' command formats output as a table and removes unlisted fields, while 'fields' only includes or excludes fields without changing the display format.
Pipeline order directly affects results: placing a broad filter early reduces data volume and improves search performance.
The 'dedup' command removes duplicate events based on one or more specified fields, keeping only the first occurrence.
The 'stats' command can calculate aggregates (count, avg, sum) and group results using the 'by' clause.
These come up on the exam all the time. Here's how to tell them apart.
search command
Filters events by keywords or field-value pairs like 'status=500'
Treats comparison operators like > and < as literal text by default
Works best for simple text-based filtering of raw events
where command
Filters results using boolean expressions like 'where response_time > 1000'
Interprets comparison operators correctly for numeric and calculated fields
Used after other commands or for complex conditional filtering
table command
Displays results as a formatted table with only specified columns
Removes all unlisted fields from the output
Best for creating clean reports or final output for sharing
fields command
Keeps or removes fields but keeps the event list display format
Can include (+) or exclude (-) fields without affecting visual layout
Best for reducing data size while preserving event structure for further processing
top command
Finds the most common values of a specified field
Returns a table with value, count, and percent of total
Used to identify dominant categories or frequent errors
rare command
Finds the least common values of a specified field
Returns a table with value, count, and percent of total
Used to identify outliers or uncommon events
dedup command
Removes duplicate events, keeping only the first occurrence for each unique combination of specified fields
Does not calculate any aggregate numbers
Useful for reducing event count when you only need one example per unique value
stats count by field
Groups events by a field and counts how many events exist in each group
Returns a summary table with count values, not the individual events
Useful for understanding distribution of values across categories
Mistake
The pipe symbol sends data backward to the previous command to be processed again.
Correct
The pipe symbol sends data forward only. Each command receives the output of the command before it and passes its own output to the next command. There is no looping or backward flow in a Splunk pipeline.
This mistake comes from confusing the pipe symbol with a loop or feedback mechanism. In other contexts, arrows sometimes mean bidirectional flow, but in Splunk the pipeline is strictly left-to-right.
Mistake
Using 'search' after 'top' searches the original full dataset again, not the small 'top' results.
Correct
When you type 'search' after 'top', it searches only the output from 'top', which is a small table of the most common values. It does not go back to the original data.
Beginners often think each command in a pipeline starts fresh from the raw data. They do not grasp that the pipeline transforms the data sequentially, and each step sees only the data passed to it.
Mistake
The 'table' command and the 'fields' command do exactly the same thing.
Correct
The 'table' command displays results as a table with the specified fields and removes any unlisted fields. The 'fields' command only keeps or removes fields but does not change the display format — results still show as a list of events.
Both commands manipulate which fields appear, so beginners assume they are interchangeable. The visual difference in output format (table vs event list) is easy to overlook when studying quickly.
Mistake
You can use 'search' to filter numeric fields with operators like > or <.
Correct
The 'search' command treats >, <, and other operators as literal characters by default. To filter numeric fields with comparisons, you must use the 'where' command or use eval first. For example, 'where response_time > 1000' works, but 'search response_time > 1000' may not give the expected results.
In everyday language, we say 'search for scores greater than 10', so it feels natural to type 'search score>10' in Splunk. The command's different behaviour with operators is a common point of confusion.
Mistake
The 'eval' command can change the original data permanently in the index.
Correct
The 'eval' command only creates temporary calculated fields in the search results. It does not modify the data stored in the index. To permanently change data, you would need to use data transformation tools or summarisation, not eval.
Because 'eval' seems to 'change' data in the results, beginners sometimes worry they will accidentally overwrite real data. They do not understand that search results are ephemeral copies, not the original indexed data.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The pipe symbol '|' connects commands in a pipeline. It takes the output from the command on the left and feeds it as input into the command on the right. This lets you chain multiple data-processing steps together.
Yes, you can chain as many pipes as you need. Each pipe sends the results forward. For example: search error | top user | fields user count.
The 'search' command treats >, <, and other operators as plain text by default. To filter numeric values with comparisons, use the 'where' command instead: 'where response_time > 1000'.
No. 'eval' creates new temporary fields or modifies existing ones only for the current search results. It never writes back to the index or changes the stored data.
'table' displays results as a neat table with only the fields you list, removing all other fields. 'fields' keeps or removes fields but keeps the event list format. Use 'table' for a clean report, 'fields' to reduce data size while keeping events.
Start with a broad search to collect relevant data, then use commands that reduce or transform the data. For example, filter first with 'search', then calculate with 'stats', then format with 'table'. Always filter early to improve speed.
You've finished Basic Search Commands and the Pipeline. Continue through the SPLK-1002 study guide to build a complete picture of the exam.
Done with this chapter?