Plot metrics in the future

Asked by Kieran Girvan


I am currently running Graphite 0.9.9 and utilising the new timeShift functionality.

I have been asked to configure a graph to show the current day (00:00-23:59) containing a metric for the today and the previous week. I've been able to achieve this by commented out 1 statement within the file:

Line 660 > #if untilTime > now:
Line 661 > # untilTime = now

This allows be to select a %from attribute of 00:00, &until attribute of 23:59 which will display the current days metric (so far) and the previous weeks metric for the entire day.

Is there any reason why the untilTime is overwritten with ‘now’ whenever untilTime is in the future or was this simply designed before the timeShift functionality.

Many thanks,

Question information

English Edit question
Graphite Edit question
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Dieter P (dieter-plaetinck) said :

I did some work on this code recently ( and noticed that some of the "magic" adjustments of from/until times seem a bit inconsistent. I don't think there is a single "philosophy" that explains all cases, I had the impression most of these adjustments were added at one point without thinking too much about it.

My opinion on this is: whisper should only error if from > until. in all other cases (an until date in the future, even a from date in the future) whisper should IMHO just return whatever the user asked for. it's the caller's responsability to use sensible/correct from/until dates.

magically altering from/until dates:
* makes things less clear (if you're debugging a web interface and you see a request with a certain from/until date, you should be able to know that's what whisper will return you, without diving in the whisper code to find out all the special conditions)
* makes things less flexible (if you try to prevent users from doing dumb things, you also prevent them from doing clever things), as this example shows
* introduces uncertainty . different callers might have different expectations and assumptions.

Revision history for this message
Dieter P (dieter-plaetinck) said :

in addition to what I already said, I can also imagine use cases where a user might want to store datapoints for future dates, on purpose. for example output of cpu intensive future predictions, or deadlines or numeric tresholds that will need to be met

Revision history for this message
Michael Leinartas (mleinartas) said :

While there's a case for storing future data, I dont think there'd be a way to make this sanely work with whisper as it's designed. Since these files are fixed size and written with rolling-over offsets, writing to the future will overwrite data in the past. Ex: you have a whisper file with 30 day retention - if you write data 1 day in the future, you'll overwrite the data from 30 days ago. It's more confusing if you have multiple retentions: Say you have a whisper file with a 1 week and then 1month archive. If you write a point 1 day in the future, you're overwriting data from 7 days ago *and* from 30 days ago. While each of these archives will still be consistent when fetched (fetches only ever return data from a single archive - they dont get combined) this is quite unintuitive in my mind.

I do agree that the manipulation of from/until times as is can be quite confusing from a user perspective. I think though that any change to the existing behavior (and this would include the future case outlined in the original question) can be handled by the webapp. Currently the webapp requests the datestamp the user provides (via from= and until= parameters) but then renders only based on the time range of data it returns. It can instead use the requested datestamps for the graph width and render the requested data within that.

Revision history for this message
Michael Leinartas (mleinartas) said :

To answer the original question, there's a patch that was recently merged to the 0.9.x branch that will do what you need with timeshift:

If you want to stick with your 0.9.9 install it appears to apply cleanly except for the docstring:

Revision history for this message
Dieter P (dieter-plaetinck) said :

to handle arbitrary datapoints in the future, maybe we could extend retention policies to include the future, so the user could configure how far in the future he can store datapoints, and at which interval. however, let's not start implementing something like this until people actually start asking for it and explaining their use cases/problems.

Revision history for this message
Dieter P (dieter-plaetinck) said :

oh and if, you want to store a datapoint in the future and it overwrites data from the past, that's a bug IMHO. whisper should either do as you say, or error.

Can you help with this problem?

Provide an answer of your own, or ask Kieran Girvan for more information if necessary.

To post a message you must log in.