Metric ordering and wildcards

[tulanian]

The ordering of metrics in the legend when using wildcards and aliasByNode seems to be random in v1.9.0. Is this a bug or am I missing a setting somewhere?

[kipanshi]

+1, I was wondering why it's random, probably here someone needs to do a pull request to
do the ordering in Javascript.

[torkelo]

What backend (graphite or influx) are you using? The order is determined by the backend time series store. Graphite and Influx is for more returning ordered series.

[kipanshi]

I'm using Influxdb 0.8.6.

[torkelo]

Might be a bug in influxdb, strange. Gonna check what version I use

[kipanshi]

What I do is I have a query that fetches count(value) and groups by url,
and then I select "table", "values", "total", "max" checkboxes in the "Axes & Grid"
menu. The legend is a nice table with urls and respective counts,
but the ordering is kinda random,
and I want this table to be sorted by the "total" count, for example.

[tulanian]

The backend is graphite. Found it! I don't remember seeing sortByName, sortByMinima, etc. under Special> before. sortByName does the trick. When were they added? And what is the default?

[torkelo]

The default should be series name, not sure how graphite handles this.

[tulanian]

Something changed but I'm not sure when. I don't want to have to add sortByName to every metric with a wildcard. I have side-by-side graphs and each one has a different order for the same aliases: eagle1, eagle2, eagle3; eagle2, eagle1, eagle3; etc. This makes comparisons very difficult.

[torkelo]

That sounds very strange, I have always gotten the same order with aliasByNode (sorted in alpha numeric ascending order)

[tulanian]

[torkelo]

And this order is different some times? Not sure what causes this. Maybe a bug in graphite.

[tulanian]

Yup. And it does look like a bug in graphite. Will poke around there.

[jfischoff]

I'm also have this bug with graphite. Has there been any progress?

[cout]

I've noticed that with graphite 0.9.10, there is a well-defined order to the metrics that are returned (I think they are sorted lexicographically by name?). And if I want to enforce a specific ordering with the wildcards, I can explicitly list them, e.g. for cpu usage I can write cpu-{user,system,idle} to ensure that idle is always at the top.

However, when I query against latest graphite master, the metrics come back in a different order every time I query, so I have to add sortByName to any query involving wildcards. Additionally, the above trick to enforce a specific ordering no longer works. So this does appear to be a change in behavior in graphite, and may in fact be a bug.

What I typically want isn't a pure lexicographic ordering but rather a numeric ordering; e.g. if I have eagle1, eagle2, eagle3, ... eagle14, eagle15, then a pure lexicographic ordering would put eagle11..eagle15 between eagle1 and eagle2. This can be implemented as a custom function in graphite, though as pointed out above, this requires adding a call to that function to any queries which use wildcards. I almost wonder if the ordering should be controlled as a display style rather than relying on graphite to do the sorting.

[torkelo]

@cout you should report that to the graphite project

[zeph]

• http://graphite.readthedocs.io/en/latest/functions.html#graphite.render.functions.sortByName

with natural=True should do the job... but seems not work, I'm looking into it

FAIL... there is a mismatch between the graphite-web and the graphite-api project