RCODE metrics patch

Hi,

We'd like metric values for RCODEs 0-5 to always be emitted, even when their value is zero. I understand why the "don't print if zero" test is present but RCODEs 0-5 seem to be the minimum we'd alway like to have.

I've attached a

(attachments)

unbound-rcode-metrics.patch (603 Bytes)

(let me try this a second time, without hitting send before I was ready. apologies for the dupe email)

Hi,

We'd like metric values for RCODEs 0-5 to always be emitted by unbound-conotrl, even when their value is zero. I understand why the "don't print if zero" test is present but RCODEs 0-5 are the minimum we'd like to have all the time. For these I'd rather not have to worry about whether we're in a 'metric absent' or a 'metric is zero' state.

I've attached a patch which only applies the "don't print if zero" test for RCODEs greater than five (REFUSED). Wouter; perhaps you'd consider applying this for the next release?

Thanks,
james

(attachments)

unbound-rcode-metrics.patch (617 Bytes)

Hi James,

Thank you for your patch. I've applied it :slight_smile:

Best regards,
   Wouter

Raftery, James:

We'd like metric values for RCODEs 0-5 to always be emitted by unbound-conotrl, even when their value is zero.

could you describe the problem your patch solve?
Thanks...

Hi,

Wouter; thanks for applying the patch!

could you describe the problem your patch solve?

Without it unbound-control omits num.answer.rcode.<something> metrics when they're zero. So you get this:

num.answer.rcode.NOERROR=93
num.answer.rcode.NXDOMAIN=50
num.answer.rcode.nodata=24

instead of this:

num.answer.rcode.NOERROR=93
num.answer.rcode.FORMERR=0
num.answer.rcode.SERVFAIL=0
num.answer.rcode.NXDOMAIN=50
num.answer.rcode.NOTIMPL=0
num.answer.rcode.REFUSED=0
num.answer.rcode.nodata=24

If you've a metrics system that knows the difference between 'absent' and 'zero' this is troublesome. Rather than definitive metric points at zero telling you everything's working well you have potentially long gaps in data points which can mistakenly be interpreted as a fault in the metrics gathering/publishing systems.

james