|
This is due to a race condition with MRTG/RRD.
Data is collected by MRTG and logged by RRDTool against the 5-min window in which it appears. However, if you subsequently generate a graph while in the next window, you can get this.
EG, collect data at 12:04 and log it. It goes against the 12:00-12:05 window.
Then, generate a graph at 12:06. This is in the next window, so the last same is displayed as 0 (unknown).
routers2 does some tricks to try and get around this, but it is harder to avoid on userdefined graphs.
What you can do to avoid it is one of these.
1. Make sure you data collection runs at the beginning of the 5-min window (hard)
2. Set the uselastupdate=yes option in the routers2.conf. This works, but if a device is down then you end up with a graph based on the last actual data retrieval (probably OK). This is what we do here.
3. Live with it (probably not what you want else you'd not have posted here)
4. Set the 'unknasprev' option in the routers.cgi*Options[]. This makes the graphs behave as per native MRTG, IE, with unknown data being displayed as the last known value. This may result in misleading graphs, though, if the device is ever unavailable.
I'd suggest using the uselastupdate=yes option, as this alters the base time on the displayed graph to being the last update time of the RRD, rather than 'now'. Therefore, even if the time is 12:06 (and you're in the next timewindow) then the graph will be based at 12:05 (the end of the last updated window).
_________________ Steve Shipway UNIX Systems, ITSS, University of Auckland, NZ Woe unto them that rise up early in the morning... -- Isaiah 5:11
|