Converting from Rateup to RRDTool




This page will walk you, step by step, through the process of switching from Rateup to RRDTool for MRTG's backend. When switching, please keep in mind that MRTG moves from being the whole ballgame to just a frontend data collector for RRDTool. There are many other front ends, and MRTG may not be what you want to use anymore. Also, I will say this now and many times through these pages, MRTG will no longer do anything with graphing. It is just used to grab the data and stuff it into RRDTool. There are other programs that will extract the data from RRDTool and put it into a nice graph, similar to what MRTG used to do. You can write your own scripts to do both of these jobs, and once you understand the whole RRDTool concept, you may just want to do that.

Tobi Oetiker has written a basic version of what exactly is needed to convert. It can be found on the mrtg site, under RRDTool Integration. My document describes from more of a user perspective, a kind of "Rateup to RRDTool for Dummies" kind of conversion.
There are a number of assumptions.


If you want to skip the teaser and go straight to the technical stuff, click here.
Here is a "teaser" for what is to come. These are png's created by 14all.cgi, extracted from RRDTool. I moved the data storage over from the .log format to the .rrd format for the mrtg box itself about 2 weeks prior to the actual conversion so I could get an idea of what to expect. What I discovered was way beyond what I thought would happen.


NIC load before/during conversion Old NIC load (6395 bytes)(fig. 1)
NIC load during/after conversion New NIC load (6901 bytes)(fig. 2)
CPU before/during conversion Old CPU load (4564 bytes)(fig. 3)
CPU load during/after conversion New CPU load (4505 bytes)(fig. 4)

Before I get into the technical parts of the conversion, let me describe the graphs above to explain what was happening.

Fig. 1
Network card inbound and outbound traffic as obtained via net-snmp, mostly prior to conversion of RRDTool. You can see from the graph that I started the conversion about 8:00 pm. There was about double the traffic that there had been prior to conversion. There reason for this is that I was doing BOTH Rateup and RRDTool at the same time, so twice the amount of requests were getting sent out (and being received) by the box.
Fig. 2
Network card inbound and outbound traffic as obtained via net-snmp, shortly following conversion to RRDTool. After conversion, I ran both for at least a day while I made sure everything was working ok. The brief increases in traffic are from the morning NOC employees coming to and checking things out on the network. They had no clue that I had even changed MRTG over from using rateup to RRDTool. Turned off the old collection method (rateup) about 10:00 am.
Fig. 3
CPU load as obtained via Alex van den Bogaerdt's script (here), mostly prior to conversion of RRDTool. At about 8:00 pm, I made a new entry in my cron, and the huge spike in cpu load is from MRTG doing the automatic conversion from the old .log/.old format, over to the shiny new .rrd format. As far as MRTG was concerned, it just converted the logs over, but it left them behind, just in case something didn't work out. The process that converted the logs over to rrds is just there, as you'll see I didn't do anything extra to convert them over.
Fig. 4
CPU load as obtained via Alex van den Bogaerdt's script (here), shortly following conversion to RRDTool. After a day of letting both rateup and RRDTool do collection, I verified that I was getting the same data, and turned off rateup for good at about 10:00 am. RIP rateup.


Technical steps for conversion.

Where to start? Well, I guess the best place to start is at the beginning.

  1. Copy your configuration file that has all the target you want to convert, naming it something similar, maybe with "rrd" at the beginning, like rrdconfig.cfg.
  2. Add the following statements to the top of the rrdconfig.cfg file: The softlink command is used to create a "virtual" connection between the actual location of your information and where you want it to be. For instance, I created the softlink for rrdtool to my actual version, specifically so that when I move to the next version of rrdtool, I only have to update the softlink, not every single place that I have the PathAdd and Lib add statements. Right now, that's about 30 different config files. That would be a real pita to have to change. When I executed the command, I was in the /usr/local/bin directory on my mrtg machine. The command syntax in my situation was:
    ln -s rrdtool-1.0.28 rrdtool
    This was all I needed to establish both directory softlinks in the example.
  3. Add the command to start mrtg with the new log capabilites. For my case, I added an additional cron entry to kick off mrtg using rrdtool. Keep in mind that I was also doing the old logging as well. Also, remember that there is no need to do an "explicit" conversion of your old .log files, MRTG will know that it needs to convert your old log files to the new .rrd format.
  4. Wait at least 30 minutes (to allow for complete conversion) and then use your favorite front end to view the results! I use 14all.cgi. You can find my steps for using it here.
  5. Once you are satisfied that all is well, remove the old mrtg call to collect the data. Also, don't forget to remove all html and graphs from the directory, and I would recommend moving the .log and .old files to another location of the machine, just so you have an archived version of the data from before you converted. This way, you at least have a backup from when you converted.

Hosting by WebRing.
Navigation by WebRing.