Additional "Unknown"-Value

[n1LL3]

Hello,

I am working with a monitoring tool, which uses the rrdtools for creating
graphs.

When I am sending an update-command to the RRD with no data, for which I am
using the "U", what is mentioned in the documentation (If there is no data
for a certain data-source, the letter U (e.g., N:0.1:U:1) can be
specified.), in the RRD is a "NaN". When the RRD gets the next
update-command with data and the heartbeat-value has not reached, an average
rate will be calculated and added to this and to the previous data-source.

But for monitoring tools it would be nicer: If there is no data, the graph
should break.

This could be realised by adding a new value, for e.g. "unknown-status",
which I can edit with the update-command too. When this option is set, the
heartbeat will be ignored and the graph will break.
With this option, I can see the real breakdown of my monitoring.
Otherwise the RRD creates data, which does not really exist.

What would you say about this?

Thanks!
--
View this message in context: http://n2.nabble.com/Additional-%22Unknown%22-Value-tp3042052p3042052.html
Sent from the RRDtool Users Mailinglist mailing list archive at Nabble.com.

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Tobias Oetiker-3]

Hi n1LL3,

Today n1LL3 wrote:

>
> Hello,
>
> I am working with a monitoring tool, which uses the rrdtools for creating
> graphs.
>
> When I am sending an update-command to the RRD with no data, for which I am
> using the "U", what is mentioned in the documentation (If there is no data
> for a certain data-source, the letter U (e.g., N:0.1:U:1) can be
> specified.), in the RRD is a "NaN". When the RRD gets the next
> update-command with data and the heartbeat-value has not reached, an average
> rate will be calculated and added to this and to the previous data-source.
>
> But for monitoring tools it would be nicer: If there is no data, the graph
> should break.
>
> This could be realised by adding a new value, for e.g. "unknown-status",
> which I can edit with the update-command too. When this option is set, the
> heartbeat will be ignored and the graph will break.
> With this option, I can see the real breakdown of my monitoring.
> Otherwise the RRD creates data, which does not really exist.
>
> What would you say about this?

My sugestion would be that you set your mrhb to only a bit more
than your sampleing interval ... (as it should be) now, when you
miss samples, or you log 'U' rrdtool will turn the stored data into
NaN aka Unknown which will cause the graph to 'disapear' ...

My phanstasy is that you want to see the graph break for intervals
shorter than your step size ?

cheers
tobi
>
> Thanks!
>

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi@... ++41 62 775 9902 / sb: -9900

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[n1LL3]

oetiker wrote:

>
> My sugestion would be that you set your mrhb to only a bit more
> than your sampleing interval ... (as it should be) now, when you
> miss samples, or you log 'U' rrdtool will turn the stored data into
> NaN aka Unknown which will cause the graph to 'disapear' ...
>
> My phanstasy is that you want to see the graph break for intervals
> shorter than your step size ?
>
> cheers
> tobi
>

Hello Tobi,

good idea! At first we want to solve our problem like this as well, but then
other problems will occure.

For various reasons it could be that the RRD can not be updated in
continuous time intervals, for e.g.:
- system-latency
- network-latency
- reload of the monitoring tool
- restart of the server
...

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 hope you can comprehend what I mean.

Thanks!

--
View this message in context: http://n2.nabble.com/Additional-%22Unknown%22-Value-tp3042052p3054719.html
Sent from the RRDtool Users Mailinglist mailing list archive at Nabble.com.

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Alex van den Bogaerdt-2]

> 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

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[n1LL3]

Alex van den Bogaerdt-5 wrote:

>
> 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
>

Hello Alex,

this is exactly what I want!

Only your last point doesn't fit, but that's negligible.
Just for your interest, we store rrd-data for every minute without any
aggregation for 400 days.
And we make our SLAs just over 1 year, using the not-aggregated
every-minute-values.

Cheers!

--
View this message in context: http://n2.nabble.com/Additional-%22Unknown%22-Value-tp3042052p3055162.html
Sent from the RRDtool Users Mailinglist mailing list archive at Nabble.com.

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Tobias Oetiker-3]

Hi n1LL3,

Today n1LL3 wrote:

>
>
> oetiker wrote:
> >
> > My sugestion would be that you set your mrhb to only a bit more
> > than your sampleing interval ... (as it should be) now, when you
> > miss samples, or you log 'U' rrdtool will turn the stored data into
> > NaN aka Unknown which will cause the graph to 'disapear' ...
> >
> > My phanstasy is that you want to see the graph break for intervals
> > shorter than your step size ?
> >
> > cheers
> > tobi
> >
>
> Hello Tobi,
>
> good idea! At first we want to solve our problem like this as well, but then
> other problems will occure.
>
> For various reasons it could be that the RRD can not be updated in
> continuous time intervals, for e.g.:
> - system-latency
> - network-latency
> - reload of the monitoring tool
> - restart of the server
> ...
>
> 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 hope you can comprehend what I mean.

yes ... and if component C or D break you would want to have
different states for this too, so that the user can see what the
exact cause of the break was ... I'm afraid you will have to store
this kind of information outside rrdtool ... as rrdtool is not
realy siuted to store arbitrary information from the way it is
designed ...

fact is, you have no data for the given periode, hence you can not
charge your customers for it ... in dubio pro customer ... for
billing purposes I would set 'unknown' to 'zero' then you are on
the safe side, and you have a good incentive to make sure your
monitoring is rock solid ....

cheers
tobi



> Thanks!
>
>

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi@... ++41 62 775 9902 / sb: -9900

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[n1LL3]

oetiker wrote:

>
> yes ... and if component C or D break you would want to have
> different states for this too, so that the user can see what the
> exact cause of the break was ... I'm afraid you will have to store
> this kind of information outside rrdtool ... as rrdtool is not
> realy siuted to store arbitrary information from the way it is
> designed ...
>
> fact is, you have no data for the given periode, hence you can not
> charge your customers for it ... in dubio pro customer ... for
> billing purposes I would set 'unknown' to 'zero' then you are on
> the safe side, and you have a good incentive to make sure your
> monitoring is rock solid ....
>
> cheers
> tobi
>

Hello Tobi,

we don´t want to have the states inside of the RRD. For these we work with
thresholds outside of it.

What we want is a value, what we can give to the RRD with an update-command,
so the RRD knows that here was a real breakdown and it should not backfill
here. You mentioned in your first post that we should set the mrhb very
small, that the graph will break when only one check couldn´t get
performanca-data.
At first we thought that this could solve our problem.
But in my second post you can see a couple of reasons why we couldn´t do it
like that. Because when there is for e.g. a system-latency and the data
would come in some seconds too late, the graph will show a break, where
actually no break was.


Cheers!

--
View this message in context: http://n2.nabble.com/Additional-%22Unknown%22-Value-tp3042052p3079800.html
Sent from the RRDtool Users Mailinglist mailing list archive at Nabble.com.

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Tobias Oetiker-3]

Today n1LL3 wrote:
> What we want is a value, what we can give to the RRD with an update-command,
> so the RRD knows that here was a real breakdown and it should not backfill
> here.

ah ... in that case you log

rrdtool update $now-1:U
rrdtool update $now:new_value

then there will be no back-filling.

cheers
tobi


--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi@... ++41 62 775 9902 / sb: -9900

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Alex van den Bogaerdt-2]

Using some version of rrdtool, found on my system:

---cut here---
rrdtool create example1.rrd --step 300 --start 1245016800 DS:x:GAUGE:300:U:U
RRA:AVERAGE:0:1:100
rrdtool create example2.rrd --step 300 --start 1245016800 DS:x:GAUGE:300:U:U
RRA:AVERAGE:0.99:1:100
rrdtool create example3.rrd --step   1 --start 1245016800 DS:x:GAUGE:300:U:U
RRA:AVERAGE:0:300:100
rrdtool create example4.rrd --step   1 --start 1245016800 DS:x:GAUGE:300:U:U
RRA:AVERAGE:0.99:300:100

for i in 1 2 3 4
do
        rrdtool update example$i.rrd 1245017100:100
        rrdtool update example$i.rrd 1245017400:200
        rrdtool update example$i.rrd 1245017410:300
        rrdtool update example$i.rrd 1245017420:U
        rrdtool update example$i.rrd 1245017430:400
        rrdtool update example$i.rrd 1245017700:500
        rrdtool update example$i.rrd 1245018000:600
done

for i in 1 2 3 4
do
        rrdtool fetch example$i.rrd AVERAGE --start 1245017100 --end
1245018000
done
---cut here---

examples 1,2 and 4 have a known rate between 1245017400 and 1245017700. Only
example 3 has an unknown rate.

I think this is to be expected. Two important details:

1: the "U" update should not get superseeded by another update (here at
1245017430)
2: the unknown rate should not be ignored due to the X-Files Factor
(examples 2 and 4)

HTH
Alex


----- Original Message -----
From: "Tobias Oetiker" <tobi@...>
To: "n1LL3" <Christian.Michel@...>
Cc: <rrd-users@...>
Sent: Monday, June 15, 2009 2:08 PM
Subject: Re: [rrd-users] Additional "Unknown"-Value

> Today n1LL3 wrote:
>> What we want is a value, what we can give to the RRD with an
>> update-command,
>> so the RRD knows that here was a real breakdown and it should not
>> backfill
>> here.
>
> ah ... in that case you log
>
> rrdtool update $now-1:U
> rrdtool update $now:new_value
>
> then there will be no back-filling.
>
> cheers
> tobi
>
>
> --
> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
> http://it.oetiker.ch tobi@... ++41 62 775 9902 / sb: -9900
>
> _______________________________________________
> rrd-users mailing list
> rrd-users@...
> https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
>

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users