Unbound stats -> unbound_munin_ + another monitoring system

Milan Jeskynka Kazatel KazatelM at seznam.cz
Thu Apr 11 11:56:32 UTC 2019

Hello Håvard,

thanks for your answer, I really appreciate it. 

I agree with you, the original Munin plugin with non-cumulative counters is 
not the best way, how to monitor Unbound application from more than one 
monitoring system. 

But complaining does not help. 

Anyway, have you any experience with Munin plugin and modifying existed 
contrib/munin/unbound_munin_ in the case when is Unbound set to a cumulative
counter and Munin shows rrd in COUNTER or DERIVE format, but the graf is 
still not displayed correctly. I did some update in the plugin in hope, when
the counter type would be set to COUNTER or DERIVE, then the Munin graph can
show me some valid information, but it still shows to me only the 
exponential line - then plugin did not count.

As I wrote before, my plugin modification is  in "p_config" function

line 217 - 223

Smil Milan Jeskyňka Kazatel

---------- Původní e-mail ----------
Od: Havard Eidnes <he at uninett.no>
Komu: KazatelM at seznam.cz
Datum: 11. 4. 2019 13:23:55
Předmět: Re: Unbound stats -> unbound_munin_ + another monitoring system 
"[[ Setting up a tangent on cumulative/non-cumulative counters ]] 

> I set the Unbound configuration to statistic-cumulative: yes 

Truth be told, I never understood why anyone with their wits 
intact (not picking on you in particular...) would configure 
"statistic-cumulative: no". 

If you have a single monitoring client, that could work, for some 
value of "work". However, with such a configuration, as soon as 
you sample the stats with e.g. unbound-control, you ruin that 
interval's counters for your monitoring client by resetting them 
to zero "out of order" wrt. the monitoring client's periodic 

With multiple monitoring clients any hopes of accuracy is 
thrown out the window. 

It always struck me as a bad idea to even offer the option to the 
operator; IMHO the counters should always be counters in the 
sense used by SNMP, i.e. never reset to zero on read. 


- Håvard 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20190411/aea3db67/attachment.htm>

More information about the Unbound-users mailing list