- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

I blame search
syntax where you can leave off double quotes for strings, teaches people syntactic laziness 😛
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks! Something as simple as a quote which I don't think I saw when looking at various examples.
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content


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.
