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




Regards, 
--
Smil Milan Jeskyňka Kazatel

---------- Původní e-mail ----------
Od: Havard Eidnes <[email protected]>
Komu: [email protected]
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
polling.

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.

Regards,

- Håvard
"

Reply via email to