Martin Knoblauch wrote:
On Monday 05 May 2003 19:31, Federico Sacerdoti wrote:
This is one of those hard-to-anticipate bugs which occur from
unintended side effects to the system. To fix it, I believe we need to
use the true localtime when updating rrds for which we are not the
"authority" on. (The authority mode is off whenever we get our data
from another gmetad).
Seems the time-keeping is a bit touchy :-)
To paraphrase Invader Zim:
"You guys are just BEGGING to face the gaps!"
Basically that's the trade-off. Either you trust RRDtool's timestamp,
or you pass along your own. And if you pass along your own, you have to
have a trustworthy way of determining it. If you trust RRDtool, you get
gaps in the graph if two updates occur to the same RRD in under a second
(causing the update function to error out immediately). If you place
your trust outside RRDtool, you get graph wackiness (gaps or flatlines)
if your time source is unreliable.
Personally I think it would be nice to rely on the stated cluster time,
but it makes more sense to me to generate the timestamp locally just
before updating the RRDs. gmetad can decide on its own by that time
whether it's necessary to update the RRDs or not, by comparing
timestamps. If the cluster is dead it shouldn't be updating anything.
And since the RRDs are being generated locally, it makes sense that they
should be stamped with the local time. The current architecture of
gmetad does not allow for any sort of historical query (the web
front-end is another story), so there's not much of a reason to respect
a foreign gmetad's timestamp.
Of course, that's just my opinion. I don't even use the grid features. :)
