In our last blog, part one of the eval command series, we covered the basics of using eval as well as a few functions of the command. Let’s keep the ball rolling into part two.
First, let’s add one more thing to your list of eval basics. Let’s not forget a crucial component to eval command… at results time of the search, if you’ve created a new field using eval, then a new column will be added to the results table. This means that if you have three columns listing Name, Id, and count and you write the follow the line at the end of your search:
|eval percent = (count/number)*100
This will add a fourth column that will have a percent value per row.
Let’s talk comparisons
Now, let’s talk about comparisons. Sometimes, we just need to add a bit of flavor to our data, like web status codes. Sure, sure, we all know the common ones like 200 and 404, but what about the other ones? Once you go looking at the code definitions, you begin to realize, there are a plethora of codes and “ain’t nobody got time for that”. What if I told you that we could put a general description of our status codes? That’s where if and case step in.
If and Case with eval
IF and CASE are in the same vein of comparison, however, CASE will allow for more arguments. Let’s take a quick look at these two:
|eval test = if(status==200, “Cool Beans”, “No Bueno”)
Here’s the breakdown, when using IF, we need to pass three arguments:
- The condition – this is usually “if something equals some value”
- The result – if said field does equal the defined value, then the test’s value is the argument
- The else – if said field does NOT equal the defined values, then test’s value is the argument
In this case, if status equals 200, then the text would say, “Cool Beans.” If the value of status is anything other than 200, then the text reads, “No Bueno.”
As stated earlier, CASE will allow us to add more arguments…
|eval test = case(status==”2*”, “Cool Beans”, status==”5*”, “Yikes”, status==”4*”, “might be broken”)
As you can see, we can apply multiple conditions using the case to get a more robust list of descriptions. Pretty cool right? Let’s look at some other things that eval can do.
Lower/upper with eval
Sometimes, the text formatting in our data can be weird. Splunk says that when you search for a value it doesn’t need to be case-sensitive… but take that with a grain of salt. It’s also not true when comparing values from different sources. Check out this scenario…
Event Data – ID: 1234AbCD
Lookup – ID: 1234abcd
If I’m trying to use a lookup command and join and get values in a coherent table of information, that’s not going to happen. Why? Because the two values don’t match. Sure, the numbers and letters are the same, but the formatting is different. Splunk views that as a roadblock. Need a quick fix? Here’s one that’s super easy and barely an inconvenience.
|eval id = lower/upper(id)
And that’s it.
Lower and upper will allow you to format a field value to make all letters each lowercase or uppercase depending on which function you use. Now, all we’ll have to do is make the letters in our event data lower case and then the lookup and indexed data can communicate correctly.
That’s going to be it for Part 2 of the eval command, but we’re not done quite yet. Be sure to check out Part 3 coming next week!
Ask the Experts
Our Splunk Search Command Series is created by our Expertise on Demand (EOD) experts. Every day, our team of Splunk certified professionals works with customers through Splunk troubleshooting support, including Splunk search command best practice. If you’re interested in learning more about our EOD service or chat with our team of experts, fill out the form below!