About calculated fields
Calculated fields are fields added to events at search time that perform calculations with the values of two or more fields already present in those events. Use calculated fields as a shortcut for performing repetitive, long, or complex transformations using the eval command.
The eval
command enables you to write an expression that uses extracted fields and creates a new field that takes the value that is the result of that expression's evaluation. For more information, see eval
.
Eval expressions can be complex. If you need to use a long and complex eval expression on a regular basis, retyping the expression accurately can be tedious.
Calculated fields enable you to define fields with eval expressions. When writing a search, you can cut out the eval expression and reference the field like any other extracted field. The fields are extracted at search time and added to events that include the fields in the eval expressions.
You can create calculated fields in Splunk Web and in props.conf
. For information on creating calculated fields in Splunk Web, see Create calculated fields with Splunk Web. For information on creating calculated fields with props.conf
, see Configure calculated fields with props.conf.
Calculated fields and the search-time operations sequence
When you run a search, Splunk software runs several operations to derive knowledge objects and apply them to events returned by the search. Splunk software performs these operations in a specific sequence.
Search-time operations order
Calculated fields come sixth in the search-time operations sequence, after field aliasing but before lookups.
Restrictions
All EVAL-<fieldname>
configurations within a single props.conf
stanza are processed in parallel instead of sequentially. This means you can't chain together calculated field expressions where the evaluation of one calculated field is used in the expression for the next calculated field.
Calculated fields can reference all types of field extractions. They can't reference lookups, event types, or tags.
For more information
For more information about search-time operations, see search-time operations sequence.
Creation of a calculated field on an aliased source is not supported
You can't create a calculated field that is scoped to an aliased host, source, or source type. There are other ways you can achieve a similar result using a conditional if
eval function in the eval expression of calculated field. For example, say you want to create a calculated field called appLength
for events with response_code=200
and sourcetype=window_app
. instead of creating an alias for response_code
called source
and scoping the calculated field to that aliased source, you would directly filter the events in the eval expression using the if
function. To do that, you would configure the calculated field in Splunk Web with Field name set to appLength
and Eval expression set to if(response_code=200,len(app),null)
.
To use a configuration file to configure the calculated field on Splunk Enterprise, add the following stanza to your props.conf file:
[<window_app>] EVAL-appLength = if(response_code=200,len(app),null)
See Comparison and Conditional functions in the Search Reference.
Preventing overrides of existing fields
If a calculated field has the same name as a field that has been extracted by normal means, the calculated field will override the extracted field, even if the eval
statement evaluates to null. You can cancel this override with the coalesce function for eval
in conjunction with the eval
expression. Coalesce takes an arbitrary number of arguments and returns the first value that is not null.
If you do not want the calculated field to override existing fields when the eval
statement returns a value, use:
EVAL-field = coalesce(field, <eval expression>)
If you do not want the calculated field to override existing fields when the eval
statement returns null, use:
EVAL-field = coalesce(<eval expression>, field)
For more information about coalesce and other eval functions, see evaluation functions in the Search Reference.
Calculated fields independence
When Splunk software evaluates calculated fields, it evaluates each expression as if it were independent of all other fields. You cannot chain calculated field expressions, where the evaluation of one calculated field is used in the expression for another calculated field.
In the following example, for any individual event, the value of x
is equivalent to the value of calculated field y
because the two calculations are carried out independently of each other. Both expressions use the original value of x
when they calculate x*2
.
[<foo>] EVAL-x = x * 2 EVAL-y = x * 2
For a specific event x=4
, these calculated fields would replace the value of x
with 8
, and would add y=8
to the event.
Another example which involves the extracted field response_time
. When it is first extracted, the value of response_time
is expressed in milliseconds. Here are two calculated fields that make use of response_time
in different ways.
[<access_common>] EVAL-response_time = response_time/1000 EVAL-bitrate = bytes*1000/response_time
In this example, two things are happening with the access_common
sourcetype.
- The first EVAL changes the value of the
response_time
in allsourcetype=access_common
events so that it is expressed in seconds rather than milliseconds. The new "in seconds" value overrides the old "in milliseconds" value. - The second EVAL calculates a new field called
bitrate
for allsourcetype=access_common
events. It is expressed in terms ofbytes
per second.Bytes
is another extracted field.
In both calculations, response_time
is initially expressed in terms of milliseconds, as both EVALs are calculated independently of the other.
Configure extractions of multivalue fields with fields.conf | Create calculated fields with Splunk Web |
This documentation applies to the following versions of Splunk® Enterprise: 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.1.7, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.3.0, 9.3.1, 9.3.2
Feedback submitted, thanks!