Very cool, Gary. Awesome to the max!
Thank you very much for sharing your experience and a fix!
Just for the record - when using this double check the rrdtool dir and the user:group permissions - not everyone uses those same settings!
Again, thanks a lot!
On 12/5/07, Gary Baluha <gumby3203 at gmail.com> wrote:
I wrote a script to clean up these bogus values. Of course, if there are trend graphs where numbers large enough for NNNe+1NN to be valid, the script will have unexpected results. To run the script, you need to "cd" into the directory with the rrd files to be fixed.
On Dec 5, 2007 2:05 PM, Gary Baluha <gumby3203 at gmail.com> wrote:
cd hobbit_data_dir/host_machine rrdtool dump clock.rrd > clock.xml
I know any number that shows up greater than "e+1nn" is bogus, so I search for "e+1".
One of several bogus data lines: <!-- 2007-11-26 19:00:00 EST / 1196121600 --> <row><v> 3.9551632477e+169</v></row>
Same line, changed to NaN (repeat for all affected lines): <!-- 2007-11-26 19:00:00 EST / 1196121600 --> <row><v> NaN </v></row>
rrdtool restore clock.xml clock.rrd
On Dec 5, 2007 11:57 AM, Kern, Thomas <Thomas.Kern at hq.doe.gov > wrote:
Could you give a short example of a bogus and a changed (NaN) entry, just in case that is also happening to some of my data files?
/Thomas Kern /301-903-2211 (O) /301-905-6427 (M)
*From:* Gary Baluha [mailto:gumby3203 at gmail.com] *Sent:* Wednesday, December 05, 2007 11:53 AM *To:* hobbit at hswn.dk *Subject:* Re: [hobbit] strange graph behavior - random machines & graphs
I am now completely convinced that the strange behavior of the graphs is due to some bad data getting inserted into the .rrd database files. The bad data is always the same value: 5.1776682516e+170. That's what the value looks like when you do an rrddump on the .rrd database file.
I still have no idea where this value is coming from, but I have at least determined how to fix these graphs. I'm working on a script to do this, but for now, I manually do an rrddump of the file, change all bogus values to NaN (basically, searching for "e+1", since none of the values I trend generally get that large, so I know these entries are just averaged values of correct data and the 5.17... number), and then do an rrdrestore from the modified xml file.
It would be nice to determine where this problem is coming from, though.
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
Those who don't understand UNIX are condemned to reinvent it, poorly. --- Henry Spencer