[rrd-users] Additional "Unknown"-Value

Alex van den Bogaerdt alex at vandenbogaerdt.nl
Wed Jun 10 12:48:37 CEST 2009


> For that time we have no data for the RRD, but we want to handle it like 
> "in
> dubio pro reo" ("in doubt for the accused"). In this case it would be nice
> if we could have the ability to set the mrbh such high that only very long
> timeperiods (longer than one day) will not be bridged.
> But if there will be a real problem while monitoring something 
> (performance
> data could not be determined for example due to timeout), it would be good
> to have the option to tell RRDtools that it was determined an
> unknown-status.
> This breakdown will be displayed in the graph as well without overwriting
> the breaks by aggregation or additional filling of the graph by using a
> small heartbeat.
>
> Otherwise it could be fatal, because we want to create service level
> agreements.
> Without this function the SLAs will have wrong results.
> Maybe this could also be very interesting for other monitoring tools.



I think I understand what you want to achieve.  If I may summarize:

* you want the ability to fill a relatively large amount of time with some 
known rate, meaning you want to be able to skip several updates and still 
provide a known rate
* you also want the ability to hardcode "U" into your data, to signal that 
you know you don't know. That U should stay visible.

An extreme case:
step size: 1 second
X-Files Factor: 0.0
amount of PDPs per CDP: 300
heartbeat 86400

As long as one update occurs within 86400 seconds (one day) you will get 288 
rows with known data. But if you insert an U, that entire bucket of 300 
steps will become unknown.

And if you have more than one RRA in your RRD, you can do the same. For 
instance:

other RRA:
X-Files Factor: 0,0
amount of PDPs per CDP: 86400

This will show one day per pixel column. Show an entire year of such data 
and you see instantly how well you're doing: visible data means days without 
any interuption.


Does this help?

cheers,
Alex



More information about the rrd-users mailing list