[smokeping-users] [BULK] Re: RRD max value hardcoded to 180

Adrian Popa adrian_gh.popa at telekom.ro
Tue Jun 9 12:04:06 CEST 2015


Hello everyone!

Update: After the changes I did yesterday the data was stored correctly. 
Only the overview graphs had missing/wrong data, but it was fixed by 
setting

max_rtt = 1000000000

in the overview section. Now all graphs are ok.

@Tobi: If I make the changes to the "max" setting in the rrd in the 
github code would you consider a pull request to remove the rrd limits 
(or do you want to do it yourself)?

I will also release the plugins I've been working on in the near future 
- they could be included in the core plugins if you'd like/if people 
find them useful.

Regards,
Adrian

On 06/08/15 18:12, Tobias Oetiker wrote:
> Hi Adria,
>
> yes, there are a few assumptions about timeing hardcoded in
> smokeping ... but you can certainly relax them ...
>
> cheers
> tobi
>
> Today Adrian Popa wrote:
>
>> Hello everyone!
>>
>> I'm writing some custom plugins for smokeping that don't measure time, but
>> measure bps (one plugin does periodic speedtests with speedtest.net). The
>> values returned are usually in the 10^6 range (Mbps).
>>
>> I noticed that the plugin works correctly, returns the data in the correct
>> format, but it doesn't get stored in the rrd:
>>
>> ds[ping1].index = 3
>> ds[ping1].type = "GAUGE"
>> ds[ping1].minimal_heartbeat = 7200
>> ds[ping1].min = 0.0000000000e+00
>> ds[ping1].max = 1.8000000000e+02
>> ds[ping1].last_ds = "2.3910000000e+08"
>> ds[ping1].value = NaN
>> ds[ping1].unknown_sec = 92
>>
>> last_ds is correct, but I guess rrdtool ignores it because it's higher than
>> "max".
>>
>> I've looked in the code where it sets the max value, and it's hardcoded to
>> 180:
>>
>> Smokeping.pm:560: "DS:median:GAUGE:".(2*$step).":0:180",
>> Smokeping.pm:561:                              (map {
>> "DS:ping${_}:GAUGE:".(2*$step).":0:180" }
>>
>> I wonder - why is the need to hardcode it to 180? I understand most probes are
>> fast and return small numbers, but -  is there any benefit from setting a max
>> value, and not setting max to "U"?
>>
>> I will change my code to have it set to U and report back if the problem
>> persists (I expect there will be problems with the Y scale, but we'll see...
>>
>> Regards,
>> Adrian
>>
>> _______________________________________________
>> smokeping-users mailing list
>> smokeping-users at lists.oetiker.ch
>> https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
>>
>>



More information about the smokeping-users mailing list