On Wed, 2007-05-16 at 11:46 -0500, Matthew Chambers wrote: > I initially set up gmetad.conf with my data sources using default > intervals (15sec). I then decided I wanted 10sec intervals so I > changed the conf and restarted the service. I soon discovered that my > hour graphs looked like bar graphs.
Since I don't know what you gmetad.conf file looked like, I'll venture to guess what changes you made. Then you can tell me if I am right. My guess is that you modified the "data_source" line to look something like this: data_source 10 "cluster_name" <host1> <host2>... That way your gmetad would poll the gmond every 10 seconds. However, you didn't specify a new "RRAs" line in gmetad.conf. Is that correct? > After much gnashing of teeth (and learning about rrdtool, and help > from #rrdtool), I discovered that the default RRAs that were initially > created by gmetad were dependent on the 15sec interval (actually, >= > 15 sec). In other words, the RRA for the hourly data was not big > enough to store 10 second intervals because it was created for 15 > second intervals; as a consequence, the next largest RRA was used, the > daily RRA which had ~24 times lower resolution! If my previous statements were correct, your gmetad used the "10" from the data_source line to create rrd files with 10 sec step sizes. But the RRA definition was still the default "RRA:AVERAGE:0.5:1:240"... This meant that the rrd files had 240 data points at 10 sec intervals, which only spans 2400 secs = 40 mins. When you tried to graph an hour interval, rrdtool pulled data from the hourly averages to generate the graph. Is that assessment correct? If so, then it should just be a matter of adding a new RRA definition when the data_source interval is changed. (If not, then just ignore the rest of this message.) The time period in the data_source lines controls two things: 1) The default step size for new rrd files 2) The interval at which gmetad polls gmond It is perfectly valid to poll at an interval that is less than the rrd step size. Gmetad can push data into a rrd file at any rate that it chooses. The rrd file contains a running average of the data, and uses this to create a "primary data point" every $step seconds. If the default 15 secs has been used to create the rrd files, but then the polling interval was changed to 10 secs, there shouldn't be any problems with rrd files that already exist. The problem would only occur for NEW rrd files which would then get created with a 10 sec step size. That kind of behavior is not really documented, and is certainly unintuitive. > It seems to me that when gmetad starts up, it should check the RRAs > and should either warn that the existing RRAs are too small or it > should resize the RRAs automatically. That kind of behavior is not realistic. Different people want to collect data at different intervals for different lengths of time. Some people may want the smallest timestep data to span 2 hours instead of 1 hour, or they could just as easily want it to span 30 minutes. Sure, gmetad could determine the step size from the data_source line, multiply it by the number of data points in the RRA definition, and find out what time span that covers. But it has no way of knowing whether that time span is "too short". Only the admin who configures gmetad can know that. The real problem with your case was that the web frontend didn't allow you to view graphs for time periods of less than an hour. A 30 minute graph would have allowed you to see the details in your data. But if you look back through the mailing list, you should see some mention of recent work to allow customizable graphs for the web frontend. I am not sure if it is in the latest Ganglia release, but that might be of interest to you. -- Rick Mohr Systems Developer Ohio Supercomputer Center ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
