BIND 10 #2157: Create an interface to pass statistics counters in Auth module

[BIND 10 Development]

#2157: Create an interface to pass statistics counters in Auth module
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  y-aharen                           |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20121106
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  b10-auth                           |  Estimated Difficulty:  8
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:27 y-aharen]:

 > > I'm sorry for being stubborn, but I'm still not convinced.  This time
 > > I took a little bit deeper look at the branch and the stats
 > > implementation, but I don't understand what's the fundamental design
 > > limitation of Stats that requires the hardcoded specific RR types in
 > > auth.spec.  For example, can't it be a named set?
 > I think the structure of the counters should be defined in the spec
 file,
 > except for zones definition, for differential updates of statistics
 > (scheduled to be implemented). If no RR types are given, Stats can't
 > distinguish the item exists (and just not incremented at the time) or
 not.

 I don't see why this is a problem with named sets.

 The stats daemon would initially begin with an empty map.
 Auth will then send (or respond to a request) first update like this:
 "NS": 10
 "AAAA": 42
 then the stats daemon's set will become
 {"NS": 10, "AAAA": 42}
 Next time auth will send another update like this:
 "SOA": 5
 "AAAA": 2
 then the stats daemon's set will become
 {"NS": 10, "AAAA": 44, "SOA": 5}
 and so on.

 > Users will be happy if they can get a list of items from 'Stats show'.

 I'm not sure what this means, but 'Stats show' would still show items
 that have positive counter values.  The user will naturally assume the
 counter value for the rest is 0.  And I'd rather see such a compact
 output (besides, that's how BIND 9 currently works for per
 rrtype/opcode statistics.) than having many 0 value items.

 > There is no way to get defined RR types and the other per-code counters
 > for Stats except in the spec file.

 But, in any case, as I suggested in the call, as a practical way
 forward I'd like to propose leaving how to represent per-type counters
 open, and (although I'd like to revisit the way of defining others
 too) keep the current approach for the others and complete this task.
 If you agree on that, we can move on; if you still think we should
 include the per RRtype statistics in the way it's implemented in the
 branch, I think we need to discuss it in the list.

 Finally, some initial comments at this point:

 '''general'''

 - Isn't it possible to unify the definition of the counter information
   (things like QR_REQUEST_IPV4, QR_OPCODE_QUERY, etc), e.g., in some
   separate file and auto generate others?  Right now, we have the same
   kind of information at least in 3 different places: auth.spec,
   statistics_items.h, and the man page.  Even excluding RR types, that
   can easily cause maintenance problems.
 - I'd like to avoid relying on a magic keyword like `_SERVER_`.  In
   fact, there could even a zone of that name.
 - if possible I'd like to make one clarification before merging this
   branch.  That is, the BIND 9 version of statistics counters are
   confusing in that the sum of any of QRYxxx does not match the number
   of incoming queries.  I'd clarify the counters so that at least the
   sume of some subset of QRYxxx counters equals to QR_OPCODE_QUERY.

 '''statistics_items.h'''

 - We shouldn't use namespace {} or define things here.  Only
   declaration is okay.  See #2358 for these.

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