Splunk Search

xyseries vs chart over by

Path Finder

Are there any differences between the following queries other than my observation (below):

  1. xyseries Foo Bar Value
  2. chart latest(Value) over Foo by Bar

I have noticed that chart last(Value) does not return (anymore?) non numeric results unless limit=0 is set? Which is weird and was a lucky find, but now I have an option, and I'm not sure how xyseries works over a timerange. For example I know latest(Value) pulls the most recent value for each key, even if they are not time aligned, so if I pick a large time scope (like 24 hours) I can interpolate into one row. xyseries does not seem to work exactly like this, but then again based on its behavior I cant figure out what its doing at all!

Any help is appreciated,

Tags (3)
1 Solution

SplunkTrust
SplunkTrust

the basic purpose of xyseries is to turn a "stats-style" search result into a "chart-style" search result.

You may have noticed that whereas stats count by foo and chart count by foo are exactly the same, stats count by foo bar, and chart count by foo bar are quite different.

In fact chart has an alternate syntax to make this less confusing - chart count over foo by bar. Basically the over field in a chart command becomes the field whose distinct values define each row. And the by field becomes the field whose values are sprayed out across the columns.

Stats on the other hand, never puts field values in columns at all. Instead stats count by foo bar as well as stats count by foo bar baz cux cuux fishies will just keep on making rows that represent the unique combinations of the N fields.

It turns out that the stats format is more powerful and flexible, in that it allows you a wider range of trickery to massage data using eval and other commands, whereas as soon as chart sprays things out across columns, they become harder to work with. So say you have to do a little "work" with eval, but you ultimately want to display it as a chart. This is where xyseries comes in - it can effectively turn stats count by foo bar into the same format that you would have gotten by chart count over foo by bar.

This seems really obscure and strange, but it's actually extremely useful - quite often you need to tweak the unique combinations of 2 fields a little bit before turning them into a chart-style output to be graphed.

To finish on a practical note - I would be very careful about piping raw events into xyseries. It's not really designed for it so it might somehow be truncating or discarding things, and you might as well use the relevant stats query right before that untable, because since stats has been very highly optimized and xyseries has not, it may well make your search more efficient.

View solution in original post

SplunkTrust
SplunkTrust

the basic purpose of xyseries is to turn a "stats-style" search result into a "chart-style" search result.

You may have noticed that whereas stats count by foo and chart count by foo are exactly the same, stats count by foo bar, and chart count by foo bar are quite different.

In fact chart has an alternate syntax to make this less confusing - chart count over foo by bar. Basically the over field in a chart command becomes the field whose distinct values define each row. And the by field becomes the field whose values are sprayed out across the columns.

Stats on the other hand, never puts field values in columns at all. Instead stats count by foo bar as well as stats count by foo bar baz cux cuux fishies will just keep on making rows that represent the unique combinations of the N fields.

It turns out that the stats format is more powerful and flexible, in that it allows you a wider range of trickery to massage data using eval and other commands, whereas as soon as chart sprays things out across columns, they become harder to work with. So say you have to do a little "work" with eval, but you ultimately want to display it as a chart. This is where xyseries comes in - it can effectively turn stats count by foo bar into the same format that you would have gotten by chart count over foo by bar.

This seems really obscure and strange, but it's actually extremely useful - quite often you need to tweak the unique combinations of 2 fields a little bit before turning them into a chart-style output to be graphed.

To finish on a practical note - I would be very careful about piping raw events into xyseries. It's not really designed for it so it might somehow be truncating or discarding things, and you might as well use the relevant stats query right before that untable, because since stats has been very highly optimized and xyseries has not, it may well make your search more efficient.

View solution in original post

Path Finder

thanks Nick, went with: stats latest(value) as Value by Foo Bar|xyseries Foo Bar Value

Its way faster! Plus I dont need to worry about the pesky limits, and it returns both string and numerics. Thanks again!

0 Karma