Hi all,
i have some problems in understanding the way to get the "spikes/wraps" out of my graphs. i just read a lot in the mailing list and i finally came to the following result. The setup of my rrd database files looks actually like the following filename = "test_router.Serial0.rrd" rrd_version = "0001" step = 300 last_update = 980849175 ds[in].type = "COUNTER" ds[in].minimal_heartbeat = 740 ds[in].min = NaN ds[in].max = NaN ds[in].last_ds = "2467800446" ds[in].value = 3.2024009901e+04 ds[in].unknown_sec = 0 ds[out].type = "COUNTER" ds[out].minimal_heartbeat = 740 ds[out].min = NaN ds[out].max = NaN ds[out].last_ds = "1609629600" ds[out].value = 5.3415594059e+04 ds[out].unknown_sec = 0 1. I could set the "ds[in].min = 0" (as Tobi said). This should cause that a negative difference would reslut in a "nan" or "UNKNOWN" value. Did i understand this correctly ? As you wrote, this wouldn't prevent all kind of warps and spikes in the graphs. 2. If i change the ds[in].type from "COUNTER" to "Derive" then i should get rid off all problems (as discussed in the mail list), right ? The point that i can't understand is the change of the "ds[in].last_ds". Wouldn't this tell to the rrd that the last entry is the number you set to that value ? Could you explain to me how this should work and if i realy have to set "ds[in].last_ds" to a specific value to get all the warp and counter restet problems out of my stats ? >Original-Recipient: rfc822;[EMAIL PROTECTED] >Delivered-To: [EMAIL PROTECTED] >Date: Fri, 26 Jan 2001 21:54:03 -0500 (EST) >From: Christian Pearce <[EMAIL PROTECTED]> >To: [email protected] >Subject: [rrd-users] rrdtool resets (sorry) >X-archive-position: 1364 >Sender: [EMAIL PROTECTED] >X-original-sender: [EMAIL PROTECTED] > > > >I been doing a lot of reading through the rrd-users archives about counter >resets that cause rrdtool to artifically wrap. I don't like rehashing the >old, but it seems that this topic is an will always cause confusing as >long as we have counters and rrdtool. :-) > >1. Tobi mentions setting the MIN for the DS to 0. It is my understanding >when the delta is calculated after a COUNTER was reset it is negative. >Thereby renedering that interval "nan" or *UNKNOWN*. > >2. Check the data on the way in a set it to unknown. > >I have tried number one and it didn't work for me. > >[EMAIL PROTECTED] larrd]$ rrdtool info >/usr/local/bbvar/rrd/pearcec.fast.net.apache.rrd >filename = "/usr/local/bbvar/rrd/pearcec.fast.net.apache.rrd" >rrd_version = "0001" >step = 300 >last_update = 980563121 >ds[TA].type = "COUNTER" >ds[TA].minimal_heartbeat = 600 >ds[TA].min = 0.0000000000e+00 >ds[TA].max = NaN >ds[TA].last_ds = "998" > >I am not going to try and figure out one, but it seems like a good >solution. Although from my readings I have been led to believe the MIN >set to zero isn't a total fix. > >So I am just going to use : > >ds[TA].last_ds = "998" > >as for the last value to compare to my current value. Is this sane? > >And it at all possiable could someone tell me how I might cure number one? > >Christian Pearce >-PacketPusher > > >-- >Unsubscribe mailto:[EMAIL PROTECTED] >Help mailto:[EMAIL PROTECTED] >Archive http://www.ee.ethz.ch/~slist/rrd-users >WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi ------------------------------------------------------------------- Beginner thinks 1Kb == 1000 bytes. Master knows 1Km == 1024m -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-users WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
