Support traffic metrics

[SuperQ]

There are some interesting metrics on the traffic statistics endpoint. They appear to be sparse histogram buckets. It will take some digging, but we might be able to translate these into Prometheus buckets.

<?xml version="1.0" encoding="UTF-8"?>
<statistics version="3.8">
  <server>
    <boot-time>2020-01-12T16:30:26.247Z</boot-time>
    <config-time>2020-01-12T16:30:26.371Z</config-time>
    <current-time>2020-01-12T16:42:45.433Z</current-time>
    <version>9.11.5-P4-5~bpo9+1-Debian</version>
  </server>
  <traffic>
    <ipv4>
      <udp>
        <counters type="request-size">
          <counter name="16-31">3718</counter>
          <counter name="32-47">10699</counter>
          <counter name="48-63">12175</counter>
          <counter name="64-79">834</counter>
        </counters>
        <counters type="response-size">
          <counter name="64-79">100</counter>
          <counter name="80-95">1382</counter>
          <counter name="96-111">12759</counter>
          <counter name="112-127">3157</counter>
          <counter name="128-143">847</counter>
          <counter name="144-159">1</counter>
          <counter name="176-191">50</counter>
          <counter name="192-207">8971</counter>
          <counter name="208-223">105</counter>
          <counter name="224-239">52</counter>
          <counter name="480-495">1</counter>
          <counter name="496-511">1</counter>
        </counters>
      </udp>
      <tcp>
        <counters type="request-size"/>
        <counters type="response-size"/>
      </tcp>
    </ipv4>
    <ipv6>
      <udp>
        <counters type="request-size">
          <counter name="32-47">2</counter>
          <counter name="48-63">35</counter>
        </counters>
        <counters type="response-size">
          <counter name="64-79">2</counter>
          <counter name="96-111">9</counter>
          <counter name="112-127">4</counter>
          <counter name="128-143">21</counter>
          <counter name="144-159">1</counter>
        </counters>
      </udp>
      <tcp>
        <counters type="request-size"/>
        <counters type="response-size"/>
      </tcp>
    </ipv6>
  </traffic>
  <views/>
</statistics>

[dswarbrick]

I'm just going to add this from the bind9 source lib/dns/include/dns/stats.h:

/*%
 * Traffic size statistics, according to RSSAC002 section 2.4
 * https://www.icann.org/en/system/files/files/rssac-002-measurements-root-20nov14-en.pdf
 *
 * The RSSAC002 linear bucketing does not directly match the log-linear
 * bucketing of an `isc_histo_t`, so we need to adjust some parameters
 * to fit.
 *
 * To map a message size to an `isc_histo_t`, first divide by
 * DNS_SIZEHISTO_QUANTUM so that `isc_histo_inc()` is presented with
 * one value per RSSAC002 bucket.
 *
 * Configure the `isc_histo_t` with large enough `sigbits` that its
 * one-value-per-bucket range (its `UNITBUCKETS`) covers the range
 * required by RSSAC002.
 */
#define DNS_SIZEHISTO_QUANTUM    16
#define DNS_SIZEHISTO_MAXIN  (288 / DNS_SIZEHISTO_QUANTUM)
#define DNS_SIZEHISTO_MAXOUT     (4096 / DNS_SIZEHISTO_QUANTUM)
#define DNS_SIZEHISTO_SIGBITSIN  4
#define DNS_SIZEHISTO_SIGBITSOUT 7

#define DNS_SIZEHISTO_BUCKETIN(size) \
    ISC_MIN(size / DNS_SIZEHISTO_QUANTUM, DNS_SIZEHISTO_MAXIN)

#define DNS_SIZEHISTO_BUCKETOUT(size) \
    ISC_MIN(size / DNS_SIZEHISTO_QUANTUM, DNS_SIZEHISTO_MAXOUT)

STATIC_ASSERT(DNS_SIZEHISTO_MAXIN <=
              ISC_HISTO_UNITBUCKETS(DNS_SIZEHISTO_SIGBITSIN),
          "must be enough histogram buckets for RSSAC002");

STATIC_ASSERT(DNS_SIZEHISTO_MAXOUT <=
              ISC_HISTO_UNITBUCKETS(DNS_SIZEHISTO_SIGBITSOUT),
          "must be enough histogram buckets for RSSAC002");

I'm not sure if we would want to use buckets as granular as 16 bytes, especially when you consider that DNS_SIZEHISTO_MAXOUT is going to yield 256 buckets. Maybe translate to log2 buckets?