<html><body>Hello Håvard,<div><br></div><div>thanks for your answer, I really appreciate it. </div><div>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. </div><div>But complaining does not help. </div><div>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.<br></div><div><br></div><div>As I wrote before, my plugin modification is <span style="background-color:transparent"> </span><span style="background-color:transparent">in "p_config" function</span></div><div>line 217 - 223</div><div><br></div><div>Regards, <br>-- <br>Smil Milan Jeskyňka Kazatel<br><br><aside>

---------- Původní e-mail ----------<br>

Od: Havard Eidnes <he@uninett.no><br>

Komu: KazatelM@seznam.cz<br>

Datum: 11. 4. 2019 13:23:55<br>

Předmět: Re: Unbound stats -> unbound_munin_ + another monitoring system

</aside><br><blockquote data-email="he@uninett.no">[[ Setting up a tangent on cumulative/non-cumulative counters ]]

<br>

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

<br>

<br>Truth be told, I never understood why anyone with their wits

<br>intact (not picking on you in particular...) would configure

<br>"statistic-cumulative: no".

<br>

<br>If you have a single monitoring client, that could work, for some

<br>value of "work".  However, with such a configuration, as soon as

<br>you sample the stats with e.g. unbound-control, you ruin that

<br>interval's counters for your monitoring client by resetting them

<br>to zero "out of order" wrt. the monitoring client's periodic

<br>polling.

<br>

<br>With multiple monitoring clients any hopes of accuracy is

<br>thrown out the window.

<br>

<br>It always struck me as a bad idea to even offer the option to the

<br>operator; IMHO the counters should always be counters in the

<br>sense used by SNMP, i.e. never reset to zero on read.

<br>

<br>Regards,

<br>

<br>- Håvard

<br></blockquote></div></body></html>