BIND 10 #2135: design a new statistics model

[BIND 10 Development]

#2135: design a new statistics model
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  UnAssigned
  naokikambe                         |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120821
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  statistics                         |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  8
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Description changed by naokikambe:

Old description:

> As a result of the f2f meeting in Apr, we agreed that the stats daemon
> should pull statistics from each module. But in the current model, each
> module pushes to the stats daemon. So we need to design such a pull
> module before implementation.
> Current model:
> {{{
> +----+      +-----+
> |Auth| ---> |Stats|
> +----+ push +-----+
> }}}
> New model:
> {{{
> +----+ <--- +-----+
> |Auth| ---> |Stats|
> +----+ pull +-----+
> }}}
>
> In this ticket, the task is to revise the existing document
> [[StatsModule]] in which the current model is described. In that
> document, we should also describe how the stats daemon invokes the
> command and how the modules reply to that.
>
> If the new model is implemented into all modules, the existing push model
> would be unused and the codes might be dead codes. So we should replace
> the current model with the new model. After the implementation, we would
> remove such dead codes.

New description:

 As a result of the f2f meeting in Apr, we agreed that the stats daemon
 should pull statistics from each module. But in the current model, each
 module pushes to the stats daemon. So we need to design such a pull module
 before implementation.
 Current model:
 {{{
 +----+      +-----+
 |Auth| ---> |Stats|
 +----+ push +-----+
 }}}
 New model:
 {{{
 +----+ <--- +-----+
 |Auth| ---> |Stats|
 +----+ pull +-----+
 }}}

 In this ticket, the task is to revise the existing document
 [[StatsModule]] in which the current model is described. In that document,
 we should also describe how the stats daemon invokes the command and how
 the modules reply to that.

 If the new model is implemented into all modules, the existing push model
 would be unused and the codes might be dead codes. So we should replace
 the current model with the new model. After the implementation, we would
 remove such dead codes.

 [Additional description]
 5 Main purposes of this ticket are:

 * Change from pushing statistics data to fetching statistics data

   In current version, each target module pushes statistics data to the
 stats module.  In next version, the stats module asks each module to
 return statistics data.  It is discussed in #1847 that the timeout problem
 is caused if the stats module isn't there.  this change is for fixing the
 problem. The existing pushing model should be removed from both of the
 stats module and each module because the pushing model is expected to be
 unused and the algorithm of the modules is expected to be complicated.

 * Make the stats module ask each module periodically

   Due to the above change, the target modules never send statistics data
 to the stats module. In stead of this, the stats module asks each module.
 That behavior should be periodical. The periodical time should be
 configurable for a administrator. Thus the stats module should have an
 interval time item in its configuration.

 * Introduce a new command in each module for returning statistics data

   For returning statistics data, a new command is required for each
 module.  Details of the command should be described in the wikipage. For
 example, the things are : what name of the command is, whether the command
 has an argument, how the target module returns statistics data what the
 stats module should do if statistics data are invalid.

 * Consider multiple instances of the same module running

   In the case of running multiple instances of the same module, the things
 to be considered are: When a instance is unexpectedly down, how the stats
 module handles its collected statistics data. Whether the stats module
 should hold them or discard them.

 * Consider against the increasing amount of statistics data

   In the current version, the amount of statistics data which all modules
 have is not so much. But if the statistics items of each module increase,
 we wouldn't be able to ignore the total amount of statistics data which
 would be sent in the message queue. Each module should return only
 differential updates of statistics data for reducing the amount.

--

-- 
Ticket URL: <https://bind10.isc.org/ticket/2135#comment:11>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development