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

[Tomek Mrugalski]

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:

> 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.


> 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.

> 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.

> 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.

> 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.

There are two items 24.

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.

Tomek