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
Regards,
--
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
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
"
-------------- 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