What if you had a million log entries from a web server, and you urgently needed to know how many times each user logged in during the last hour? Without a way to group them, you would be stuck manually counting, which is impossible. The 'stats' command in Splunk solves this exact problem by letting you group related events and instantly calculate summaries like counts, averages, and sums — giving you answers in seconds instead of hours.
Jump to a section
A simple way to picture Grouping and Analyzing Data with stats
First, you get the RSVPs for a large dinner party, which gives you a raw list of every guest and their dietary preference (vegetarian, pescatarian, meat-eater). This raw list is like a huge, unorganised set of log events. To plan the seating, you need to group these guests by their dietary preference. So you use a function: for each preference group, count how many guests there are in each category. This gives you a summary: 8 vegetarians, 5 pescatarians, 12 meat-eaters. That summary is exactly what the 'stats' command does for your data — it groups events by a field (dietary preference) and applies a calculation (count).
Now, imagine you want to know the average age of each group. You'd add that to your summary: the average age of vegetarians is 34, of pescatarians is 45, and of meat-eaters is 29. In Splunk, you do this with 'stats avg(age) by dietary_preference'. The raw list becomes a concise report that helps you make decisions — who sits with whom, where to put the vegan options. Without the 'stats' command, you would be stuck scrolling through thousands of individual RSVPs (events) and trying to add up numbers in your head. It is the tool that transforms a mountain of noise into a clear, actionable table.
The 'stats' command is one of the most powerful tools in Splunk for turning raw data into useful information. At its simplest, it lets you group events that share a common characteristic (a field) and then run a calculation on those groups. Think of it as a specialised calculator that works on groups of events rather than individual numbers.
Let us break down the most important terms. A 'field' is a labelled piece of information inside an event, such as a username, an IP address, or a status code. For example, a web server log event might have a field called 'status_code' with a value of '200' (success) or '404' (not found). A 'function' is a mathematical operation that Splunk performs on the values of a field, like counting how many events are in a group ('count') or finding the average of a numeric field ('avg()'). 'Grouping' means you tell Splunk to look at every event that shares the same value for a specific field — for example, all events where 'status_code' is '200' form one group, and all where 'status_code' is '404' form another.
Why does this exist? Before the 'stats' command, you would have to export all your data to another tool (like Excel or a database) and write complex formulas there. That process was slow, error-prone, and not real-time. Splunk's 'stats' command does all of this within the search itself, instantly. It replaces tasks that used to require dedicated data analysts or expensive business intelligence software.
Here is how you write a basic 'stats' command in the Splunk search bar. A typical search looks like this:
source=web_server.log | stats count by status_code
The pipe character (|) means 'then'. The search says: first, pull all events from the source 'web_server.log'. Then, group those events by the field 'status_code' and count how many events are in each group. The result is a table with two columns: 'status_code' and 'count'. You might see rows like '200' with a count of 5,000 and '404' with a count of 50.
The 'stats' command can use many different functions to analyse your data. Here are the most common ones you will see on the SPLK-1002 exam:
count: counts the number of events in each group. This is the most basic and frequently used function.
distinct_count (or dc): counts the number of unique values in a field within each group. For example, how many different users visited a page, even if some users visited it many times.
sum: adds up all the numeric values of a field in each group. For instance, total sales amount per region.
avg: calculates the average (mean) of a numeric field in each group. For example, average response time per server.
values: lists all the distinct values of a field found in each group. This is useful for seeing the range of datetimes or IPs involved.
list: lists all values (including duplicates) of a field in each group. It is less common than 'values' but can be useful for troubleshooting.
When you combine multiple functions in one 'stats' command, you separate them with a space. For example:
| stats count, avg(response_time), max(response_time) by server_name
This single command returns a table showing, for each server, how many events, the average response time, and the maximum response time. You can also group by multiple fields. To do that, list the fields separated by a space after 'by'. For example:
| stats count by department, location
This groups events first by department, then within each department by location. The result table will have three columns: department, location, and count.
A critical detail for the exam: the order of the fields after 'by' determines the grouping hierarchy. The first field is the primary group, and the second is the subgroup. Also, if you do not use the 'by' clause at all, 'stats' calculates the function over all the events in your search results, giving you a single row of output. For instance, '| stats count' returns just the total number of events.
Another important concept is that 'stats' only works on the fields that are present in your events. If a field is missing from an event, that event is ignored for that function. For example, if you run '| stats avg(price)', any event that does not have a 'price' field will not be counted in the average. This can lead to misleading results if you are not careful.
Finally, remember that 'stats' is a transforming command. That means it changes your raw events into a statistical table. After you run 'stats', you no longer have individual events — you have summary results. This is different from commands like 'search' or 'where', which filter events without summarising them. Understanding this transformation is key to knowing when 'stats' is the right tool for the job.
Define Your Goal
Before writing any Splunk command, decide what you want to summarise. Do you need a count of events per server? The average response time per user? The distinct users per page? Write down the group field (what to group by) and the calculation function (what to calculate). This prevents confusion later.
Filter Your Events
Write the Pipe and Stats Keyword
Add the Function and Field
Add the 'by' Clause for Grouping
Review the Result Table
Imagine you are an IT professional working for an e-commerce company that runs an online store. One morning, your manager calls you, frantic: customers are complaining that the checkout page is extremely slow. They want to know which server is causing the problem, and whether it is isolated to a particular region of the country. You have access to a large set of logs from all the web servers. Each log event contains a field for the server name (server01, server02, etc.), a field for the geographic region (US-East, US-West, EU-West, etc.), and a numeric field for the response time in milliseconds (response_time).
Without the 'stats' command, you would have to manually scroll through thousands of events, trying to spot patterns. With it, you can get an answer in seconds. Here is the step-by-step process you would follow:
1. First, you write a search to pull all events from the checkout page logs for the last hour. You use a time range picker and a search like: source=checkout_logs earliest=-1h | ...
2. Next, you pipe that into a 'stats' command to group by server name and calculate the average response time: | stats avg(response_time) by server_name
This gives you a quick table showing which servers are performing poorly. You see that 'server03' has an average response time of 3000 milliseconds (3 seconds), while all others are under 200 ms. That is your main suspect.
3. But your manager needs more detail: is this slow performance happening across all regions on that server, or only for customers in one area? You refine the search to group by both server and region: | stats avg(response_time) by server_name, region
The result shows that 'server03' is slow in the US-East region (4000 ms) but normal in EU-West (150 ms). That tells you the problem is likely network-related between the US-East region and that specific server, not a problem with the server itself.
4. To dig deeper, you might want to see the maximum response time to understand the worst-case scenario. You expand the command: | stats avg(response_time), max(response_time) by server_name, region
Now you see that while the average in US-East is 4000 ms, the maximum is 9000 ms — meaning some users experienced a 9-second wait, which is terrible for a checkout page.
Finally, you export the results to a CSV file or create a dashboard with this table. You present the findings to the network team, who can focus on fixing the connectivity issue between the US-East region and 'server03'. The 'stats' command saved you hours of manual work and provided the exact evidence needed to solve the problem.
In a more advanced scenario, you might use multiple 'stats' commands in the same search. For example, first group by server to find the worst server, then group by minute to see if the problem is constant or intermittent. But the core principle — group by a field and calculate — stays the same. For the SPLK-1002 exam, you are tested on your ability to write a single, correct 'stats' command. In the real world, you will use it dozens of times a day, often chaining multiple stats commands or combining them with other commands like 'eval' to create new fields before summarising.
The SPLK-1002 exam tests your ability to write a 'stats' command correctly and to interpret the results. The questions are not theoretical — they give you a scenario and ask you to identify the correct search syntax. They love testing a handful of specific patterns, and they set traps around common mistakes that beginners make.
First, let us list the exact concepts you must memorise:
Know the syntax: 'stats (function1), (function2) by field1, field2'. The comma between functions is optional but recommended for clarity. You must know that the 'by' clause is what triggers grouping. Without it, you get a single row.
Memorise these functions and what they do: count, dc (distinct_count), sum, avg, values, list. You will be asked to choose which function to use for a specific scenario (e.g., 'How many unique users visited the site?' answer: 'dc(user_id)').
Understand that 'count' counts events, not field values. If you want to count distinct values of a field, you must use 'dc' or 'distinct_count'. This is a classic trap.
Know the difference between 'values' and 'list': 'values' returns unique values, 'list' returns all values including duplicates. The exam will ask which one to use when you want to see every instance versus just the distinct possibilities.
Remember that 'stats' is a transforming command. After it runs, events are gone, and you have a table. This matters when you chain commands later in the search — certain commands only work on transforming commands or on events.
Now, the traps you will see:
Trap: The question asks for the 'number of unique users', and one answer option uses 'count(user_id)' while another uses 'dc(user_id)'. The wrong choice is 'count' because that counts every event with a user_id, not each unique user. The correct answer is always 'dc(user_id)'.
Trap: The question provides multiple functions in the 'stats' command but places the 'by' clause incorrectly, such as 'stats count by status_code avg(response_time)'. This is invalid syntax. The correct order is 'stats count, avg(response_time) by status_code'.
Trap: The question asks for a 'by' clause on a field that is not present in the events. The answer may present a field name that looks similar but is spelled differently (e.g., 'userName' vs 'username'). The exam expects you to match the exact field name.
Trap: The question describes a scenario where you need to see the list of all error messages for each server. Some answer options use 'values(error_message)' and some use 'list(error_message)'. The question will specify whether they want to see each distinct message only once, or every single occurrence. Read carefully.
What types of questions appear? - Multiple-choice questions asking you to choose the correct 'stats' syntax from 4 options. You will see 2 obviously wrong ones and 2 close ones. The close ones will differ in one detail, like the presence of a comma or the function name. - Scenario-based questions: 'A security analyst needs to find the average login time per user. Which search should they run?' The answer will include '| stats avg(login_time) by user'. - True/false questions about what a specific function does, such as 'The count function counts the number of unique values in a field.' This is false, and you must know that. - Questions asking you to interpret a table that is output from a 'stats' command. You might be asked, 'Based on the table, which user had the most logins?' You must be able to read the table rows and columns.
To pass this section, practise writing 'stats' commands until the syntax is automatic. Focus on the four most common scenarios: counting events per group, counting distinct values, averaging a numeric field, and listing values. If you master those, you will be well-prepared for the exam.
The 'stats' command transforms a list of raw events into a summary table by grouping events that share the same field value and applying a calculation function to each group.
Always use 'distinct_count' or 'dc' to count unique values of a field, not 'count', which counts every event in the group.
Without a 'by' clause, 'stats' calculates the function over all events in the search results, returning a single row — this is a common exam question trap.
The pipe character (|) means 'then' — your search flows from left to right, first filtering events, then summarising them with 'stats'.
If you need to manipulate a field's value (like converting units) before grouping, do it with the 'eval' command in a separate pipe before 'stats'.
After 'stats' runs, the search results are no longer individual events — they are a statistical table, so commands that require events (like 'rex') will not work afterwards.
Grouping by multiple fields creates a hierarchy: the first field after 'by' is the primary group, and subsequent fields are subgroups within it.
The 'values' function returns a list of unique values per group, while 'list' returns all values including duplicates — choose based on whether you need distinct or complete data.
These come up on the exam all the time. Here's how to tell them apart.
count
Counts every single event in the group.
Use when you want total occurrences, e.g., total page visits.
Does not ignore duplicates — if a user visits 5 times, they count 5 times.
distinct_count (dc)
Counts only unique values of a specified field within the group.
Use when you want unique entities, e.g., number of distinct visitors.
Ignores duplicates — if a user visits 5 times, they count only once.
values
Returns only distinct (unique) values of a field per group.
Use when you need to see the range of possibilities, e.g., all error codes that occurred.
Output is a comma-separated list of unique items.
list
Returns all values of a field per group, including duplicates.
Use when you need to see every occurrence, e.g., every single error message.
Output is a comma-separated list that may have repeated items.
stats with 'by'
Groups events by one or more fields.
Output has one row per unique combination of 'by' field values.
Most common use case for answering 'per X' questions.
stats without 'by'
No grouping — calculates over all events at once.
Output is a single row with the summary values.
Use for overall totals, averages, or counts across all events.
stats
Is a transforming command — it removes individual events and returns a table.
After 'stats', you cannot see the original events.
Use when you only need the summary, not the raw data.
eventstats
Is NOT a transforming command — it adds summary values to existing events.
After 'eventstats', you keep all original events and can see the summary in a new field.
Use when you need the summary for each event, such as to compare individual values to the average.
Mistake
The 'count' function counts the number of unique values in a field.
Correct
The 'count' function counts the total number of events in each group, not the unique values of a field. To count unique values, you must use 'dc' (distinct_count).
Many beginners assume 'count' works like COUNT DISTINCT in SQL, because they know a similar concept from databases. Splunk uses different terminology.
Mistake
The 'stats' command must always have a 'by' clause to work.
Correct
The 'stats' command works without a 'by' clause, in which case it calculates the function over all the events in the search results, returning a single row. For example, '| stats count' returns the total event count.
Because grouping is the most common use case, learners often forget that stats can be used without grouping, which the exam specifically tests.
Mistake
You can use 'stats' to change or clean up individual field values before grouping.
Correct
'stats' only calculates summaries; it does not modify individual events. To transform field values (e.g., convert milliseconds to seconds), you must use 'eval' before 'stats'.
Beginners try to combine field manipulation and summary in one command, misreading 'stats' as a general data transformation tool rather than a specific summarisation command.
Mistake
If you use 'stats values(field1) by field2', you will see one row per event.
Correct
You will see one row per unique value of field2. 'values(field1)' collects the unique values of field1 within that group into a single cell. The output is not one row per event, but one row per group.
This comes from not understanding that 'stats' is a transforming command that reduces the number of rows, unlike 'table' or 'fields', which keep event structure intact.
Mistake
The order of functions inside the 'stats' command affects the result.
Correct
The order of functions (e.g., 'count, avg(price)') does not affect the numeric result in any way. The order of fields after 'by' determines the grouping hierarchy, but the order of function columns is just for presentation.
People assume the order matters because they are used to order-dependent programming or because the 'by' field order matters, and they incorrectly generalise that to all parts of the command.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
'stats count' without 'by' gives a single row with the total number of events. 'stats count by field' gives one row per unique value of that field, showing how many events belong to each group.
Yes, you can group by text fields (like username) and you can use functions like 'count' or 'dc' on them. However, you cannot use 'avg' or 'sum' on text fields because those functions require numeric values.
Most likely, your field name is misspelled or the field does not exist in your events. Check the field names using the 'Fields' sidebar in Splunk or by running '| fieldsummary' before 'stats'.
'dc' stands for 'distinct_count'. Use it when you need to know how many unique values of a field exist within a group, such as counting unique visitors (dc(visitor_id)) rather than total page visits.
Yes, you can. Each 'stats' command transforms the data further. For example, you might first group by server to get counts, then pipe that into another 'stats' to calculate the average count across all servers. This is called chaining.
Technically, there is no hard limit, but the exam only tests grouping by one or two fields. Grouping by too many fields can create a huge table that is hard to read and slow to run.
You've finished Grouping and Analyzing Data with stats. Continue through the SPLK-1002 study guide to build a complete picture of the exam.
Done with this chapter?