Alex et al, > > Example 1: > > You are running MRTG using 32bit SNMP counters and you want > to switch > > to 64 SNMP counters. If you just change your configs you will get > > enormous spikes in each graph as the 64 bit counters will be much > > bigger than the 32 bit, but may still be valid data for the RRD. My > > solution is to run MRTG with 64 bit counters and have it create a > > brand new RRD. Then you can merge the old RRD data from 32 bit > > collections into the new RRD. > > Step 1: stop updating using the 32-bit counter > Step 2: insert NaN in the stream (rrdtool update ... N:U) > Step 3: start updating using the 64-bit counter
Good idea! I hadn't realised that explicitly setting U would reset the last value. I had assumed it was a null-op. That'll save some grunt work ... cheers! > > Example 2: > > Your collection server crashes and you are in a mad panic. > You start > > up collections on a separate server while you fix your > server. What > > do you do with the data collected on the backup server when your > > normal collection box is fixed...? > > Step 1: update both databases simultaneously (so that they're > in sync) Step 2: a: rrdtool dump database1.rrd > database1.xml > b: rrdtool dump database2.rrd > database2.xml > Step 3: copy interesting parts from both xml files into a > third Step 4: rrdtool restore newdatabase.xml newdatabase.rrd Um... this is exactly what the perl script I posted does. Note that for the standard MRTG RRD "interesting" means 8 different places with some non-trivial alignment issues. That's not something I want to do manually with even one RRD file let alone the other 17000 RRDs that are updated every 5min on our production server. I need a tool that can re-merge in the old data without disrupting live collections. > This is the most complex solution. Then again, how often are > you going to make this mistake? I still have to plan for what I will do if/when my collection server dies. What did happen that was almost as bad was when a sysadmin accidentally increased the system clock by a month on a Saturday I came in on a Monday and had flat-lines for a month on all my graphs. I would be interested to hear suggestions on the most effective way to tidy up from that. Cheers Alistair ----------------------------------------------------------------------- Registered Office: Marks and Spencer plc Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. The registered office of Marks and Spencer Financial Services PLC, Marks and Spencer Unit Trust Management Limited, Marks and Spencer Life Assurance Limited and Marks and Spencer Savings and Investments Limited is Kings Meadow, Chester, CH99 9FB. These firms are authorised and regulated by the Financial Services Authority. -- 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
