Configurable step value

[obfuscurity]

No description provided.

[obfuscurity]

Rather than needing to allow configuration of the step value we might be able to get by with applying a summarize(target, 10) to the query.

[whilp]

Cubism applies summarize() under the hood in some cases. Where else do you need this?

[obfuscurity]

To be determined. As you've seen in #7, storage schemas can bite users in the ass. I'd love to be intelligent about this and perhaps query Graphite/Carbon for whisper metadata, but the only thing /metrics/get-metadata supports right now is fetching the aggregationMethod.

A better solution might be to query a single datapoint to see how many were returned by Graphite and adjust size instead.

[whilp]

Yeah, I haven't had any good ideas about fixing this yet. Hrmph.

[flatiron32]

The metadata is part of the raw data. Raw data is two tuples separated by a pipe. This first is metadata and the second data. The metadata is name, timestamp of first value, timestamp of second value, and seconds between each value. Is more data needed to determine how to draw?

[obfuscurity]

Sorry I missed this earlier. Good idea. I'd be tempted to use format=raw for all of our data collection, but since we already use the Graphite context (and I'm too lazy to change it now), I'll probably just request it once as raw data to get the step before constructing the first cubism request.

[obfuscurity]

Cubism already uses format=raw to fetch data, so I'm not sure why they don't already adjust based on the step returned to them. Since we don't know what the range (from/until) will be when setting up the context (cubism determines it here) we'll either need to duplicate that logic in Dusk or monkeypatch(?) cubism.js to do what we want.

@whilp @flatiron32 Does this make sense to you guys?

[flatiron32]

Looking at cubism a bit closer, I think it is getting the step out here. Perhaps dusk does not need to pass a step at all.