Thanks for the reply.<br><br>As for normalizing the data, I had the suspicion that is what was going on, so thank you for clarifying it. I started to look at the link you posted and will go over it more in detail. It will help out. I can easily see how a CDP's result will be different then an actual outage doing it the way I have it setup.<br>
<br>I'll take a look at count. Seems to be a nicer way of doing this, but will take me some time to get it set up. <br>The ultimate goal in what I am doing is to show a graph of the response time, with our SLA times marked. With outages in and out of SLA times (which is what I have setup now). The next step will be to figure out the total SLA availability and total avilability of the service that I am monitoring. I was hoping to use the flags for this, realizing that it is not a true measure of uptime. Checking every 5 mins, can show a 10 min outage, even though it was only down for the moment it took to do the check.<br>
<br>Again, thanks for your time.<br><br>-mathew<br><br><div class="gmail_quote">On Fri, Mar 4, 2011 at 2:58 AM, Simon Hobson <span dir="ltr"><<a href="mailto:linux@thehobsons.co.uk">linux@thehobsons.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">mathew anderson wrote:<br>
<br>
>I have a single RRD file that has the value 100 in places. Whenever<br>
>my monitoring sees an error (probes every 5 mins), it pushes a 100<br>
>into an rrd file. I am trying to figure out how many times this<br>
>value is in a given time range.<br>
<br>
</div>Are you aware that except under certain very strict conditions, what<br>
is stored is NOT what you entered ?<br>
ALL input data is normalised, and then consolidated. If your data<br>
entry times don't exactly match step boundaries then it normalisation<br>
will alter it. Suppose your step time was 1 minute (60 seconds),<br>
you'd been entering zeros, then at 20s past the minute you enter 100,<br>
and 20s past the next minute you enter zero again, and continue<br>
entering zeros. The nomalisation means that for your one minute with<br>
a value of 100, 2/3 (ie 66.6) will go into one step period, and the<br>
rest (33.3) will go into the next. So you'd get out 0, 0, 66.6, 33.3,<br>
0, 0<br>
<br>
Then say you had a consolidation for 10 minute periods. The<br>
consolidated average for that would then be 10 (assuming both the<br>
non-zero normalised values fall into the same consolidated time<br>
period).<br>
<br>
See : <a href="http://www.vandenbogaerdt.nl/rrdtool/" target="_blank">http://www.vandenbogaerdt.nl/rrdtool/</a><br>
In particular the one on Rates, normalizing and consolidating<br>
<br>
Also, note that all time periods are referenced to unix epoch<br>
(midnight, 1st Jan 1970). So with a step time of 300, step periods<br>
start on the hour, 5 minutes past the hour, etc. If you consolidate 6<br>
PDPs to a CDP (ie 1/2 hour) then these consolidated periods will be<br>
on the hour and half hour.<br>
<br>
<br>
Given that you seem to be logging errors, it may be better to log the<br>
error count rather than a flag. If the errors are reported as a<br>
count, then use a counter data type and rrd will take care of<br>
converting that to a rate. You can then get rrd graph to do logic<br>
such as "if rate > some_threshold then draw it in red".<br>
<br>
--<br>
Simon Hobson<br>
<br>
Visit <a href="http://www.magpiesnestpublishing.co.uk/" target="_blank">http://www.magpiesnestpublishing.co.uk/</a> for books by acclaimed<br>
author Gladys Hobson. Novels - poetry - short stories - ideal as<br>
Christmas stocking fillers. Some available as e-books.<br>
<br>
_______________________________________________<br>
rrd-users mailing list<br>
<a href="mailto:rrd-users@lists.oetiker.ch">rrd-users@lists.oetiker.ch</a><br>
<a href="https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users" target="_blank">https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users</a><br>
</blockquote></div><br>