Without event correlation, you would drown in a sea of unrelated log entries — a login failure here, a failed payment there — with no way to see they are two pieces of the same puzzle. Event correlation techniques let you join these pieces together so you can answer big questions like: 'Is this one user having many problems, or are many users having the same problem?' This matters for the SPLK-1003 exam because you will be asked to use commands like stats, streamstats, and eval to turn scattered events into meaningful insights, just like a detective assembling clues.
Jump to a section
A simple way to picture Event Correlation Techniques
The head chef in a busy restaurant kitchen is the real-world role at the centre of this scene. They don't just cook one dish at a time; they coordinate dozens of orders coming in from the pass, each one a different table, each dish requiring different preparation times and ingredients. A waiter shouts an order for table 7: a well-done steak, a Caesar salad, and a gluten-free pasta. At the same time, a second waiter calls out table 3: a rare steak, the same pasta, and a side of asparagus. The chef must correlate events — linking the steak order with the right table number, checking the pasta order to see if it matches a gluten-free version or a standard one, and ensuring the rare steak and the well-done steak are cooked to different timings. They use mental 'stats' to count how many of each dish are needed, 'streamstats' as each new ticket arrives to update their plan on the fly, and 'eval' to decide, for example, which steak gets the grill first based on cooking time. If they just cooked each ticket blindly, they might serve the wrong steak to table 7 or forget the gluten-free pasta altogether. This is exactly what event correlation does in Splunk: it connects scattered pieces of data to build a single, coherent story of what really happened.
Event correlation is the process of connecting related events across time, source, or attributes to discover patterns, relationships, and root causes. In Splunk, an 'event' is a single record of something that happened — for example, a log entry showing a user logging in at 10:00 AM, or a server returning an error code at 11:02 AM. Without correlation, these events are just isolated dots on a timeline; with correlation, you can draw lines between them to see a bigger story.
Let's start by defining the three main commands you will use for correlation on the SPLK-1003 exam: stats, streamstats, and eval.
'stats' is a command that aggregates (summarises) data across a set of events. For example, if you have a thousand login events, stats can count how many times each user logged in, or find the average time between logins. It works like a calculator for your events — you feed it a field (like 'user') and an aggregation function (like count or avg) and it gives you a single result per group. This is useful for spotting trends, like which users have the highest failure rate.
'streamstats' is similar to stats, but it runs across events in order, one at a time, adding a running calculation to each event. Imagine you are watching a video of your data events playing in sequence. Streamstats gives you a running count, sum, or average as each new event appears. For instance, you could use streamstats to calculate cumulative bytes transferred across a session, with each new event showing the running total so far.
'eval' is used to create new fields and evaluate expressions. It does not aggregate — it works on a per-event basis. With eval, you can combine, transform, or calculate values. For example, you might use eval to convert a timestamp into a readable date, or to combine a first name and last name field into a single 'full_name' field. It is the tool for shaping data before you correlate it.
Now, how do these commands work together? Suppose you want to investigate a user who was charged twice for the same transaction. First, you use eval to create a combined field that concatenates the 'user_id' and 'transaction_id' into a unique key. Then you use stats with a count of that key to find any keys that appear more than once — those are the duplicates. Then you use streamstats to order those duplicate events by timestamp and assign a sequence number to each one, helping you see which came first.
Why does correlation exist? Because raw logs are often meaningless in isolation. A single error code like '401' could mean an invalid password for one user, or a token expiry for another. By correlating events from the same user (using stats to group by user) and then checking the time between events (using eval to calculate time differences), you can identify which scenario is happening. This replaces manual guesswork and saves hours of tedious searching through logs.
What does it replace? Before correlation tools, IT professionals had to manually scroll through log files, looking for patterns by eye, or write complex scripts to join data. Splunk's correlation commands make this process fast, repeatable, and accessible to non-programmers. The exam expects you to know not just the syntax, but when to choose each command. For instance, if you need a running total, streamstats is the answer; if you need a final summary, use stats.
1. Define your question
What pattern are you looking for? For example: 'Are there duplicate transactions for the same user?' This step matters because it guides which commands you will use. If you want a running total, you will prioritise streamstats. If you want a final count, you will use stats.
2. Prepare your data with eval
Use eval to create a composite field that uniquely identifies each event for correlation. For duplicate detection, you might concatenate 'user_id' and 'transaction_id' into a single field like 'unique_key'. This step is critical because correlation requires a meaningful key to group or compare events.
3. Aggregate with stats
Run stats count by your composite field to find any keys that appear more than once. This reveals the duplicate events. If no duplicates exist, stats will show all counts as 1. This is the core of many correlation searches for patterns like repeated failures or duplicate charges.
4. Order events with sort and streamstats
Sort the duplicate events by timestamp, then use streamstats to assign a running sequence number or cumulative count. For example, streamstats count as sequence_number by unique_key. This helps you see the order of events and identify which happened first, last, or in bursts.
5. Evaluate time differences with eval
Use eval to calculate the time difference between consecutive events. For instance, eval time_diff = _time - previous_time. This reveals if events are occurring at regular intervals, suggesting a timeout or retry loop. This is often the step that confirms the root cause of an issue.
An IT professional at an e-commerce company named 'ShopFast' needs to investigate a report that customers are failing to complete purchases during checkout. The support team says they have received a dozen complaints in the last hour. The IT person opens Splunk and runs a search for all checkout-related events in the last hour.
First, they use eval to categorise events: they create a new field called 'error_type' that marks each event as either 'payment_declined', 'cart_timeout', or 'successful_checkout'. This lets them separate the noise from the signal. They can see there are 500 events, but it is not obvious which are related.
Next, they use stats to group these events by 'customer_id' and count how many errors each customer experienced. The output shows that one customer, 'cust_1234', has 15 failed payment attempts in the last hour, while most other customers have only one or two. This tells them the problem might be specific to that customer's account or card, not a system-wide error.
To dig deeper, they use streamstats on the events for 'cust_1234', sorted by timestamp. Streamstats creates a running count of events per minute. They notice that between 14:30 and 14:35, the count spikes to 8 events — far more than any other five-minute window. This suggests the customer was trying repeatedly, maybe due to a timeout on the payment page.
Finally, they use eval to calculate the time difference between consecutive events for that customer. They find that the gap between attempts is exactly 30 seconds, which matches the payment gateway's timeout setting. This confirms the root cause: the payment gateway is timing out after 30 seconds, but no error message is shown to the customer, so they keep clicking 'Pay' repeatedly.
Armed with this insight, the IT pro escalates to the payments team to adjust the timeout setting. They also use stats to generate a report showing how many customers were affected overall, to prioritise the fix. The entire investigation took 15 minutes, whereas manually reading logs would have taken hours.
This scenario shows how an IT professional uses event correlation every day:
To identify outliers (one customer with many errors vs many customers with few errors)
To find patterns in time (spikes of activity at specific minutes)
To calculate differences (time between attempts)
To build reports that justify changes to the business
The SPLK-1003 exam tests event correlation techniques in several specific ways. First, you will get questions that ask you to choose the correct command for a given task. They love to pit 'stats' against 'streamstats'. A typical trap question: 'Which command do you use to calculate a running total across ordered events?' The obvious wrong answer is 'stats', because it also calculates totals — but stats gives you a total for the whole set, not a running one. The correct answer is 'streamstats'. Memorise this distinction.
Another common question type: you are given a search result with raw log data and asked to write a correlation search to find duplicate transactions. The exam expects you to use eval to combine the transaction key fields, then stats with count to find duplicates, and then a where command to filter for count > 1. This is a classic pattern.
What exact concepts do they love to test? - The difference between 'stats' and 'streamstats': stats returns one result per group; streamstats returns one result per event with the running calculation appended. - The use of 'eval' for creating new fields: they may ask you to correct a search that uses 'eval' incorrectly (e.g., using 'eval' to try to aggregate, which it cannot do). - The 'by' clause in stats: without 'by', stats aggregates everything into one row; with 'by', it groups results. They often test this with a question like: 'What does stats count by <field> do?' - The ordering requirement for streamstats: streamstats respects the order of events in the search pipeline. If events are not sorted by a time field, streamstats will apply the running calculation in the order they arrive, which is often wrong. Expect a question that tests whether you remember to use 'sort' before 'streamstats'.
Traps they set:
They might give you a scenario where the time field is not the default '_time', and they expect you to use 'sort _time' or 'sort timestamp' explicitly.
They might ask for a 'cumulative' calculation but phrase it as 'running total'. If you pick 'stats', you lose points.
They might test 'eval' with 'if' or 'case' — these are conditional functions within eval. For example, 'eval status = if(error_code=200, "Success", "Failure")'.
To pass, you must know the syntax cold. The exam uses multiple choice, and often the wrong answers look almost right. Practise writing these commands manually, not just clicking in a GUI. Focus on the verbatim definitions from Splunk documentation for stats, streamstats, and eval.
Use stats when you need a single summary row per group, such as counting how many times each user logged in.
Use streamstats when you need a running total or cumulative calculation as each event is processed in order.
Use eval to create new fields, transform values, or combine fields on a per-event basis, never for aggregation.
Always sort your events by the relevant time field before using streamstats to ensure correct chronological order.
The 'by' clause in stats is mandatory for grouping; without it, stats returns a single aggregated row across all events.
Eval supports conditional logic with 'if' and 'case' functions, allowing you to categorise events based on conditions.
When correlating, structure your search by using eval first to prepare fields, then stats or streamstats to find patterns.
These come up on the exam all the time. Here's how to tell them apart.
stats
Returns one row per group or one total row if no 'by' clause is used
Does not depend on event order; all events are processed at once
Best for final summaries, counts, averages, and max/min values
streamstats
Returns one row per event with a running calculation appended to each row
Requires events to be sorted in a meaningful order before use
Best for cumulative totals, running counts, and sequential analysis
eval
Works on a single event at a time, never aggregates across events
Can create new fields, combine fields, and apply conditional logic
Does not have a 'by' clause; cannot group results
stats
Aggregates across events, returning summary rows
Cannot create new fields from scratch; only calculates aggregations on existing fields
Uses 'by' clause to group results by field values
sort before streamstats
Ensures running calculations are applied in chronological order
Returns meaningful cumulative values (e.g., cumulative errors over time)
This is the correct and expected pattern for SPLK-1003 exam questions
no sort before streamstats
Streamstats applies calculations in the order events arrive, which may be random
Running total values are meaningless if order is not controlled
This is a common trap the exam sets — avoid this mistake
Mistake
stats and streamstats are interchangeable; the only difference is the spelling.
Correct
They have fundamentally different outputs: stats aggregates all events into summary rows, while streamstats calculates on a per-event basis in order. They cannot be swapped without changing the result.
The names sound very similar, and both perform mathematical operations, so beginners assume they are just synonyms. The different output shape (one row vs one row per event) is not obvious without trying it.
Mistake
eval can be used to group events together, like stats does with 'by'.
Correct
eval works on a single event at a time and cannot aggregate across multiple events. It can create new fields, but it never combines rows. To group, you must use stats or another aggregation command.
Eval is so versatile for calculations that beginners naturally try to make it do everything. The idea of 'grouping' feels like a calculation, but eval does not have a 'by' clause.
Mistake
streamstats will automatically sort events by time before applying its calculations.
Correct
streamstats does not sort; it applies its running calculation in the order events arrive in the search pipeline. You must explicitly use 'sort' on the time field before streamstats to get chronological results.
Other Splunk commands sometimes default to sorting by _time, so beginners assume streamstats does the same. The distinction is subtle and often not explained in basic tutorials.
Mistake
When using stats, if you do not include a 'by' clause, it will still group by some default field.
Correct
Without a 'by' clause, stats aggregates across all events into a single row. There is no default grouping. This is a common source of confusion.
In everyday language, 'stats' implies breaking things down, so the idea of a single aggregate without grouping seems counterintuitive. Beginners expect it to group by something natural like time or source.
Mistake
You can use eval to replace values in an existing field without creating a new field.
Correct
Eval always creates a new field or overwrites an existing one explicitly. It does not modify the original data in place. If you want to change the value of 'status', you must write 'eval status = ...' which overwrites it.
Beginners think 'eval' is like a find-and-replace tool that modifies data invisibly. They do not realise it is a transformation that returns a new field.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Stats aggregates all matching events into one or a few summary rows, while streamstats adds a running calculation to each event as it is processed. Use stats for final summaries and streamstats for cumulative values across ordered events.
No, eval works per-event and cannot count across events. Use stats to count events. Eval is for creating or transforming fields on a single event basis.
Yes, always sort your events by the time field before using streamstats, otherwise the running calculation will be applied in whatever random order the data arrives, giving incorrect results.
The 'by' clause tells stats to group results by the values of one or more fields. Without 'by', stats aggregates all events into a single row. With 'by', you get one row per unique value of the field(s).
Use eval to combine transaction-specific fields like user_id and transaction_id into a unique key, then stats count by that key, then where count > 1 to isolate duplicates.
A running total is the sum of values as they appear in order — for example, the cumulative bytes transferred over time. Use streamstats with sum(field_name) to calculate it on ordered events.
You've finished Event Correlation Techniques. Continue through the SPLK-1003 study guide to build a complete picture of the exam.
Done with this chapter?