BIND 10 #421: Requirements for Logging Framework

[BIND 10 Development]

#421: Requirements for Logging Framework
--------------------------+-------------------------------------------------
      Reporter:  stephen  |        Owner:  UnAssigned
          Type:  task     |       Status:  reviewing 
      Priority:  minor    |    Milestone:            
     Component:  logging  |   Resolution:            
      Keywords:           |    Sensitive:  0         
Estimatedhours:  0.0      |        Hours:  0         
      Billable:  1        |   Totalhours:  0         
      Internal:  0        |  
--------------------------+-------------------------------------------------

Comment(by shane):

 Hey Stephen, I had a look at this, and have some comments.

   * It is not clear to me how logging sources work exactly. Can a log
 message belong to multiple logging sources? That is, can it belong to both
 the authoritative server ''and'' the DNS library? It seems like this is
 the case to me, but it should be explicit.

   * I think that whether a given source is enabled or disabled should be
 considered configuration, and managed by the config manager.

   * It is not clear to me that severity is per source. I think it should
 be.

 Note that if there are multiple sources per message then severity becomes
 tricky. For instance, what if I want debugging for the DNS library but
 only for the authoritative server? For simplicity I think we should not
 specify this, but maybe note that it is possible for future work.

   * Should we define some rough indication of what the debugging levels
 are, or offer any guidance as to how they should be used? (I am reminded
 of the habit in BASIC of numbering lines by 10 so that you can add lines
 in between if necessary...)

   * We should use file sizes as maximum, and rotate ''before'' we hit the
 defined size. I know it doesn't really matter whether we have 1000003 or
 999912 byte log files, but as an administrator I am always annoyed by
 "best effort" maximums.

   * File rotation based on time might also be useful. One tricky bit if we
 do decide to do that is that one cannot always guarantee a log message
 occurs in a given time interval. For example, if you specify log files
 every hour and no messages occur in that hour, how does the logging
 subsystem know to create a file? We can create an API to help do this, for
 example something like this:

 {{{
     next_rotation = logging.time_of_next_file_rotation()
     if next_rotation <= 0:
         logging.rotate()
         next_rotation = logging.time_of_next_file_rotation()
     (rlist, wlist, xlist) = select.select(rfds, wfds, [], next_rotation)
 }}}

 Alternately we could just specify that you should try rotating at least
 once per minute. :)

   * Whether we include rotation based on time, we will probably want some
 sort of way to define what file names look like for users.
 "/var/log/bind10/bind10-%Y%m%d.log" or similar (we can probably steal from
 some advanced syslog.

 It might be nice to set different logging levels per output. I think BIND
 9 allows this now. So what I think we really have is something like this:

 {{{
 +------------+
 | log output |
 +-----+------+
       |
       |
 +-----+------+     +----------+
 | log source +-----+ severity |
 +-----+------+     +----------+
       |
       |
 +-----+---------+
 | log(...) call |
 +---------------+
 }}}

 Each log output can be connected to any number of log sources
 (authoritative server, recursive server, DNS library, ...). Each log
 source is set to a specific severity. Each logging call (in the source
 code) can be connected to any number of sources.

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