BIND 10 #2154: Create a set of counters to hold auth statistics items

[BIND 10 Development]

#2154: Create a set of counters to hold auth statistics items
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jelte
  y-aharen                           |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20120904
                   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      |
-------------------------------------+-------------------------------------
Changes (by y-aharen):

 * owner:  y-aharen => jelte


Comment:

 Thank you for reviewing.

 Replying to [comment:8 jelte]:
 >
 > I still wonder whether these should be flat enums; especially in the
 case where we already have a group with a number->string relation (query
 types, opcodes, rcodes, etc.); for instance, in this way, all query types
 that fall outside of the current list will be reported as 'other', even
 though they have a perfectly acceptable type code (TYPEXX), this in itself
 may or may not be fine depending on the requirements.
 >
 > I also suspect this will make counting them trickier than strictly
 necessary; if you'd have multiple layers in the base structure, I'd
 imagine you could simply do something like
 > increaseCounter(QR_QTYPE, question.getType().getCode());
 >
 > (where increaseCounter would have an optional integer argument for those
 types that have subdivisions based on a number, like query types, opcodes,
 and rcodes).
 >
 > Of course these base structures might need to be more complicated in
 such a scenario (or we'd need another way to track which ones have
 subdivisions). And there could be efficiency reasons not to do it, but
 still.
 I made the counters flat for performance reason and to simplify structure.
 'other' type of qtypes, opcodes and rcodes are for BIND 9 compatibility.

 > Regarding the code itself, statistics_items.h contains one small style
 issue:
 > {{{
 > const char *SocketCounterItemName[SOCKET_COUNTER_TYPES] = {
 > }}}
 >
 > should be
 > {{{
 > const char* SocketCounterItemName[SOCKET_COUNTER_TYPES] = {
 > }}}
 >
 > and it can be made const char* const btw.
 >
 > Same for QRCounterItemName[]
 Yes, they can be. I made them const char* const (git 55b8cc3).


 > Lastly, I found a number of items on the original StatisticsItems page
 for Auth which aren't here:
 > {{{
 > auth.[zonename].authqryrej
 > auth.[zonename].updaterej
 > auth.[zonename].update.reqfwd
 > auth.[zonename].update.respfwd
 > auth.[zonename].update.fwdfail
 > auth.[zonename].update.done
 > auth.[zonename].update.fail
 > auth.[zonename].update.badprereq
 > }}}
 >
 > Obviously most of these aren't in auth because they will go in b10-ddns
 (except perhaps updaterej if ddns is not running?), so those should
 probably get their own category on the wiki page. Only the first one
 sounds like it could have been missed.
 The first one had been missing, I added it. The others should go in
 b10-ddns. I updated wiki:StatisticsItems.

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