blackbox_exporter
blackbox_exporter copied to clipboard
prometheus
Add probe_dns_rcode metric
This metric has the value of the response code from the DNS server; 0 is NOERROR, per https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
It can be used along with probe_success in order to diagnose why failures occurred.
For #474.
Signed-off-by: David Leadbeater [email protected]
It was mentioned in #799 -- it would be nice, but per https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6 there's quite a few possibilities, maybe we could pick the ones we think are likely...
Say NOERROR, SERVFAIL, NXDOMAIN, REFUSED and then have an OTHER for the rest would cover it, but we do then lose what the actual rcode is (unless we use the value of OTHER to be the rcode, but that is wrong for an ENUM style metric...)
Adding some reviewers to get any thoughts on labels vs numbers...
Sorry, I was sure I had replied to this...
I would prefer @SuperQ's proposal. That makes it easier to build a counter out of this if desired (e.g. using a recording rule).
IIRC there are ~ 40 possible response codes. As long as the returned one is always captured, I don't have a strong preference for including a few select ones all the time.
We could provide a list of default "always expodsed" rcodes as a command line flag. Something like --probe.dns.rcodes=NOERROR,SRVFAIL,NXDOMAIN". If the rcode is some other code, we could either assign it to an OTHER bucket, or since it's reasonably limited, we could directly expose the "other" code.
Opinions?
We could provide a list of default "always expodsed" rcodes as a command line flag. Something like
--probe.dns.rcodes=NOERROR,SRVFAIL,NXDOMAIN". If the rcode is some other code, we could either assign it to anOTHERbucket, or since it's reasonably limited, we could directly expose the "other" code.Opinions?
I would be OK with that (either option: exposing the "new" code, or using an "OTHER" bucket, maybe leaning slightly towards the latter).