I'm trying out the new HTTP Event Collector, but I'm having problems searching the data.
Basically, the raw data looks like this:
And there are several similar events for Huey, Dewey and Louie. In the search, Splunk correctly identifies the varous
and task.description fields. Nice!
task.code is always a number. However, my problems are that I want to use
eval to concatenate
task.code, but in that context,
task.code does not seem to have any value.
... task.description="HTTPSplunking*" |eval usertask=user + ":" +tostring(task.code)
usertask having the values
"Huey:Null", "Dewey:Null", "Louie:Null". If I omit
usertask does not get any value at all. Same thing if I use
So I tried
task_code_null is always
stats is able to calculate
sum(task.code) so it does not seem completely null.
Does anyone else have this problem? Bug or feature?
As far as I know, the
eval actually means "concatenate", which is causing problems when you have a field like
For example, I have this search:
index=stash2 sourcetype=commits | head 100 | eval changes.foo=10 | eval usertask=username. ":" .changes.foo
and it won't work, as there is no field called
changes and no field called
foo. However, if I change it to this:
index=stash2 sourcetype=commits | head 100 | eval changes.foo=10 | rename changes.foo AS changes_foo | eval usertask=username. ":" .changes_foo
then it works just fine, as now it doesn't need to disambiguate the
.. I hoped that the
tostring() you had would solve this, but it doesn't seem like it. In short, I'd just do an inline rename of your field.
rename works well! Thanks!
Funny, I thought that
+ was the only concatenation operator. Ironic, since I have a Perl background and
. comes natural to me. I wonder if this is going to change, because I fear this behaviour will surprise many users.