Eval vs Fieldformat
Both “eval” and “fieldformat” have similar kinds of functionalities in Splunk. We used both of these commands to perform calculations, concatenations, creating new fields, comparison and conditional functionalities and much more.
Similarities:
1. Syntax for both of these commands are the same.
2. Functions we used with the “eval” command are the same as we used with the “fieldformat” command.
3. Both of these commands change the appearance of the result without changing the actual value of that event field.
NOTE: You can find lot of similarities between these two commands but we are going to differentiate between these two, which you will not find anywhere easily.
Differences:
1. You can’t use “fieldformat” command with any command that export results i.e. it will not work with command like “outputlookup” and “outputcsv”. You need to use the “eval” command there instead of “fieldformat”.
Example 1:
index=_internal | stats count by method | fieldformat new_count=tostring(count,"commas") | outputlookup my_test_fieldformat.csv
Result 1.1:
Explanation 1.1:
Here we took data from the “_internal” index, and by using stats command took the count of every unique value of the “method” field. Then using the “tostring” function with “fieldformat” command we have created a new field “new_count”, which just converted the count fields values with commas. At last we have used the “outputlookup” command to save that result in the form of lookup.
If you don’t know the functionalities of the “tostring” function then click here.
Verification 1.1:
Now search to verify lookup is saved or not,
|inputlookup my_new_fieldformat.csv
Explanation:
As you can see the field we created using “fieldformat” command i.e. “new_count” is not present in this lookup file.
Now do the same thing using “eval” instead of “fieldformat” .
Example 1.2:
index=_internal | stats count by method | eval new_count=tostring(count,"commas") | outputlookup my_test_fieldformat.csv
Result 1.2:
Verification 1.2:
| inputlookup my_test_fieldformat.csv
Explanation:
Now we have used “eval” instead of “fieldformat” and within the saved lookup file you can see the differences i.e. the field we created using “eval” command i.e. “new_count” is present in this lookup file.
2. With the concatenation function sorting will not work with the “eval” command, you need to use “fieldformat” for proper sorting.
Example 2.1:
index=_internal sourcetype=splunkd_ui_access | stats count by method | eval count="$".round(count,2) | sort count
Result 2.1:
Explanation 2.1:
Here we took data from the “_internal” index, and by using stats command took the count of every unique value of the “method” field. Then using eval command we concatenated “$” with each count value. Then we applied a “sort” command on the count field to enforce sorting the counts in ascending order, but as you can see it’s not happening.
Let’s try it with “fieldformat” then.
Example 2.2:
index=_internal sourcetype=splunkd_ui_access | stats count by method | fieldformat count="$".round(count,2) | sort count
Result 2.2:
Explanation 2.2:
Here we took data from the “_internal” index, and by using stats command took the count of every unique value of the “method” field. Then using the “fieldformat” command we concatenated “$” with each count value. Then we applied a “sort” command on the count field to enforce sorting the counts in ascending order, which is the same as earlier we have just used “fieldformat” instead of “eval”. Now as you can see sorting is working properly.
I hope you have understood this “Eval vs Fieldformat” comparison.
Happy Splunking !!!
I generally encourage dashboard developers not to format their data until the very end. This keep their data as accurate as possible. If you can do it on the dashboard great, if not, do at the end of the search.
There is another case that is not mentioned, post process searches. If Search1 gets the data and tables it, and Search2 summarizes it, you are going to want Search1 to pass Search2 accurate data. Search1 can use the fieldformat command so the display looks clean, while still allowing Search2 to process the raw data.