A: I have been asked many times, why not RRD to store data? This is self-maintaining, fast, lots of tools available, great support. Some people have suspected my sanity when I mention using anything as complex and fickle as MySQL for the storage of Nagios data.
This FAQ answer lists some of those reasons. I am willing to accept if any of these are wrong, so this may be the start of a constructive discussion.
There Two kinds of needs for
PerfParse.
If you need to see what happened yesterday or few days ago, on a graph, and only a graph. There is a storage module that allows an export of data into a format friendly to gnuplot. This should fit most of your needs already.
If somebody implements a storage module for rrdtool, this should not be too hard to do, and it should also fit that need : fill the RRD database, and use your own tools to ask rrdtool to make the graph.
For any other kind of use, RRD Storage is inappropriate.
1. RRD Storage is not client server.
Using a DBMS (Database Management System, such as MySQL) allows the database, Nagios and CGI to all reside on different servers. Complete with security.
This also allows multiple Nagios servers to a single Database to multiple CGI front ends. Which some users have found useful.
2. RRD Storage is fixed length.
An RRD is a fixed length sample of data. This allows automatic auditing of records, they are deleted automatically. However it becomes hard to change the size of the sample. It is also impossible to store an unbound sample length. The DBMS offers a far more flexible solution, including unlimited sample length. You can store load data for the entire lifetime of a server if you so desire.
3. RRD Storage is fixed frequency.
Nagios is variable frequency. This is because of three factors:
(i) You may freely change the sample period at any time.
(ii) Nagios may miss one or more samples.
(iii) Nagios may delay the sampling of data due to load, by a noticeable error.
The first point probably being more important. Under RRD it becomes very hard to resample data when the frequency changes. Again, the DBMS solution is flexible enough to handle this. You can change the sample length as much as you like without effecting the stored data or it's presentation.
4. RRD Storage is inefficient for Nagios data.
RRD is inefficient, leading to large disk space. Nagios produces seven variables for each metric: Value, Critical Low, Critical High, Warn Low, Warn High, Max, Min. An RRD solution demands all these are stored for each sample.
PerfParse (when finished) will only store the peripheral data when it changes. This will end up with anything as much as four times as little disk space consumed. As many systems are speed limited to the speed of disk access, this may also lead to a faster solution than RRD.
5. RRD Storage cannot store Nagios data format.
A minor point rarely used, but the Warn and Critical are not single values. They are in fact either an inside or an outside range. Therefore describing an area and not a line. RRD cannot describe an area.
When
PerfParse is finished, this will draw areas for Warn and Critical.
6. RRD Storage cannot store raw data.
PerfParse stores the raw data output from Nagios for as long as the user wished to view it. The ability of the DBMS allows for fast access to massive amounts of saved data in a small time. RRD cannot store this data.
7. RRD Storage cannot link completely to a DBMS.
The DBMS does not just store values. It contained limitless information about the hosts, services and metrics. For instance, it can store a picture of each host. This is linked to the data in such a way that the change of one effects the other. Again, this referential integrity becomes very hard under RRD.
8. RRD cannot easily complete complex analysis.
A DBMS has huge ability to analyse numerical data. Either for reports or extraction of statistical data. This allows the developers of
PerfParse to generate very strong applications with ease and speed. Including custom reports for users. Again, this is very hard using RRD.
9. Central Database Theory.
Most companies these days have somewhere a large database. Usually heavily guarded and afforded the best and most expensive servers, backups, staff and IT revenue. The idea of PP is that it uses a part of this resource to store the state and history of all equipment handled by the company. (When PP is ported to all other platforms.) Therefore taking advantage of, and becoming part of the heart of a company. Again RRD cannot in my opinion claim this.
I hope this list helps some users understand my motives. You may please email me if you want to discuss this further.
Ben & Yves.
.
Wiki