Why is pretty straightforward. RRDtool will display the "most recent" hour based on the current time on your box, but the times that are put into the RRDtool database are absolute and derived from the original clock on the box collecting the data (IIRC). So your views were looking at an hour, but an hour from starting from some minutes ago.
RRDtool displays data based on the best resolution it has for the whole period being displayed. Since you don't have 15s detail past the sixty-something minute, it uses the 5m-wide data it stores for the day view by default. The RRA variables in your gmetad.conf drive exactly how long it retains data at specific resolutions. It's absolutely imperative to run some clock-synchronizer, at least between your aggregation nodes and your gmetad nodes, when working with Ganglia. I thiink it's possible to write a metric plugin that would detect drift once it got above a second or two, but I don't remember hearing about one. -- ReC On Wed, Apr 6, 2011 at 6:07 PM, Whit Blauvelt <w...@transpect.com> wrote: > To answer myself: This appears to be an artifact of clock drift (to the slow > side) in the VM. Somewhere I'd seen advice not to use ntp in a kvm vm. > Looking further I see other advice that it's okay. No idea which is right, > but resetting the clock with ntpdate and then running ntp to keep it set > results in the graphs reverting to normal appearance. > > Why is a question I can't answer. It would be curious, but I've no pressing > need to understand it now that it works. > > Whit > > On Wed, Apr 06, 2011 at 08:51:02PM -0400, Whit Blauvelt wrote: > >> We've been running 3.1.7 for some months to monitor a cluster of six >> servers, with no problem. We recently set up a second instance of gmeta >> running in parallel with the original one. For some days they were >> displaying just the same graphs. But today, I find the parallel instance >> graphing in at much longer intervals - six minute wide steps instead of the >> graphing at what I take to be the 15 second default intervals. We haven't >> had it set to anything beyond default for the cluster. >> >> Since the second instance is on a VM, which we're planning to use as our >> primary instance once we're satisfied with it, this is a puzzle I need to >> solve. On the scale of days, the graphs between the two instances look quite >> the same. It's just on the hour view that the 6-minute artifact is obvious. >> I've reset the polling interval in the problem instance to an explicit 15 >> seconds, but it's still graphing with straight lines across each 6-minute >> period. >> >> Any ideas what's causing this? > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > Ganglia-general mailing list > Ganglia-general@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ganglia-general > ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
