[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