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

[wilsonds]

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

[martin_mueller · Accepted solution]

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]

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

[wilsonds]

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

[richgalloway]

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

Please provide some sample (sanitized) events.