bitprophet / fullerene

Graphite dashboarding
27 stars 2 forks source link

Multiple metric types per graph #13

Open bitprophet opened 13 years ago

bitprophet commented 13 years ago

I.e. something more than foo.{a,b,c}.biz.{baz,boz} where it's typically a bunch of, say, disk related things in one graph. Instead, the sort of thing I do when troubleshooting: I want memory usage and load and HTTP requests all in one graph so I don't have to scan between multiple images to see if stuff actually lines up or not.

This almost always requires juggling of the two Y-axis as well as scaling individual metrics so that between those two Y-axis, things all look good together instead of clobbering or being too small/large to be visible.

But see if there's any good low-hanging fruit here -- perhaps something that can pre-tickle Graphite to figure out how it would draw a given metric in the default parameters, even e.g. obtaining the raw data (ideally just max/min values, maybe mean too) and then use that to figure out the final arrangement.

bitprophet commented 13 years ago

Partly solved by a new addition, "raw" paths. Paths with a literal %s in them will have the hostname inserted and will skip expansion/exclusion/etc. This lets you skip around the modeling we try to do, and have something go straight through to the rendered with just hostnames added (the only thing previously in the way of literal passthrough.)

So, e.g.:

path: group(alias(%s.cpu.*.cpu.system.value, 'system'), alias(%s.cpu.*.cpu.user.value, 'user'))

will show up on render pages with %s replaced by the appropriate hostname.

Until Fullerene is capable of doing this sort of grouping on its own (e.g. a setting saying "take one of the wildcards and turn it into a group() expression), and for anything else it cannot do, this is a good workaround.