[kea-dev] Requirements for the Logging and Diagnostics in Kea

Shawn Routhier sar at isc.org
Thu Apr 9 05:48:20 UTC 2015

> On Apr 7, 2015, at 4:10 AM, Marcin Siodelski <marcin at isc.org> wrote:
> Hi All,
> One of the goals for the Kea 0.9.2. release is "Logging and Diagnostics Improvements". This includes a number of little improvements and tweaks to the existing logging system, but some of the possible enhancements are much more significant than this.
> I have created the requirements document http://kea.isc.org/wiki/DiagnosticsRequirements for "Logging and Diagnostics Improvements", which is meant to summarize the requirements mentioned in different discussions we've had so far.
> This document is still a "draft" because there is the outstanding requirement which we're discussing internally and I am not sure if there is a reliable way to implement it. That is:
> "Kea MUST provide an utility to automatically locate a core file after server crash to prevent future server runs from overriding the core file."
> Note that not only does this requirement provide a way to prevent override of the core file but it also allows for having a convenient way to put all useful debugging information in a single place (The same utility could copy the current configuration file, lease file, log file etc).
> However, I am not familiar with any standard and reliable way to locate the core files. On Linux I know that there is a core_pattern file but it may redirect the core file to a program, rather than save it in the specific location on the disk. In that case, you don't really know where the core dump goes.
> Please review all other requirements in the document and provide your feedback.
> Thanks,
> Marcin Siodelski
> DHCP SW Engineer
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev

I have one high level concern which is to make sure that the logging doesn’t end up 
impacting the performance of the server in general.  Using different log levels should
help some there but we may want to do some testing to see if anything more needs
to be done (allow to enable / disable some of the logging at run time or at compile time

1-8 - this is written such that it implies a single tool.  Do you want to mean that?  Or would
several tools be acceptable (for example one tool per backend each with something to read
that backend and that uses a common method to output to the CSV file).

Note that in the CSV case we may have several files that represent the “lease file”.  As they
are in the proper format we would probably want to simply copy all of them as part of the
collection process.

9, 10, 11, 12 - I’d like to clarify that this is happening for each individual callout.  So if
there are two callouts at the same hook we would get
info about calling callout 1
info about returning from callout 1
info about calling callout 2
info about returning from callout 2
If so we might also want a log message to indicate the start and end of the whole process
and might be able to move some of the duplicated information there so:
info about entering hook
same as above - except no hook information as that is already available.
info about leaving hook

We may want to include some sort of internal transaction id on each packet and use that
to connect the various log messages together.  

In 12 we have the callout execution time, I’m wondering if there are other times we might want
as well - potentially the total execution time and the time waiting for responses from the backend
DB might be useful.

In Tomek’s mail he mentioned logging information similar to that from ISC DHCP.  There
are three useful notes to consider.  

1) There may be a couple of items to add in some of the
messages.  Sadly I don’t recall them offhand but there were a couple of them where you
couldn’t tell quite what had happened from the message.  

2) we may wish to make some of
them more or less visible (possibly by use of log level).  With the current code we can get
rather large log files fairly quickly on a busy system, if Kea does get much better performance
this will be much worse.  Trying to notice “interesting” items within a large log file can be
difficult.  Yes you can search for things such as DHCPINFORM if you know that your
enterprise doesn’t use that but if we can provide a good way to stress odd items people
would probably like that.  

3) With ISC DHCP many people use scripts to review their log
files.  We try hard not to change the log entries once we have started using them to avoid
breaking existing scripts.  It would be best if we decide on the structure and format of
these log entries for Kea by 1.0 and don’t change them thereafter.  Also providing a good 
description of them in the docs would probably be appreciated.


More information about the kea-dev mailing list