BIND 10 #170: document how stats are collected (via spec files)

[BIND 10 Development]

#170: document how stats are collected (via spec files)
-----------------------------+----------------------------------------------
      Reporter:  larissas    |        Owner:  jinmei                     
          Type:  task        |       Status:  reviewing                  
      Priority:  major       |    Milestone:  06. 4th Incremental Release
     Component:  statistics  |   Resolution:                             
      Keywords:              |    Sensitive:  0                          
Estimatedhours:  0.0         |        Hours:                             
      Billable:  0           |   Totalhours:                             
      Internal:  0           |  
-----------------------------+----------------------------------------------

Comment(by jinmei):

 Replying to [comment:17 shane]:
 > From my point of view this is fine. Jinmei should address the concerns
 directed to him. I'm changing the owner so he can do that (sorry about not
 doing this sooner!).
 >
 Ditto about not doing this sooner.

 I'm responding to this comment:
 https://bind10.isc.org/ticket/170?replyto=17#comment:14

 > These counters means "total" count for one auth server, but I
 > think "incremental" count for one auth server may be also supported.
 > Because I think each auth sever may not know how many auth servers
 > work and if it means total counter, all auth servers must support a
 > very long-range counter. I think it may be very heavy for auth servers.
 >
 I'm not sure if I understand this part.  Do you mean an auth server can
 run for a long time (e.g. several years) and a monotonically increasing
 counter may overflow?  If so, I don't know how the number of auth servers
 (btw what this means?  the number of auth server processes/threads
 assuming we adopt a multi-process/thread server model?) is related to the
 point.  Also, should we really worry about overflow in a realistic
 scenario?  Suppose we handle 100,000 qps, and have a counter of number of
 queries.  If it's a 64bit unsigned integer, it won't overflow until
 368,452,886,146 years later.  Even if it's 32bit, it won't overflow until
 85 years later.

 If this is about overflow, and if there's no realistic scenario we should
 worry about, I suggest we begin only with a simple total counter.
 Otherwise, please explain what's I'm missing.

 I have no problem with the proposed python syntax, btw.

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