Saner units

[bitprophet]

I think this may be a Graphite specific problem, but many times one will get a graph that spans, say, 375 M to 412 M, but instead of using actual M, the graph will use K, so you'll see e.g. 375238 K => 412133 K. Much harder to parse/read.

See why this happens in Graphite and if there is a way to "fix" it solely via URL API args or if it requires Graphite changes.

[bitprophet]

Relevant Graphite code:

• render/glyph.py:UnitSystems defines the magnitudes
  • in a unit-agnostic sense, i.e. not "bytes" or "bits" but simply "mega" (SI, multiples of 1000, what we normally think in, and the default) or "mebi" (binary, multiples of 1024). Specifically, it uses "M" or "Mi" style suffixes.
• render/glyph.py:format_units() takes in a value, a step, and a system ID and returns a two-tuple of value, prefix (though I think it should really be 'suffix'...?)
  • It looks like the "bug" is here, and on purpose -- if the step size is not larger than the matching magnitude, there's no transformation.
  • For example, free disk space for mnt on cache10 does not fluctuate much, so a 4-hour view of the graph has a very small yAxis value change ("Yspan") and thus a very small draw step. Thus, it's not given a unit at all, even though this means it looks ridiculous because the free space value is really 398 GB (so it displays as eg 398603255071)
  • I presume the point of this is so one can actually see a high granularity in data -- removing the step check would mean that the above graph shows up as "398 G" repeated 5 times along the Y-axis, with no way of seeing small changes.
• render/glyph.py:LineGraph.makeLabel() calls format_units to arrive at a final label string for a given value.
  • It mostly just determines exactly how to format the floats, i.e. how many decimal places, and separating the value from the suffix by a space.
  • This is what we currently use to format the min/max/mean numbers calculated for #14.

---

First obvious solution is to make the magnitude check an optional boolean kwarg in format_units, passed down from LineGraph.makeLabel as that's our interface to these mechanisms.

The second is to further extract things so we can have a "step-agnostic" version of the above chain -- then, at least for now, we could skip the graph prerender step entirely since all we care about is acting upon the raw data series (and don't care about the step.)

EDIT: Hm, maybe not; makeLabel uses ySpan to determine how many decimal points to use (so, maybe removing the step check from format_units could work, if we allow makeLabel to use more than 2-3 decimal places...) and that does require the graph to be drawn/calculated. Unless we're able to wrench that out too. May be more work than necessary, it's not like doing all the graph calculations appears THAT heavy until it's truly drawn.

[bitprophet]

Yea, making step check skippable is easy, but of course then we run into situations where the graph's yAxis is still going from e.g. 19000245 to 19001437, but the min/max/mean values are all "19 M".

Will probably leave it at that for now -- if we make the graphs themselves skip the step check, they'll be less useful and really silly looking, but at least making the min/max/mean a "sane" suffix means one can glance at them to get context for a graph that is showing very long numbers on its yAxis.