Getting it Right with Splunk

Have you ever performed calculations in Splunk and sometimes not obtained the answers you were expecting?

If so, you may have fallen foul of the way Splunk handles decimals in its calculations.

Normally in programming languages, converting an integer (for example 3) into its decimal analogue (3.0) ensures that any calculations that involve that number will be carried out to a precision of many significant figures.

For example, take the decimals 0.23 and 0.014; multiplying these together gives an exact answer of 0.00322.

However, in Splunk, the number of significant figures defines the precision of the calculations it performs and Splunk will round the result of a calculation to the lowest number of significant figures that appeared in the individual numbers that went into it.

Going back to our calculation, 0.23 is precise to two significant figures and 0.014 is also precise to two significant figures. When multiplying these together, Splunk will round the answer to the number of significant figures of the least precisely defined number. In this case, the numbers are precise to 2 significant figures, so the result produced by Splunk is rounded to 2 significant figures.

We can see this by running the following search:

 | makeresults
 | fields - _time
 | eval x1 = 0.014
 | eval x2 = 0.23
 | eval x3 = x1*x2
 | transpose 

From which we get:

As already stated, the actual answer to this calculation is 0.00322 but Splunk, because the input numbers are only to two significant figures, rounds its answer to two significant figures (0.0032).

Let us now increase the precision of one of the numbers to 3 significant figures. To do this we can append a zero – let us do this to 0.23 so that we now have 0.230 and 0.014.

If we now run the following search (note the additional zero)

 | makeresults
 | fields - _time
 | eval x1 = 0.014
 | eval x2 = 0.230
 | eval x3 = x1*x2
 | transpose 

We get:

So, even though we have increased the precision of one of the numbers, Splunk will still only round to 2 significant figures because 0.14 is only precise to 2 significant figures.

However, if we now increase the precision of 0.14 by appending a zero to give us 0.140 and run the following search:

 | makeresults
 | fields - _time
 | eval x1 = 0.0140
 | eval x2 = 0.230
 | eval x3 = x1*x2
 | transpose 

We get:

Now that both input numbers are precise to at least 3 significant figures, Splunk returns a value that is precise to 3 significant figures which in this example happens to be the correct answer.

Interestingly. if dealing with just integers, Splunk knows to perform any calculation based on these to great precision.

For example, consider the integers 1 and 6. If we do 1 divided by 6 the actual answer should be 0.1666… (the sixes carrying on to infinity). If we do carry out this calculation in Splunk:

 | makeresults
 | fields - _time
 | eval x1 = 1
 | eval x2 = 6
 | eval x3 = x1/x2
 | transpose 

We get:

However, if we instead specify 1.0 and 6.0 as the numbers in our calculation:

 | makeresults
 | fields - _time
 | eval x1 = 1.0
 | eval x2 = 6.0
 | eval x3 = x1/x2
 | transpose 

We get:

Splunk has rounded the answer off because we have only supplied numbers that are precise to 2 significant figures. If we were to add additional zeroes then the result gets rounded off after more significant figures

The Solution

Whilst appending 0s to your data to increase the level of precision in your calculations MIGHT solve your problem, Splunk comes with an inbuilt, better solution – that is the exact function.

The exact function performs the calculation specified but ensures that much greater precision is used.

Going back to our original example; if we now enclose our calculation with the exact function:

 | makeresults
 | fields - _time
 | eval x1 = 0.014
 | eval x2 = 0.23
 | eval x3 = exact(x1*x2)
 | transpose 

We get the exact answer returned to us.

Conclusion

If exact precision is required then ensure you enclose any eval calculations inside the exact function otherwise Splunk might return answers that are not what you are expecting.