The "step" value in the rrd database is slightly different from the "step" attribute when generating a graph. They are related, but have a different impact. In order to graph short time periods (I saw 10 seconds listed somewhere in the thread), you must first ensure that the RRD database is saving 10 second intervals and also that you display 10 second intervals. Just to clarify, when you run "rrdtool info" on the datase file, you DO see that the step value is set to 10? If this is the case, then you are all set to record the 10 second values in your rra(0) column.
You must also actually be collecting data every 10 seconds. This means your collector must be running every 10 seconds, and you must be actually getting values back every 10 seconds. Warning: I'll proceed with this message assuming that you can actually do this. In practice, I've only seen this work reliably when your collection service is running on a local machine, not over a network, and not when there are multiple systems involved. 1 minute snmp collection intervals are attainable in practice on a limited basis, dependent on your disk IO and network performance and collection system memory. The default Round-Robin Archive settings in Zenoss are based around 600 pixel graphs showing 5 minute averages over approximately 30 hours (hourly graph), 20 minute averages over approximately 10 days (daily), etc. The default size of rra[0].rows is 2016. (See example below)That means only 2016 values are recorded. At 10 seconds per value that means that you have only 20160 seconds (slightly over 5.5 hours) recorded. If your graph is displaying a time-frame greater than 5.5 hours, regardless of the graph step, it will fall back to whatever step value that provides enough values for the supplied time-frame. You either need to increase the number of values recorded to fit the default Zenoss time-frames, or modify the default graph display to show a smaller time-frame. For 48 hours worth of values, you would need 17280 ( (60 sec * 60 min *48 hours)/10 secs) values recorded in rra[0]. Which method you should use will depend on how you intend to use Zenoss overall for support. If you are looking for absolutely precise graphs, there are some other things to consider. As James Pulver alluded to earlier in the thread, RRD graphs will perform averaging of the values to match the size (600 pixels) of the graph. For brevity, reference my posts in this thread: http://forums.zenoss.com/viewtopic.php?t=8739. As an aside, given the hurdles and limitations presented by shortening the step value this much, I would encourage you to make sure that the value gained by tracking a near real-time 10 second interval is really worth the effort. The only valid reason I can see for this short a step is for true real-time monitoring. There are relatively few cases where network management systems actually require near real-time response. (normally those involve cases where millions of dollars can be lost in minutes, or human life is at stake.) A 1 minute interval would probably be more sane and achievable in most cases. The most common reasoning I see for shortening the collection time is to overcome a 32-bit counter that can flip within 5 minutes, leaving unpredictable results. The better solutions would be either use a 64-bit collection system, or change the scale of your recording (I.E, don't record how many octets are sent and received for 10 GB interfaces, instead record how many 1000s of octetes are sent and received.) A simple RPN statement in the RRD file would be more appropriate. |[zen...@server3 Devices]$ rrdtool info mplsa.domain.com/os/interfaces/Se0_0_1_0/ifInErrors_ifInErrors.rrd filename = "mplsa.domain.com/os/interfaces/Se0_0_1_0/ifInErrors_ifInErrors.rrd" rrd_version = "0003" step = 300 last_update = 1241538885 ds[ds0].type = "DERIVE" ds[ds0].minimal_heartbeat = 900 ds[ds0].min = 0.0000000000e+00 ds[ds0].max = NaN ds[ds0].last_ds = "534" ds[ds0].value = 0.0000000000e+00 ds[ds0].unknown_sec = 285 rra[0].cf = "AVERAGE" rra[0].rows = 2016 rra[0].pdp_per_row = 1 rra[0].xff = 5.0000000000e-01 rra[0].cdp_prep[0].value = NaN rra[0].cdp_prep[0].unknown_datapoints = 0 rra[1].cf = "AVERAGE" rra[1].rows = 2016 rra[1].pdp_per_row = 4 rra[1].xff = 5.0000000000e-01 rra[1].cdp_prep[0].value = NaN rra[1].cdp_prep[0].unknown_datapoints = 2 rra[2].cf = "AVERAGE" rra[2].rows = 1488 rra[2].pdp_per_row = 24 rra[2].xff = 5.0000000000e-01 rra[2].cdp_prep[0].value = NaN rra[2].cdp_prep[0].unknown_datapoints = 22 rra[3].cf = "AVERAGE" rra[3].rows = 730 rra[3].pdp_per_row = 288 rra[3].xff = 5.0000000000e-01 rra[3].cdp_prep[0].value = NaN rra[3].cdp_prep[0].unknown_datapoints = 190 rra[4].cf = "MAX" rra[4].rows = 2016 rra[4].pdp_per_row = 4 rra[4].xff = 5.0000000000e-01 rra[4].cdp_prep[0].value = NaN rra[4].cdp_prep[0].unknown_datapoints = 2 rra[5].cf = "MAX" rra[5].rows = 1488 rra[5].pdp_per_row = 24 rra[5].xff = 5.0000000000e-01 rra[5].cdp_prep[0].value = NaN rra[5].cdp_prep[0].unknown_datapoints = 22 rra[6].cf = "MAX" rra[6].rows = 730 rra[6].pdp_per_row = 288 rra[6].xff = 5.0000000000e-01 rra[6].cdp_prep[0].value = NaN rra[6].cdp_prep[0].unknown_datapoints = 190| || slickrick21 wrote: > ok I can see that the step of the graph is changed via rrdtool info but how > do I get this to be reflected in the actual graphs ? I still can only zoom > into what looks to be 5 minute intervals > > > mrchippy wrote: > >> Ok, the collector frequency for snmp collection does determine the rrd step >> size for those rrd files. Like James said below, you will need to delete >> the rrd files so they can be recreated with the right step size. These >> files are in $ZENHOME/perf/Devices/<devicename>. HOWEVER, make sure you >> stop zenperfsnmp first so that it doesn't get a chance to recreate the files >> before it picks up the correct frequency. >> >> 1) zenperfsnmp stop (or Settings->Daemons->stop zenperfsnmp) >> 2) Delete the rrd files >> 3) zenperfsnmp start >> 4) Once the files get recreated, go to one of the rrd files and run 'rrdtool >> info <filename>'. The step size should be toward the top. >> >> At this point the default step size on the graphs should be the rrd step >> size. >> >> chip >> >> >> slickrick21 wrote: >> >>> yes snmp data >>> >>> mrchippy wrote: >>> >>>> OK, that's slightly more complicated. The rrd file step size may come >>>> from different places depending on the daemon. Is it SNMP data that >>>> you're trying to changes the graphs for? >>>> >>>> chip >>>> >>>> >>>> >>>> >>>> slickrick21 wrote: >>>> >>>>> I am trying to get a smaller frequency I changed the monitoring frequency >>>>> but I did not see this reflected in my graph. >>>>> >>>>> >>>>> mrchippy wrote: >>>>> >>>>>> A couple of ideas: If you just want the graph to show larger steps than >>>>>> 5min, you just need to add '--step=<step size in sec>' on the custom >>>>>> graph command on the graph definition on the template. This change >>>>>> should show up immediately when you look at the graph after the change. >>>>>> This will NOT work for creating a smaller step. If you want to save >>>>>> finer data points, the rrd file and monitoring frequency will have to >>>>>> change. >>>>>> >>>>>> which are you attempting to do? >>>>>> >>>>>> chip >>>>>> >>>>>> >>>>>> slickrick21 wrote: >>>>>> >>>>>>> My new graphs are still coming back with the 5 minute step. where am I >>>>>>> supposed to be changing this ? >>>>>>> >>>>>>> >>>>>>> jmp242 wrote: >>>>>>> >>>>>>>> I think you have to delete the graph definition, and re-create it. I'm >>>>>>>> pretty sure you can't change the graph definition on existing RRD >>>>>>>> files >>>>>>>> (perhaps exporting and re-importing might work?? Read up on RRD ...)... >>>>>>>> -- >>>>>>>> James Pulver >>>>>>>> Information Technology Area Supervisor >>>>>>>> LEPP Computer Group >>>>>>>> Cornell University >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> slickrick21 wrote, On 5/6/2009 12:12 AM: >>>>>>>> >>>>>>>> >>>>>>>>> I looked in the custom graph definitions and attempted to ad >>>>>>>>> "--step=X" but this was not effective >>>>>>>>> >>>>>>>>> I simply want to increase the graph step. how do I do this ? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> zenoss-users mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.zenoss.org/mailman/listinfo/zenoss-users >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> zenoss-users mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.zenoss.org/mailman/listinfo/zenoss-users >>>>>>>> > > > > > > -------------------- m2f -------------------- > > Read this topic online here: > http://forums.zenoss.com/viewtopic.php?p=34368#34368 > > -------------------- m2f -------------------- > > > > _______________________________________________ > zenoss-users mailing list > [email protected] > http://lists.zenoss.org/mailman/listinfo/zenoss-users > _______________________________________________ zenoss-users mailing list [email protected] http://lists.zenoss.org/mailman/listinfo/zenoss-users
