[bind10-dev] Result of Question about statistics incremental update

Naoki Kambe kambe at jprs.co.jp
Wed Oct 17 11:59:29 UTC 2012


From: fujiwara at jprs.co.jp
Date: Wed, 17 Oct 2012 15:49:19 +0900 (JST)
> To implement this idea, we need to update
>     - statistics protocol document  (where ? on wiki?)
>     - config specification document (where ? on wiki?)
>     - config library both c++ and python
>     - config daemon
>     - stats  daemon
>     - auth or another components
To implement all of these, I'm afraid that we might need a lot of costs
:(.

Sorry for late responding, but can I propose another example?  This
proposal is probably like the third option in the second question.
For distinguishing whether data are full type or incremental type, how
about introducing meta names, e.g. _FULL_, _INCREMENTAL_ , in the
top-level statistics items?  Then statistics data can be under such
meta names as usual.

For example, statistics data returned from each module is like the
following format:

  {
    '_FULL_': {
      'boot_time': '2012-10-17T19:49:48Z',
      'soa_serial': '2012101701',
      ...
    },
    '_INCREMENTAL_': {
      'queries.udp': 1003,
      'queries.tcp': 31,
      ...
    }
  }

And statistics spec of that module is like the following:

  ..
  "statistics": [
    {
      "item_name": "_FULL_",
      "item_type": "map",
      "item_optional": true,
      "item_default": {},
      "item_title": "Full statistics",
      "item_description": "Full statistics data",
      "map_item_spec": [ .. ]
    },
    {
      "item_name": "_INCREMENTAL_",
      "item_type": "map",
      "item_optional": true,
      "item_default": {},
      "item_title": "Incremental statistics",
      "item_description": "Incremental statistics data",
      "map_item_spec": [ .. ]
    }
  ]

Regarding '_FULL_' data, the stats daemon replaces the existing ones
when it accepts them.  Regarding '_INCREMENTAL_' data, it sums the
existing ones and that.  Probably all this data format can be
expressed by using only the existing spec file.

So as for benefit of this proposal, we don't need to revise the core
libraries handling a spec file. We need to revise only codes of the
stats daemon and other target modules handling such statistics
data. However I don't think we might need so many costs for
that. Because statistics data structure would not be changed drastically.

Regards,

Naoki Kambe


More information about the bind10-dev mailing list