[bind10-dev] Statistics features & tasks

[Shane Kerr]

All,

Kambe-san has worked with Aharen-san and Fujiwara-san to produce a list
of features & tasks for the statistics work. The idea is that we can
then fit the statistics into the Scrum model.

I think it makes sense to discuss them a bit, and then we can think
about estimates.

First, we have the the features with a suggested ordering:

  High
      * Extend collection of statistics from Auth
      * HTTP/XML statistics reporting in BIND 9 style
      * Add collection of statistics from Recursor
      * Add collection of statistics from Xfrin/Xfrout
      * Add/extend collection of statistics from such modules
        - Boss
        - Msgq
        - Cfgmgr
      * SNMP statistics reporting
  Low

I think this matches my own preferences, although perhaps Larissa has
other feelings.

A few new features were suggested:

 * Adopting visual graph drawing including third parties

I'm not exactly sure what the extend of this is. Is the idea to provide
data in a format that specific 3rd party visualization tools can use?
I'm not opposed to this in principle, although this will probably be
"contrib"-style additions rather than core BIND.

 * Adopting statistics storage which is stored the data once
   calculated by stats daemon
   (It's like SQLlite or in-memory DB?)

The idea here is that the statistics will remain across reboots? That
makes sense to me, assuming that is the idea.

 * Management of statistics items
   (It's currently defined in 'config_data' of the stats spec file.)

Okay, this is also important. Note that I'll be posting a version of
Jerry Scharf's work on the BIND 10 command tool soon, which should help
define how this will work. (Don't be scared, it's good stuff.)


Moving on from the features to the task list:

  Task related to Stats:
    - Overhauling the current design of the stats daemon for implement
      HTTP/XML reporting

I think we need to discuss this. I assumed that HTTP/XML reporting was
to be done by a separate process. That way if you don't want HTTP/XML
reporting you don't have to run the code at all, plus any errors in the
code won't affect other statistics reporting, and so on. These are all
of the usual reasons for using separate processes for different
functionality.

If the redesign is intended to support HTTP/XML functionality in a
separate task then that is fine. If the redesign is meant to include
this in the statistics collection daemon, then I'd like to know the
motivations. 

  Tasks related to Auth (after #347):
    - Merge IntervalTimer into lib/asiolink
    - Definition of auth statistics to be tracked
    - Review of definition of auth statistics to be tracked
    - Code for configurable interval of submitting statistics via Cmdctl
    - Review of code for configurable interval of submitting statistics
    - Code for parsing response from statistics module
    - Review of code for parsing response from statistics module
    - Design for reducing performance overhead of auth statistics
    - Review of design for reducing performance overhead of auth
statistics
    - Code for reducing performance overhead of auth statistics
    - Review of code for reducing performance overhead of auth
statistics

These other tasks all make sense to me. :)

--
Shane