This lesson maps to exam objective 3.1 — Describe basic Splunk search syntax and components. The Search Processing Language, or SPL, is the single most important tool you will use in Splunk, because it is how you turn mountains of messy log data into answers you can act on. For the SPLK-1002 exam, understanding the basic structure of a search is the foundation for every other skill you will learn.
Jump to a section
A simple way to picture Introduction to the Search Processing Language
Have you ever tried to follow a recipe from a book that just listed ingredients with no instructions? You'd have flour, eggs, and sugar, but no idea what to do with them. That's what raw machine data looks like in Splunk — it's all there, but it's useless without a method to make sense of it.
The Search Processing Language (SPL) is your recipe book. Each search is a step-by-step instruction: first, you find the right ingredients (your raw data using a search term), then you mix them in a specific order (using commands like 'stats' or 'table'), and finally, you present the result as a finished dish (a table, chart, or report). Just as a recipe tells you to 'chop the onions' then 'fry them', SPL tells Splunk to 'search for error codes' then 'count them by hour'. The pipe symbol (|) is your kitchen timer that sequences each step — do this, then do that. If you follow the recipe correctly, you get a predictable, tasty result every time. But if you skip a step or mix things in the wrong order, your data 'dish' might come out half-baked or completely wrong.
Splunk is a tool designed to index and search machine-generated data. Before you can search, that data must be ingested and indexed, but this chapter focuses on what happens when you type a query into the search bar.
A basic Splunk search is like a sentence: it has a subject, a verb, and sometimes an object. The 'subject' is the search term or keyword that defines what data you are looking for. The 'verb' is the command that tells Splunk what to do with that data, and the 'object' is the argument or field that the command operates on. The entire structure is held together by the pipe character (|), which acts like a pipeline — the output of one command becomes the input for the next.
Let's break down a simple example:
error | stats count by sourcetype
'error' is the search term. This tells Splunk to look for events that contain the word 'error'. By default, this is a full-text search across all fields.
The pipe symbol (|) separates the initial search from the command that follows.
'stats' is a transforming command. It takes the results of the search and performs a statistical operation — in this case, counting how many events match 'error' for each unique value of 'sourcetype'.
'count' is the aggregation function used by 'stats'. It produces a count of events.
'by sourcetype' tells Splunk to group the counts by the values in the field 'sourcetype'. The term 'by' is a clause that specifies the grouping field.
Every search follows this general pattern:
[search terms] | [command] [arguments]
The first part of any search is the base search, also called the search term or initial filter. This is always present, even if you just type '*' which means 'match everything'. Splunk then processes this filtered data through a series of commands, each separated by a pipe.
Why does this matter? Without SPL, you would have to manually scroll through millions of lines of log files looking for a needle in a haystack. SPL gives you a structured language to ask questions like 'how many failed logins happened last Tuesday?' or 'which server has the most errors today?'. It replaces the need to write custom scripts or export data to spreadsheets for every single analysis.
There are several categories of commands you will use:
Search commands: These filter and retrieve events. Examples are 'search', 'where', and 'regex'.
Transforming commands: These turn events into statistics or tables. Examples are 'stats', 'chart', and 'top'.
Reporting commands: These format the output for display. Examples are 'table', 'rename', and 'fields'.
Sorting and grouping commands: These reorder and organise results. Examples are 'sort', 'dedup', and 'eventstats'.
A common beginner mistake is forgetting that the order of commands matters. Because data flows through the pipes sequentially, placing 'sort' before 'top' will give you a different result than placing it after. Always plan your search from left to right: first narrow the dataset, then transform it, then format the output.
Fields are a core concept in SPL. A field is a name-value pair. For example, in a web server log, 'status=404' means the field is 'status' and its value is '404'. You can refer to fields in your search by using the field name. When you use a transforming command like 'stats count by status', Splunk automatically extracts and groups by those fields. If a field does not exist, Splunk returns zero results for that group, which can be confusing if you expect a count to appear.
Finally, remember that every search takes time and system resources. A search that scans the entire index without any time filter will take much longer than one limited to the last hour. Adding a time range picker or using the 'earliest' and 'latest' modifiers in your search is a best practice for performance and for the exam.
Enter the search term
Type a keyword or field-value pair into the Splunk search bar. This is the first part of your search string. It tells Splunk which events to retrieve from the index. For example, typing 'error' retrieves all events that contain the word 'error' in any field.
Apply the time range filter
Select a time range from the dropdown menu next to the search bar, or use the 'earliest' and 'latest' time modifiers in your search string. This step narrows the dataset to a specific window, which speeds up the search and focuses the results. For the exam, remember the default is the last 24 hours.
Add the first pipe and a command
After your search term, type the pipe symbol (|) followed by a command like 'stats', 'top', or 'table'. The command tells Splunk what operation to perform on the retrieved events. For example, '| stats count by sourcetype' groups events by sourcetype and counts each group.
Add additional pipes and commands as needed
You can chain multiple commands by adding more pipes. Each subsequent command operates on the results of the previous step. For example, '| stats count by status | sort -count | head 5' counts events by status, sorts the results in descending order by count, and then shows the top 5 statuses.
Review and refine the output
Run the search and examine the results in the Statistics or Events tab. If the output is not what you expected, adjust your search term, time range, or command arguments. You might need to rename fields with the 'rename' command or change the aggregation function.
Imagine you work as a junior IT support analyst at a mid-sized online retail company. Your boss asks you to find out why customers are seeing '500 Internal Server Error' messages on the checkout page. The company uses Splunk to collect logs from its web servers, application servers, and databases.
Your first task is to write a search that retrieves all events containing the string '500' from the web server logs. You start with:
sourcetype=access_combined status=500
This tells Splunk to look only in the 'access_combined' sourcetype and only for events where the 'status' field equals 500. After running the search, you see hundreds of events. You need to understand when and why these errors occur.
Next, you add a pipe and a transforming command:
sourcetype=access_combined status=500 | stats count by date_hour
This gives you a table showing how many 500 errors occurred each hour. You notice a spike at 10 AM and 2 PM, which correspond to peak shopping times. Now you need to identify the specific pages that are failing.
sourcetype=access_combined status=500 | top limit=10 uri
The 'uri' field contains the specific page path. The results show that '/checkout/payment' is the most common failing page. Now you have a focused problem to escalate to the development team.
In a real enterprise environment, an IT professional might automate this process. They could save the search as a report and configure an alert that emails the team when the count of 500 errors exceeds 50 in an hour. They might also create a dashboard panel that displays this error rate over time. All of these capabilities start with writing a correct SPL query.
The step-by-step process an IT professional follows is:
Identify the data source: Use the 'sourcetype' or 'index' fields to limit the search to relevant data.
Apply time range: Choose an appropriate time range from the picker or using the 'earliest' and 'latest' modifiers.
Write the base search: Enter keywords or field-value pairs to filter events.
Use transforming commands: Apply 'stats', 'chart', or 'top' to summarise the data.
Format the output: Use 'table' or 'rename' to make the results readable.
Save or share: Save the search as a report, add it to a dashboard, or export the data.
This workflow is the bread and butter of a Splunk power user and is directly tested on the SPLK-1002 exam.
The SPLK-1002 exam specifically tests your understanding of basic SPL syntax and the role of each component. Expect 5-8 questions that directly assess this objective. The questions fall into a few predictable patterns.
Question type 1: Identifying the correct syntax. The exam will present a search string and ask which part is the search term, which is the command, and which is the argument. For example, in 'fail* | stats count by host', they may ask: 'Which part is the search term?'. The correct answer is 'fail*'. A common trap is that beginners think the whole string before the pipe is the search term, but in reality, the search term is just the keyword or field filter, not the commands after the pipe.
Question type 2: Order of operations. They will ask something like: 'What is the result of the following search: error | sort -count | head 5?'. The trap is that 'sort' reorders all events, then 'head' takes the first five. If you answered 'the five events with the lowest count', that would be wrong because 'sort -count' sorts in descending order (most count first), so 'head 5' takes the top five counts. The exam loves testing your understanding of command order and default sort orders.
Question type 3: Field extraction. They might present a raw log event and ask which field-value pair is correctly extracted by Splunk. For example, given the event '192.168.1.1 - - [10/Oct/2023:13:55:36] "GET /index.html HTTP/1.1" 200 2326', they could ask: 'What is the value of the status field?'. The correct answer is '200'. The trap is confusing 'status' with 'bytes' (2326) or 'method' (GET). Memorise the default fields extracted by Splunk for common sourcetypes like 'access_combined': clientip, method, uri, status, bytes.
Question type 4: Understanding the pipe symbol. They will ask: 'What does the pipe symbol (|) do in a search?'. The correct answer is: 'It passes the output of one command as the input to the next command in sequence.'. A common misconception is that the pipe symbol means 'or', which it does not.
Question type 5: Recognising invalid syntax. They might present a search like 'stats count by status | error' and ask if it is valid. The answer is no, because 'error' is a search term, not a command, and search terms cannot come after a pipe unless they are part of a command argument. The exam expects you to know that the base search must come first.
Key definitions to memorise for this exam: 'search term' (the initial filter), 'command' (an instruction that processes data), 'argument' (options passed to a command), 'pipe' (the | character that chains commands), 'field' (a name-value pair in event data). You should also know that the default time range is the last 24 hours, and that you can use wildcards like * in search terms.
A Splunk search always starts with a search term or filter, followed by one or more commands separated by the pipe (|) symbol.
The pipe symbol (|) acts as a 'then' — it passes all resulting events from one command as input to the next command in sequence.
The default time range for any search is the last 24 hours unless you manually change it to a custom range or 'All time'.
Fields are name-value pairs extracted from raw data, and you can reference them directly in commands like 'stats count by fieldname'.
The order of commands in a search matters; placing 'sort' before 'head' gives different results than placing 'head' before 'sort'.
A search term with a wildcard, such as 'error*', matches any event containing a word that begins with 'error'.
These come up on the exam all the time. Here's how to tell them apart.
Search Term
Placed at the very beginning of the search string, before any pipe.
Filters which events are retrieved from the index.
Can be a keyword, phrase, or field-value pair like 'status=500'.
Command
Placed after a pipe symbol (|) in the search string.
Performs an action on the events passed to it, such as counting or sorting.
Must be a recognised Splunk command like 'stats', 'table', or 'top'.
Pipe (|)
Chains commands in a sequence: output of one command feeds the next.
Always placed between two commands or between a search term and a command.
Cannot be used to combine search terms for logical filtering.
AND/OR Operators
Used within the search term part to combine keywords (error AND 404).
Do not chain commands; they just widen or narrow the initial event set.
Written as uppercase AND, OR, or NOT in the search term.
stats count
Returns a table with one row per unique value of the 'by' field.
Includes a 'count' column by default; can include other stats like avg.
Does not sort results by count automatically; you must add 'sort' if needed.
top command
Returns the most common values of a field, sorted by count descending.
Only outputs a limited number of results (default 10, configurable).
Automatically includes 'count' and 'percent' columns in the output.
Mistake
I can put the search term anywhere in the query, like after a pipe.
Correct
The search term must be the first element of the search string, before any pipe. Everything after a pipe must be a command, not a bare search term.
This happens because beginners think the search bar is just a text box to type anything, and they try to write natural language queries like 'error | show me top 5 IPs', not realising 'show me' is not a valid command.
Mistake
The pipe symbol (|) means 'or' — so 'error | 404' would return events that contain either 'error' or '404'.
Correct
The pipe symbol means 'then' — it passes the output of the previous command to the next. To find events with either term, you must use the OR keyword: 'error OR 404'.
This is a carryover from command-line shells like Bash, where the pipe does something similar but beginners misinterpret it as a logical operator. In Splunk, the pipe strictly means 'then do this operation'.
Mistake
If I don't include a time range, Splunk searches all time.
Correct
The default time range is the last 24 hours. You must explicitly choose 'All time' from the time range picker to search across all indexed data, or use the 'earliest' and 'latest' modifiers.
New users often assume that since no filter is visible, no filter is applied. Splunk's default behaviour is to restrict searches to the last 24 hours to protect system performance and prevent accidental full-index scans.
Mistake
Commands like 'stats' only work on numeric fields. I can't count text fields.
Correct
The 'stats count' command works on any field value, including text. It simply counts how many events have each distinct value. For example, 'stats count by sourcetype' works perfectly on a text field.
This confusion arises because other statistical functions like 'avg' and 'sum' do require numeric fields. Beginners see 'stats' and assume all its sub-functions are numeric-only.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The pipe symbol (|) separates commands in a search string. It takes the output from the command on its left and feeds it as input to the command on its right, allowing you to chain operations step by step.
No. Search terms, keywords, and field filters belong at the very beginning of the search string, before any pipe. After a pipe, you must use a valid command like 'stats' or 'table'.
This usually happens because your search term is too specific, your time range is too narrow, or the field name you used does not exist. Double-check spelling and field names, and try expanding the time range.
If you type 'error' directly into the search bar, it is equivalent to a search command. You can also explicitly use the 'search' command as your first word, but it is not required. Both approaches yield the same result.
Use the 'sort' command with a minus sign before the field name, like this: '... | sort -count'. This sorts the results by the 'count' field from highest to lowest.
A field is a name-value pair extracted from your data. For example, in a log event containing 'status=404', 'status' is the field name and '404' is its value. Fields let you filter, group, and summarise data.
You've finished Introduction to the Search Processing Language. Continue through the SPLK-1002 study guide to build a complete picture of the exam.
Done with this chapter?