Setting up 14all.cgi for use with MRTG and RRDTool
This page will walk you, step by step, through the process of switching from MRTG's graphing features to 14all.cgi. Remember that there are some MAJOR differences between the way your old MRTG displayed everything (html pages, graphs, etc) and the way 14all does it. That was the biggest mental "hump" I had to get over. The fact that once you switch from rateup to RRDTool, MRTG no longer does the following:
- Creates the graphs
- Creates the html pages to view said graphs
So, there are three areas that will factor in to why you want to switch to RRDTool to gain some serious performance advantages.
- Every time MRTG collects the data and stores it in your .rrd, that's all it does. No graphing, no redrawing html pages.
- RRDTool is now doing data storage, not MRTG. MRTG stored the data in two places (.log and .old), but RRDTool only stores the data in a single file (.rrd).
- The biggest benefit comes from RRDTool just normalizing the data and modifying the changed entries, whereas Rateup has to read in the entire .log, write that file (or copy it before reading it in, I'm not sure), create a tmp file for the data, do it's consolidation, and then write that file back out to disk.
Also, your server benefits by getting back a WHOLE bunch of disk space, because there is only one file (not 7) associated with each target. The one file is the actual rrd. The 7 files are:
- target.log
- target.old
- target.html
- target-day.(gif,png)
- target-week.(gif,png)
- target-month.(gif,png)
- target-year.(gif,png)
I don't want to lead you into believing that the graphs won't exist anywhere anymore, but as long as nobody needs to see said graphs, they won't exist. When a graph is requested, your graphing front end (14all in this case) will create the graph and put it in your web server's temp directory.
Once you realize that your newly converted MRTG/RRDTool does not do anything with graphing, you'll start to go into a state of panic, similar to what happened to me. Then you'll wonder why you're putting yourself through all this grief just to help your server out. Then the realization that you'll need to convert once MRTG-3 (currently we're all using MRTG-2, with incremental enhancements) comes out, you'll need to learn about how RRDTool does it's graphing functionality anyway, so you might as well get it over with and switch now, so you'll be ready for MRTG-3.
MRTG/Rateup produces graphs. RRDTool produces graphs. Running MRTG with RRDTool as your backend (logformat: rrdtool) will NOT produce the same results as running MRTG with Rateup as your backend. You need a graphing front end to tell RRDTool what kind of graphs to produce!
Armed with nothing more than your server and your mind, you are ready to go out and conquer the rateup beast, killing it to let the more elegant, more sophisticated RRDTool take it's place on the pedestal of data collection magic. Then you can use any front end you want. Right now, I primarily use MRTG for data collection and 14all for calling RRDTool's graphing functionality. It basically makes RRDTool "look" like your old friend MRTG. There are other scripts that can do the job as well. You can read more about them on the RRDTool Integration page.
There are a number of assumptions.
- You have MRTG installed
- It is working correctly
- You have RRDTool installed
- It is working correctly with MRTG
- You need to now view your data similar to the way you did before switching to RRDTool
On to the setup. The follwing describes the steps that need to be taken to ensure a successful changeover to 14all.
- Download 14all.cgi
- Put it in your web server's cgi directory
- As it says in the beginnig of the 14all.cgi script, make sure "RRDs" is in the module search path. Mine looks like this:
use lib qw(/usr/local/mrtg-2/lib/mrtg2);
I know it says to include the RRDs.pm from rrdtool, but my installation worked with the mrtg2 libraries set in this area. I tried it with pointing the use lib over to RRDTool's lib, but it didn't work right for some reason. Maybe someday I'll go back and figure out why, but for now I've got enough work to do without adding more to my plate.
- To make calling 14all.cgi more flexible for me, I leave the cfgfile blank, and call it from the hyperlink. The format to do this is:
http://path/to/cgi-bin/14all.cgi?cfg=your config file name (with the extension)&option1&option2etc
The options are (as far as I've figured out):
- cfg - the config file you would like to create graphs for. Be careful on this one. If you have a lot of targets in your config file, you will be waiting a very long time for all the graphs to finish drawing. I solve this by adding the next option to the hyperlink and that is solved quite easily.
- log - the specific target you are looking to graph
- png - the period you are looking to graph. This could be (14all defaults)
- daily - 2,000 minutes, with a resolution of 300 seconds (1 day, 10 hours 20 minutes long in 5 minute samples)
- weekly - 12,000 minutes, with a resolution of 1,800 seconds (8 days, 8 hours long in 30 minute samples)
- monthly - 800 hours, with a resolution of 7,200 seconds (33 days, 8 hours, in 2 hour samples)
- yearly - 400 days, with a resolution of 86,400 seconds (400 days in 1 day samples)
- daily.s - 1,250 minutes, with a resolution of 300 seconds (20 hours, 50 minutes in 5 minute samples)
You don't need to put anything in the hyperlink other than the cfg file. If you choose to put the cfg file in 14all, I would suggest copying 14all.cgi to a name that matches what config file is in the $cfgfile parameter. Naming it something like corerouters.cgi or something like that would make sense if the config file is corerouters.cfg. I think Rainer suggests this in his HowTo as well.
- In my situation, I like to keep the config files in a separate location from the cgi, so I changed my $cfgfiledir parameter to be:
$cfgfiledir = '/usr/local/rrd';
This is where I keep all my config files for my installation. This is the location that MRTG knows about for calling the configs so it knows what targets to request data from. Your configs are most likely someplace different.
- Now, go to your browser and type:
http://path/to/cgi-bin/14all.cgi?cfg=(your config file).cfg
If you don't every single target in the config showing up (it will take a long time if it is a big config file), put something like:
http://path/to/cgi-bin/14all.cgi?cfg=(your config file).cfg&log=(some target in the config)
and you'll get an html page that looks almost like your old, comfortable MRTG prior to the conversion to RRDTool. Only it's not - it's the new and improved, MRTG on steroids. If you only have one config file, and you have put that in the $cfgfile variable in the script, you can skip the cfg parameter and jump right to the log stuff.
- That's it! You should be able to graph anything in any config file armed with this new information. If you have any questions about: