Splunk Search

Which is the best approach to use with an eval+case+wildcard+chart by 2 fields?

wilsonds
New Member

I've read as many examples as I can and I still can't figure out how to get this to work. We are using 6.6.2.

I am trying to gather stats on endpoint calls grouped by endpoint and client. There may be 2 or 3 endpoint values (ul-operation) and there are 43 variations of client values (user_agent), but they all start with 2 common prefixes that I can use for grouping. However, each variation of case statement I try always falls to the third bucket. I can't see which approach to use and why each one fails.

1) eval+case+like

sourcetype="bimlocs" source=blue@bimlocs-p-ue1 "line.ul-log-data.http_request_headers.user-agent" IN ("okhttp*","Khufu*") "line.ul-log-data.http_response_code" != "4*" "line.ul-log-data.http_response_code" != "5*" | eval "user_agent"=case(like("line.ul-log-data.http_request_headers.user-agent","okhttp%"), "ANDROID", like("line.ul-log-data.http_request_headers.user-agent","Khufu%"), "IOS",1==1,"OTHER") | chart count by "line.ul-operation", "user_agent"

2) eval+case+match

sourcetype="bimlocs" source=blue@bimlocs-p-ue1 "line.ul-log-data.http_request_headers.user-agent" IN ("okhttp*","Khufu*") "line.ul-log-data.http_response_code" != "4*" "line.ul-log-data.http_response_code" != "5*" | eval "user_agent"=case(match("line.ul-log-data.http_request_headers.user-agent","^okhttp.*"), "ANDROID", match("line.ul-log-data.http_request_headers.user-agent","^Khufu.*"), "IOS",1==1,"OTHER") | chart count by "line.ul-operation", "user_agent"

3) eval+case+==

sourcetype="bimlocs" source=blue@bimlocs-p-ue1 "line.ul-log-data.http_request_headers.user-agent" IN ("okhttp*","Khufu*") "line.ul-log-data.http_response_code" != "4*" "line.ul-log-data.http_response_code" != "5*" | eval "user_agent"=case("line.ul-log-data.http_request_headers.user-agent"=="okhttp*", "ANDROID", "line.ul-log-data.http_request_headers.user-agent"=="Khufu*", "IOS",1==1,"OTHER") | chart count by "line.ul-operation", "user_agent"

I'm guessing the third case doesn't treat the * as a wildcard.

However, all the above combinations appear to work as long as they are not within eval/case.

Am I doing something wrong?

Thanks,
Dave

0 Karma
1 Solution

martin_mueller
SplunkTrust
SplunkTrust

When you write like-or-match-here("f.o.o", "bar"), you're applying the like-string or regex "bar" to the string "f.o.o". You're not applying it to the field f.o.o. To refer to complex-named fields, e.g. fields containing operators such as dot or minus signs, use single quotes:

like('line.ul-log-data.http_request_headers.user-agent',"okhttp%")
match('line.ul-log-data.http_request_headers.user-agent',"^okhttp.*")

== looks for equality, it doesn't do wildcards so even if you applied single quotes to #3 you couldn't get that to work.

When you're in the search command, whether explicitly after a pipe or implicitly in the generating search before the first pipe, the syntax is less "program-y" and more "human-y" than where and eval. As a result, double quotes on the left hand side of an operator are okay to denote complex field names. This can be really confusing.

http://docs.splunk.com/Documentation/Splunk/7.2.0/SearchReference/eval#Required_arguments
http://docs.splunk.com/Documentation/Splunk/7.2.0/SearchReference/where#Required_arguments

View solution in original post

martin_mueller
SplunkTrust
SplunkTrust

When you write like-or-match-here("f.o.o", "bar"), you're applying the like-string or regex "bar" to the string "f.o.o". You're not applying it to the field f.o.o. To refer to complex-named fields, e.g. fields containing operators such as dot or minus signs, use single quotes:

like('line.ul-log-data.http_request_headers.user-agent',"okhttp%")
match('line.ul-log-data.http_request_headers.user-agent',"^okhttp.*")

== looks for equality, it doesn't do wildcards so even if you applied single quotes to #3 you couldn't get that to work.

When you're in the search command, whether explicitly after a pipe or implicitly in the generating search before the first pipe, the syntax is less "program-y" and more "human-y" than where and eval. As a result, double quotes on the left hand side of an operator are okay to denote complex field names. This can be really confusing.

http://docs.splunk.com/Documentation/Splunk/7.2.0/SearchReference/eval#Required_arguments
http://docs.splunk.com/Documentation/Splunk/7.2.0/SearchReference/where#Required_arguments

martin_mueller
SplunkTrust
SplunkTrust

I blame search syntax where you can leave off double quotes for strings, teaches people syntactic laziness 😛

0 Karma

wilsonds
New Member

Thanks! Something as simple as a quote which I don't think I saw when looking at various examples.

0 Karma

richgalloway
SplunkTrust
SplunkTrust

You're right. #3 doesn't support * like that. It's why we have like and match.

Please provide some sample (sanitized) events.

---
If this reply helps you, Karma would be appreciated.
0 Karma
Get Updates on the Splunk Community!

What's new in Splunk Cloud Platform 9.1.2312?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.1.2312! Analysts can ...

What’s New in Splunk Security Essentials 3.8.0?

Splunk Security Essentials (SSE) is an app that can amplify the power of your existing Splunk Cloud Platform, ...

Let’s Get You Certified – Vegas-Style at .conf24

Are you ready to level up your Splunk game? Then, let’s get you certified live at .conf24 – our annual user ...