At the beginning I thought that maybe there is a problem with the way the rrd files are created. After some time Iunderstood that the issue resides in the rrd update process. The "problem" is that the rrd files are updated using thetimestamp of when the data was gathered. So, at this moment, if you compare mysql data with data stored in rrd, you have different timestamp and different values. So, as an workaround and a compromise i think a good idea would be to update the rrd file using the next rounded fixed interval. Just to explain a little bit more, instead of updating the rrd file using the timestamp 1310967997 we can update the rrd file using the timestamp 1310968200 (which is the next fixed multiplier of step); And now, you have different timestamps and same values as in mysql and the graphs are useful again.

History

If you look closer you'll find rrd timestamps are correct (in term of interval I mean, every 300 sec so 5 mins). And they are on a 5 mins basis (14h00, 14h05, etc.)

Thoose in Mysql are the real check end timestamps and so not correlated to times.

That's the way rrdtool works, it does a consolidation of values in an average manner, so when you update the rrd DB it does an average to covers the nearest next period (and if too close of last period update it).

I don't really see a correct manner to do this as the rounding is done by rrdtool at the moment of writing, having correct timestamps in mysql could do the trick maybe, but it involves knowing the check interval to create the correct timestamp and as far as I know rrd won't accept a future timestamp, so it involves centstorage process to keep trace before writing.

Actually this is not done because it is not necessary to insert values into rrd, the rrd library does the trick and sometimes give values not so accurate but near reallity.

Last point: Doing a check every 5 mins for a current counter involves missing some high or low values occuring in this period, everything between the two checks is unknow and won't even be known, that's why rrd work with average consolidation and never with accurate values.

First, thanks for taking the time to look at this. I didn't stated at any time that the rrd timestamps are not correct. I also know that timestamps frommysql are the real check end timestamps and i also know that when updating the rrd with real check endtimestamps rrd will do a consolidation of data in an average manner and will display data at fixed intervals. By the way, it is possible to update an rrd file with future timestamps. RRDTool only makes sure that the timestamp for the new value is higher than the last update time. (Please see my example below where I was able to update an rrd file with future timestamps). Regarding your last point, indeed, doing a check every 5 minutes for monitoring a current counter is not the best practice because you can have a lot of spikes between these 2 periods, but doing this at smaller interval (30 sec.) gives you the chance to have a better overview of the trending. For example, if you want to monitor the used B channels from a T1/E1 doing checks at 30 sec. can give you some idea of the load (/periods of the day) because a call is lasting in average more than 30 sec. And, I can give you examples like this one where it is useful to monitor integer values.

RRD minimum update time is 60 secs (that's why centreon use *60 in configuration) and that doing something more often would create a big network and server overhead on the monitoring target.

The main point I was talking about is : you must know the check interval to calculate the next correct rrd time. This is not trivial and add an overhead as actually this is not needed to update an rrd DB. (see man rrdudapte)