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!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

March 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...