|
Ive seen this a few times. It is caused by one of three things -
1. Race condition with data collection combined with unknaszero option.
If you have unknaszero set, then it ispossible that you are viewing the data before it is collected, so the latest data is 'unknown' which is then interpreted as zero. This is because RRD has 5-min windows on the 5-min boundary. If data collection happens at 4min50sec then for the first 4min50sec of the window it is unknown. This also explains why rescaling can fix the problem - you are generating the graph at a different time, hence may be after the data collection but still in same 5-min window.
Fix: remove unknaszero option. routers2 has a workaround for this and seeks back to previous sample if an unknown is found.
2. Race condition with data collection combined with data loss.
routers2 tries to fix this, but will only backtrack one sample (so as to avoid inaccurate calculations). If you have a missing sample, then you end up with zeroes. You can spot this because you will have occasional grey vertical lines in the graph where the data is missing (provided you dont have unknaszero set, see (1))
Fix: difficult. Check rrd has missing data, and fix reason for patchy data retrieval.
3. Userdefined graph over rrds with different data retrieval times, race condition with generation.
If a userdefined is over two rrd files, where one is collected at t+30s and one at t+4min (where t is the rrd sample time boundary), then between these two times you will get zeroes since the backtrack is not used (because *some* valid data exists in this time window). After t+4m then both have valid data, so it works. Before t+30s there is no valid data, so routers2 will automatically try to backtrack one sample window, and it is likely to work (but see (2)).
Another option for fixing is to set the 'uselastupdate' option in the routers2.conf. This will make graphs end at the last data collection time, rather than the current time. For most graphs, these are the same, or only different by 5min (in the case of a race condition). However, for a down device, it will mean the graph freezes until data is collected again, rather than moving on with a grey band.
In summary, you should first of all remove the unknaszero option (if you have it set). This may fix it. If it doesn't, then check that your data collection is at the top of the 5-min boundary (ie, at 12:00, 12:05, etc and not at 12:04, 12:08 ... ). Set the uselastupdate option in the routers2.conf (if you can put up with the downside of doing this). The root cause is tied up with the way RRDTool generates graphs and cannot be simply worked around.
_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11
|
Login
Register
FAQ
Members
