alerting expressions always start with the base unit irrespective of the requested unit

[Dieterbe]

let's say I want to alert on the amount of GB free of /var on my graphite machine.
I enter the query "unit=GB type=free graphite3 var"
because of #69 we hand the targets in their baseunit and the javascript renderer automatically uses the most fitting prefix.

• when I click on the graph and add a new alerting rule from there, the expression will be "servers.dfvimeographite3.diskspace._var_lib_carbon.byte_free" so I can't just enter val_warn 5 to mean 'warn me at 5GB', it would mean "warn me at 5 bytes"
• clicking on the button near the query itself, the expression for the alert will be "unit=GB type=free graphite3 var", but also in this case we will ask from graphite in the base unit and get an amount in bytes back.

[Dieterbe]

we have 2 options:

A add a 'scale' attribute to all targets before handing them off to the renderer, the alert processor etc.
the scale attribute means "you actually still have to multiply the target by this for the target to match the unit provided in the unit tag" (i.e. the unit requested by user). the renderer could pretty much ignore this because it will show prefixes on the Y-axis ( #69), but can address both cases above because for alerting we know we have to add a scale around the target

B we could also just undo #69 so we have the graphite target everywhere already scale adjusted to be in the given unit. there may be a way to tell flot/tswidget about this so that it does show the correct prefixes on the y-axis. or maybe, when the user requests unit=kB it's actually less confusing if we show 1k 1kB to represent one MB. (it actually does still seem confusing to me)

[Dieterbe]

also we have to take into account that some metrics out there already have unit=MB or unit=GB (that's how some monitoring agents report disk space). maybe we can do B and give "prefix hints" to tswidget. if tswidget sees that the data already has unit=MB it could divide all metrics by 10^6 and then do its thing.
But that would be unneeded calculations and also I think I want the actual data to be in the scale suggested by the unit tag so that there's never suprises when getting datapoints from flot (in popups etc)
looking at the code, it looks like I had to implement my own suffixFormatterSI and suffixFormatterBinary, so I could just adjust to take into account already existing prefixes.