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

[Marcin Siodelski]

On 07.04.2015 21:00, Tomek Mrugalski wrote:
> On 07.04.2015 13:10, Marcin Siodelski 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.
> Thanks for writing this document. It's very good, but I do have a couple
> small comments:
>

Thanks!

>> 3. The tool MUST output lease information to the CSV file having the
>> same format as the lease file created by the Memfile backend, but the
>> order of columns MAY be different.
> Why order of columns MAY be different? It would make any automation
> impossible (or at least very difficult). Note that such a tool could
> double as a migration tool between backends, but would be next to
> useless if the order wasn't maintained.
>
> It would be also difficult to automate any sanity checks or statistics
> if the other is different.
>

So how about removing the statement about the ordering? While I take 
your point about the possibility to use it as a migration tool this 
document is about the requirements for diagnostics and this doesn't 
require the strict ordering.

>
>> 9. and 14.
> I would like to raise a point mentioned by Angelo couple days ago. It
> would be very helpful to log the amount of time it took to execute the
> callout. It's very likely that we'll also be exporting this info as one
> of the statistics.
>

Agreed. I added the requirement for the hooks framework to log the 
execution time for each (out of many) callouts.

>> 15.
> Not sure if that's included in this requirement or not, but one user
> strongly requested that the Kea code should log its decisions in a
> format that contains at least the same amount of information as
> ISC-DHCP. In particular, the following info was requested to be logged
> in IPv4:
>
> DHCPDISCOVER from <client hwaddr> via <giaddr>
> DHCPOFFER on <lease ip addr> to <client hwaddr> via <giaddr>
> DHCPREQUEST (<client state>) for <lease ip addr> from <client hwaddr>
> via <giaddr>
> DHCPACK on <lease ip addr> to <client hwaddr> via <giaddr>
> DHCPNAK to <client hwaddr> via <giaddr>
> DHCPDECLINE of <lease ip addr> from <client hwaddr> via <giaddr>
> DHCPRELEASE of <lease ip addr> from <client hwaddr> via <giaddr>
> DHCPINFORM from <client hwaddr> via <giaddr>
>
> I suppose it can be extended with additional details, e.g. why NAK was
> sent or the interface name the packet was received on.
>

I don't want to overspecify it in the requirements doc. I'd rather put 
it into the design doc instead.

>> 16. Kea MUST log when the significant logical unit of work during the
>> packet processing has ended.
> I'm not opposing that, but a well defined definition of "significant
> logical unit of work" must be written (and maintained). A list of all
> steps would be an useful thing to have.
>

Sigh. Maybe. But it is hard to do it upfront without missing something 
important. I think it may be better to go over the code, update it as 
appropriate and then think whether it may be categorized.

>> 19, 20, 21
> Additional information should be provided if possible. In particular,
> the interface name and on which the packet was received, also relay
> information if available. Those cases usually mean that there's some
> troublemaking device in the network. Assisting an administrator in his
> quest to find it would be useful.
>

I added a separate requirement for this.

> There are two items 24.
>

Renumbered.

> There are two items I'd like to have on this list. One user requested to
> have a list of
>
> I would add another item to the list. Have an simple to configure
> ability to log all messages to a single destination. In the BIND10 days,
> we used to be able to specify loggers name as "*" and redirect
> everything to a single destination. With bindctl long gone, that is no
> longer possible, at least I failed to configure it. This is pretty
> important in my opinion. Even the best logging messages are useless if
> you happen to misconfigure your logging output and the messages are not
> logged at all.
>

I added a requirement for the single common logging entry for all 
loggers. But, this is only one item. You mentioned two?

Marcin