hello
I use 2 similar searc
In the first I timechart the results
| bin _time span=1h
| stats count as Pb by tutu _time
| search Pb > 1
| timechart span=1h dc(tutu)
and in the second I stats the results
| bin _time span=1h
| stats count as Pb by tutu _time
| search Pb > 1
What I dont understand is that the result of the timechart command (screen 1) for a specific hour (18h for example) is different (I just have one event) than the result of the stats command (screen 2) because I have 7 events
screen 1
screen 2
thanks
I understand (you might try xyseries sometimes instead of timechar though) but I'm talking about a completly different thing.
Let's take a very simple search.
| makeresults count=3600 | streamstats count | eval _time=count | bin _time span=1m | stats count by _time
You should get 60 rows of results, all of them with count=60
But if you add
| timechart count by _time span=1m
You will be counting the results of the summarized stats, not the original data. So it's obvous that you'll get 60 results of count=1.
That's what I'm talking about. And that's why your timechart command is doing wrong calculation. You should be doing other form of aggregation (most probably sum or avg) instead of count. With count you're only counting _rows of stats table_, not the actual original data.
You're doing two different things. In your second search (the one without the timechart), you're looking for count of some events during every hour in division among single tutu fields.
But if you add timechart dc(tutu) to this, you're only counting distict values of tutu field in the results of the stats which most probably is not what you want.
If you're piping results of stats count into a timechart, you usually want some form of sum, avg or values aggregation. You usually don't want the count aggregation again.
I understand but I need to use timechart in my search because I use different appendcols in this search
As you know, appendcols does not correlate the values in the rows, it just adds data rows in the order returned i.e. the first row returned will be added to the first row of the current set, this means the results can get out of line. So I use timechart in order to generate the "missing" time periods.
I understand (you might try xyseries sometimes instead of timechar though) but I'm talking about a completly different thing.
Let's take a very simple search.
| makeresults count=3600 | streamstats count | eval _time=count | bin _time span=1m | stats count by _time
You should get 60 rows of results, all of them with count=60
But if you add
| timechart count by _time span=1m
You will be counting the results of the summarized stats, not the original data. So it's obvous that you'll get 60 results of count=1.
That's what I'm talking about. And that's why your timechart command is doing wrong calculation. You should be doing other form of aggregation (most probably sum or avg) instead of count. With count you're only counting _rows of stats table_, not the actual original data.
Hi @jip31,
the difference is probably in the bin command: if you put the bin command before the stats in the first search you'll probably have the same results.
In your search you group by _time but you didin't grouped in bin so you have many different results and the condition >1 many times isn't true.
Ciao.
Giuseppe
hi
unfortunately, its not the bin because I put it also in the first search (i just have forgotten to add it in the first search)
i @jip31,
I suppose that PbPerf in the secondsearch is an error!
Anyway adding bin command in the first search your searches are equal, and the timechart isn't relevant.
Ciao.
Giuseppe
No Pb is not an error because I need to use this threshold
I just need to display the events in 2 different way thats why I use 2 search
And concerning timechart I need to use it because I use a lot of subsearch in this search
| appendcols
[ search index=toto
| bin _time span=1h
| stats count as Pb by tutu _time
| search Pb > 1
| timechart span=1h dc(tutu) ]
....