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:  y-aharen
  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 jelte):

 * owner:  jelte => y-aharen


Comment:

 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.

 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[]

 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.

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