Statistics Ideas

This wikipage is for brainstorming ideas for the statistics interface.

Existing BIND 9 features

  • have around 130 counters, such as IPv6 requests received, Requests with TSIG received, Zone transfer requests rejected, etc.
  • XML-based statistics interface
  • almost all statistics counters supported in BIND 8
  • statistics counters about internal status (sockets/tasks/memory usage)
  • file based statistics (but not needed if going to just XML)
  • per zone statistics


  • per remote host statistics
  • RESTful interface to get to specific statistics in XML (not everything at once)
  • all BIND 10 components may have statistics counters (even if not DNS related)
  • Separate daemon to handle HTTP requests and/or generate XML reports; BIND 10 will have separate processes running so having a central location to submit counter information might be useful.
  • will the daemon store details on all statistics?
  • use CC / msgq for subscribing to statistics and to send or receive stats data
  • How much will the stats daemon hold?
  • Will the stats daemon periodically write to disk to store its collected data?
  • "statistics daemon" (ala syslogger) that is generic to listen for stats messages, then keeps counters or other growing stats data, and then can export them in some format(s) which can be used for reports and graphs. (Evi Nemeth shared the initial idea for this stats daemon at June 2009 face-to-face meeting.)
  • It will also listen for queries so can provide the individual stats counters (or data) in near real-time.
  • A daemon because many different programs may be sending stats data to it simultaneously; for example, a HTTPD webserver could submit various counters to it and a DNS server could submit counters to it also.
  • Does it need to be a daemon? Can't it be a tool that's invoked by things that works on files?
  • What's wrong with many different programs invoking an utility to alter an on-disk database?
  • On-disk may be too slow? So this would only write to disk periodically (even if every second).
  • Then again, the initial program submitting the stats would have its own counters and doesn't need to submit them in real time. So maybe speed doesn't matter.
  • What about top-ten lists, such as top ten records getting queries? If the server is hosting 1 million zones, would the stats daemon need to keep track of all of these? Or should the auth server component itself keep track?
  • Why not just query the individual components for their details and just have non-daemon tool do these queries and generate custom reports? (So no stats daemon needed or always running.)
  • What about just having the zone databases also have data fields for different per-record and per-zone counters?
  • Would it be useful to keep track of record creation/birth time, record change/modification time? record last access/read time? (per record or per RRset?)
Last modified 9 years ago Last modified on Dec 17, 2009, 10:04:01 PM