If you can't find the specific needle in your data haystack, you waste hours scrolling through irrelevant logs and miss critical security alerts. That's why working with default and calculated fields matters: it lets you instantly organise and enrich your search results so the most important information jumps out at you. For the SPLK-1002 exam, understanding how to use these fields is the difference between writing a search that works and staring at a blank results page.
Jump to a section
A simple way to picture Working with Default and Calculated Fields
Your bedroom, on laundry day. You have a giant pile of clothes that's been accumulating for two weeks. That pile is your raw machine data — everything your computer systems produced, a messy heap of logs and events. You need to find something specific, like that one missing blue sock. Your default fields are the easy, obvious sorting categories: 'top drawer' (socks), 'middle drawer' (t-shirts), 'bottom drawer' (jeans). You can instantly sort the pile into these drawers without thinking.
But what if you need something more detailed? You want to know which socks were worn on a rainy Tuesday. The default 'sock' category doesn't tell you that. So you create a calculated field by writing a rule: 'If sock is blue AND had a laundry tag from Tuesday, label it as 'rainy-day-sock'.' Splunk does this on the fly every time you search your laundry pile — it doesn't physically move the clothes, it just calculates that new label from the existing information in your data.
This is exactly how Splunk works. Default fields are the obvious pieces of information automatically extracted from every piece of data (like timestamps, source, or host). Calculated fields are your custom rules that extract or combine data to create new information — like a 'total sales' field made by adding 'price' and 'tax' together. You don't change the original data; you just tell Splunk to figure out that new value each time you search.
When you send a search into Splunk, it returns results in the form of events. Each event is a single record of something that happened — like a user logging in, a server error, or a webpage being accessed. Think of each event as a row in a spreadsheet, with columns of information. Those columns are called fields.
Default fields are the columns that Splunk automatically creates for every single event, with no extra work from you. They are the basic facts that Splunk figures out just by looking at the raw data. The most important default fields include:
host: the name of the machine (computer, server, device) that generated the event
source: the specific file, log, or input that the event came from
sourcetype: the format or type of data the event represents, like 'access_combined' for web server logs or 'syslog' for system messages
Splunk also automatically extracts a timestamp from each event and assigns it to a default field called _time. You don't need to write any code to see these fields — they are always there. You use them in your searches by typing things like host=webserver01 or source=/var/log/syslog.
But here's where it gets interesting: not all the useful information in your data comes neatly packaged as default fields. For example, a web server log might contain a line like '192.168.1.1 - GET /index.html 200 1234'. The IP address, the web page requested, the status code (200), and the bytes transferred (1234) are all sitting inside the raw event, but they aren't automatically turned into separate fields you can search on. That's where calculated fields come in.
A calculated field is a custom field you create by writing an expression or using an extraction command. It tells Splunk: 'Every time you process an event, calculate this new value based on what's already there.' You are not changing the original data; you are adding a virtual column that only appears when you search. Calculated fields are powerful because they let you enrich your data without modifying the underlying logs.
There are two main ways to create calculated fields in Splunk:
Using the `eval` command: This is the most common method. eval lets you write an equation that can combine fields, do math, convert text, and more. For example, eval total_cost = price * quantity + tax creates a new field called total_cost.
Using the `rex` command: This lets you extract fields from unstructured text using regular expressions (a fancy way of defining patterns in text). For example, you could extract the IP address from a log line that doesn't have it as a separate field.
Why do we need calculated fields at all? Imagine you have a field called response_time_ms that shows how long a webpage took to load in milliseconds. That's useful, but your boss wants to see times in seconds. You could write a calculated field: eval response_time_sec = response_time_ms / 1000. Or suppose you want to categorise users by age: eval age_group = if(age < 18, 'Minor', 'Adult'). These calculations let you shape the data into exactly the form you need for analysis.
Default fields give you the foundation — the automatic, essential metadata about every event. Calculated fields give you the flexibility to build on that foundation. Together, they let you turn raw machine data into meaningful information that answers real questions. Without default fields, you would have no instant way to filter results by host or source. Without calculated fields, you would be stuck with whatever fields the data originally contained, which is often messy and incomplete.
Identify the raw data you need to work with
Run a search and look at a sample event in the results. Identify which pieces of information are already separated into fields (these will appear in the left panel or in the table view) and which bits of useful data are just sitting inside the raw text, not yet as separate fields.
Use default fields to filter your search
Write a search that uses default fields to narrow down your data. For example, `host=webserver01 sourcetype=access_combined`. This reduces the number of events you need to process and makes your search run faster. Default fields are always indexed, so this is highly efficient.
Create a calculated field with `eval` to transform data
If your data has a field like `response_time_ms` but you need seconds, use `eval response_time_sec = response_time_ms / 1000`. This creates a new field on the fly. The new field will appear in your search results as if it was always there.
Test your calculated field in a statistics search
Pipe your search into a `stats` command to verify the calculated field works. For example: `| stats avg(response_time_sec) by host`. If the results look reasonable (e.g., 0.5 seconds instead of 500), your calculated field is correct.
Use `rex` to extract a field from raw text (if needed)
If the information you need is part of the raw event text and not yet a field, use `rex` with a regular expression pattern to extract it. For example, `| rex field=_raw "(?<ip_address>\d+\.\d+\.\d+\.\d+)"` extracts an IP address from the raw event. Then you can use the new `ip_address` field in further calculations.
Rename the calculated field for clarity (optional)
Use the `rename` command to give your calculated field a clearer name if needed. For example: `| rename response_time_sec as "Response Time (seconds)"`. This step is especially important when sharing results with non-technical stakeholders.
A medium-sized e-commerce company called 'ShopFast' uses Splunk to monitor its website. The IT team receives a complaint from a customer in Canada who experienced slow page loading times. The team needs to investigate.
First, the SOC analyst opens Splunk and runs a search for all events from the past hour. The default fields immediately help narrow the scope. The analyst enters: sourcetype=access_combined status=500 — this instantly filters to only events from web server logs where the server returned an error. Without default fields like sourcetype and status, the analyst would have to scroll through millions of raw events manually.
Next, the analyst wants to calculate the actual response time for each request. The raw log contains a field called duration_ms, which is the time the server took to respond, in milliseconds. But the business users are more familiar with seconds. The analyst creates a calculated field on the fly:
eval duration_sec = duration_ms / 1000
This simple eval command adds a new duration_sec field to every result in the search, making the data easier to read.
Now the analyst needs to identify which specific product pages are causing the slowest responses. The log contains a field uri_path which shows the page requested, like '/products/shoes' or '/checkout'. But the analyst also wants to know the geographic region of the user. That information is stored in a separate IP address field. The analyst decides to enrich the data by combining the clientip field with a lookup table that maps IP addresses to countries. Using the eval command and the lookup command together, a new calculated field called country is created.
Finally, the analyst filters to only Canadian users and calculates the average response time:
eval region = lookup('geoip', clientip).Country
search region='Canada'
stats avg(duration_sec) as avg_duration
This chain of searches uses default fields (sourcetype, status, clientip, uri_path, duration_ms) and calculated fields (duration_sec, region, country) to pinpoint that the '/checkout' page is loading 8 seconds on average for Canadian users, while the rest of the site loads in 2 seconds. The cause turns out to be a misconfigured content delivery network (CDN) server in that region.
Without default fields, the analyst starts from scratch every time. Without calculated fields, the raw data remains too abstract to be useful. The combination allows the team to drill down from a vague complaint to a specific, actionable cause in minutes.
The SPLK-1002 exam expects you to understand not just what default and calculated fields are, but also how to use them in real searches. The exam questions are practical — they ask you to identify which command or syntax creates a calculated field, or what a default field contains.
First, you need to memorise the three primary default fields: host, source, and sourcetype. The exam loves to test these because they appear in every search result. Expect a question that shows four field names and asks which one is a default field (the other three will be made up or non-default). Another common question: 'Which default field identifies the format of the data?' The answer is sourcetype.
Second, you must know the eval command inside out. The exam will give you a scenario like: 'You have a field price with values 10, 20, 30. You want to create a new field price_with_tax that is price * 1.2. Which search is correct?' The correct answer will use eval with an equals sign and the calculation. Traps include using rename instead of eval, or using eval but with incorrect syntax (like missing the as keyword, though eval doesn't use as — it automatically creates the field).
Third, the exam tests the difference between eval and rex. eval is for calculations and simple transformations. rex is for extracting fields from text using patterns. A trap question might ask you to extract an IP address from a log line. The correct answer will involve rex, not eval. However, if the IP address is already in a field, you don't need rex at all — just use that existing field.
Fourth, the exam tests your understanding of the fields command versus calculated fields. fields is used to include or exclude fields from your results — it doesn't create new ones. Calculated fields (via eval) create new data. A trap might ask: 'Which command creates a new field called total?' The answer is eval, not fields.
Key definitions to memorise:
Default field: a field automatically extracted by Splunk from every event (host, source, sourcetype, _time)
Calculated field: a field you create using eval or rex that is computed on the fly
`eval` command: creates a new field by evaluating an expression (mathematical, string, conditional)
`rex` command: extracts fields from raw text using regular expressions
Exam trap patterns:
They might show a search that uses eval but forgets the new field name, like eval price + tax instead of eval total = price + tax
They might use eval to try to extract a substring from text, which should instead be done with rex
They might ask you to identify which field is NOT a default field — common wrong answers include index, which is metadata but not technically a default field (it is an index-time property, not a field in every event)
They might give you a search that works but is inefficient, like using rex to extract a field that already exists as a default field
Focus your study on practicing eval syntax, memorising the three default fields, and understanding the difference between extracting (rex) and calculating (eval).
Default fields (host, source, sourcetype, _time) are automatically extracted from every event and let you start searching immediately without configuring anything.
Calculated fields are created using the `eval` command and do not alter the raw log data — they only exist in your search results.
Use `eval` for mathematical operations, string concatenation, and conditional logic (if/else) to create new fields.
Use `rex` to extract specific patterns from unstructured text and turn them into new fields — `eval` cannot extract text patterns.
The `fields` command removes or keeps existing fields in your results; it does not create new fields like `eval` does.
You can combine multiple `eval` statements in one search by chaining them with a pipe (`|`): `search ... | eval a=1 | eval b=2 | eval c=a+b`.
The three most tested default fields on the SPLK-1002 exam are host, source, and sourcetype.
These come up on the exam all the time. Here's how to tell them apart.
Default Fields
Automatically extracted by Splunk from every event
Always present in search results without any extra command
Examples: host, source, sourcetype, _time
Calculated Fields
Created by the user using `eval` or `rex` commands
Only present in the search where they are defined
Examples: total_cost, duration_sec, region
`eval` Command
Used for calculations and transformations (math, strings, conditions)
Creates a field with a specified name and value
Syntax: `eval newfield = expression`
`rex` Command
Used for extracting patterns from raw text
Creates fields from capturing groups in regular expressions
Syntax: `rex field=fieldname "(?<newfield>pattern)"`
`fields` Command
Used to include or exclude existing fields from results
Does not create new data, only controls visibility
Syntax: `fields + field1, field2` or `fields - field3`
`eval` Command
Used to create new fields by evaluating expressions
Actually adds new data to each event in the results
Syntax: `eval newfield = expression`
Mistake
Default fields are the only fields that exist in Splunk.
Correct
Default fields are automatically extracted, but Splunk also automatically extracts other common fields (like status codes or IP addresses) from structured data. Calculated fields add even more custom fields.
Beginners see host, source, and sourcetype always present and assume those are the only fields Splunk recognises. They don't realise Splunk auto-extracts many other fields from common data formats like JSON or web logs.
Mistake
Using `eval` permanently changes the data in Splunk.
Correct
`eval` creates a calculated field only for the duration of your search. It does not modify the raw data or add a permanent field to the index.
In everyday language, 'creating a field' sounds like you are permanently altering a database. The temporary, search-scoped nature of `eval` is counterintuitive to non-IT users.
Mistake
The `source` field and `sourcetype` field contain the same information.
Correct
`source` is the specific file or input path (e.g., `/var/log/nginx/access.log`), while `sourcetype` is the format or type of data (e.g., `access_combined`). They are different and both are default fields.
The names sound similar and both describe 'where data comes from' in a broad sense. Beginners conflate the two because they don't distinguish between a file path and a data format.
Mistake
You cannot use `eval` to combine text and numbers in the same field.
Correct
`eval` can combine strings and numbers using concatenation. For example, `eval status_message = status . " - " . status_text` combines a numeric field and a text field into one.
Programming beginners often think you can only do one type of operation at a time. The flexibility of `eval` to mix types confuses them into thinking it is restricted.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Default fields are host, source, sourcetype, and _time. They are automatically extracted from every event by Splunk and allow you to filter searches by where data came from and when it was generated.
Use the `eval` command in your search to create a calculated field. For example, `eval new_field = existing_field * 2` creates a field called `new_field` with twice the value of `existing_field`.
No. `eval` only adds a calculated field to the search results for the duration of your query. The raw data in Splunk remains unchanged.
`eval` is for calculations and value transformations (math, string operations, conditional logic). `rex` is for extracting specific text patterns from raw strings using regular expressions.
Yes. You can concatenate fields using a period (.) in `eval`. For example, `eval full_name = first_name . " " . last_name` combines first and last name with a space.
Check that you used the correct syntax: `| eval new_field = expression`. Also ensure you are piping the `eval` command correctly after a search. If the underlying field you are referencing doesn't exist, the calculated field will be empty.
You've finished Working with Default and Calculated Fields. Continue through the SPLK-1002 study guide to build a complete picture of the exam.
Done with this chapter?