BIND 10 #1448: document basic design of stats snmp interface

BIND 10 Development do-not-reply at isc.org
Mon Jan 30 04:33:14 UTC 2012


#1448: document basic design of stats snmp interface
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  UnAssigned
  naokikambe                         |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20120207
                  Component:         |            Resolution:
  statistics                         |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:  SNMP   |           Total Hours:  0
  stats                              |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by naokikambe):

 Replying to [comment:7 jelte]:
 Hello,

 IMO in this pull-protocol a non-stats module doesn't have to take care
 about the timing to push its statistics to the stats. the timing doesn't
 need to be periodical exactly. The non-stats module can be free to throw
 its statistics.
 OTOH in push-protocol it's high cost for a non-stats module to wait for a
 request from stats. Especially for a usual busy module like auth, it might
 be truly high cost. Besides, in order to migrate to the push-protocol, we
 should implement each non-stats module to wait for the stats and should
 implement stats to request to each non-stats module.
 BTW as another approach: each non-stats module stores its statistics
 somewhere in the SQLite database, and then stats module reads there
 periodically. Such statistics saved in the sqlite might be permanent even
 if the bind 10 reboots. But after the bind10 starts, each module may have
 to take care about consistency of statistics data between in database and
 in itself.
 Anyway I don't think we should discuss here about these protocols.

 Best,

-- 
Ticket URL: <http://bind10.isc.org/ticket/1448#comment:8>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list