One of my users is having an issue with timechart ...
(host=aaa6* OR host=bbb24*) "[string to filter search]" (E=005 OR E=00D OR E=0Bb OR E=0Bz) | timechart span=12h count by E
The output of this search gives me a table with the following five field headers AND the _time field is correctly broken down into 12 hour increments
_time, 005, 00D, 0Bb, 0Bz
(host=aaa6* OR host=bbb24*) "[string to filter search]" (E=005 OR E=00D OR E=0Bb OR E=0Bz) | timechart count by E span=12h
This search gives me the following five field headers AND the _time field is broken down into 30 minute increments
_time, 0, 00D, 0Bb, 0Bz
The timechart documentation does not appear to suggest that the placement of 'span' is required directly after 'timechart', but it appears to be so.
Is this worth filing a bug?
Paul
The answer is that the span
argument has two completely different meanings in those two locations. I agree that timechart should give some messaging around this though. The docs also seem to be wrong here. Currently the docs list "span" as two different args, in the two different sections. But the description in both places describes only the more common usage.
http://docs.splunk.com/Documentation/Splunk/6.2.2/SearchReference/Timechart
Run these two searches and note the differences.
index=_internal | head 1000 | timechart span=10 count by kb
This is more normal, and timechart has interpreted our "10" to mean "10 seconds"
index=_internal | head 1000 | timechart count by kb span=10
You almost never see this but it's been a part of timechart since the beginning. This tells timechart to bucket the "kb" values on the fly into buckets of size "10". The key is that the "span" keyword follows a numerical split-by field.
Try it out.
UPDATE: actually I was misreading the docs. They don't seem to refer to the second type of "span" argument at all.
Also, the chart
command does this too, and you can do it separately for both fields. try this one.
index=_internal | head 1000 | chart count over kb span=10 by eps span=5
The answer is that the span
argument has two completely different meanings in those two locations. I agree that timechart should give some messaging around this though. The docs also seem to be wrong here. Currently the docs list "span" as two different args, in the two different sections. But the description in both places describes only the more common usage.
http://docs.splunk.com/Documentation/Splunk/6.2.2/SearchReference/Timechart
Run these two searches and note the differences.
index=_internal | head 1000 | timechart span=10 count by kb
This is more normal, and timechart has interpreted our "10" to mean "10 seconds"
index=_internal | head 1000 | timechart count by kb span=10
You almost never see this but it's been a part of timechart since the beginning. This tells timechart to bucket the "kb" values on the fly into buckets of size "10". The key is that the "span" keyword follows a numerical split-by field.
Try it out.
UPDATE: actually I was misreading the docs. They don't seem to refer to the second type of "span" argument at all.
Also, the chart
command does this too, and you can do it separately for both fields. try this one.
index=_internal | head 1000 | chart count over kb span=10 by eps span=5
Why on earth is it not documented? Some hidden feature? Not knowing I did the second sort of span and I was freaking out because the time span would not change! Thanks a lot for the explanation!
Hi pkeller
Note that in splunk web requests are executed in sequential manner
Then when you write the first request below , the attribut span=12h is considered before the action is executed
(host=aaa6* OR host=bbb24*) "[string to filter search]" (E=005 OR E=00D OR E=0Bb OR E=0Bz) | timechart span=12h count by E
while with this other request the action is executed before the attribut span=12h is considered
(host=aaa6* OR host=bbb24*) "[string to filter search]" (E=005 OR E=00D OR E=0Bb OR E=0Bz) | timechart count by E span=12h
I think that the first request is the best .I advise you to work with it.
Perfectly stated. Thank you very much.
Command arguments are not parsed sequentially. Instead the reason for the difference is that the span
argument has two different meanings in the two different places. See my answer here.
Thank you you.