[kea-dev] Pool usage monitoring in Kea ?

Tomek Mrugalski tomasz at isc.org
Fri Nov 14 18:01:03 UTC 2014

On 14/11/14 03:43, Chaigneau, Nicolas wrote:
> I'm looking into the possibility to monitor the pools usage in Kea,
> more specifically for a "memfile" back-end. For dhcpd, we've been
> using an external tool: dhcpd-pools
> (http://dhcpd-pools.sourceforge.net/) which works by parsing dhcpd
> config and lease files. This tool is used at regular time intervals
> to produce reports in a log file.
> This could be ported to support Kea, but I wonder if there could be a
> better way ? For one thing, dhcpd-pools has to parse the lease file,
> and this is quite slow for very large lease files.
Possibly, yes. One thing to remember is that the lease file will contain
expired leases. They should not be counted as used as they are available
for the server assignment.

> Would it be possible to use Kea hook API to provide this
> functionnality ? I've seen the "lease4_select" hook which seems
> interesting. Do you think the "subnet4collection" argument could be
> used to check how many leases are currently allocated for each pool,
> and report the information ?
You could implement your own statistics module using hooks. You'd create
a table of integers called subnets_counter and a size of
subnet4collection returned in subnet4_select for example. You'd need to
manage that statistic from two points. First, lease4_select callout
would increase a given statistic when new lease is assigned (just pay
attention to fake_allocation flag - the callout is called also during
Discover processing and the lease is not assigned then) or existing
lease is released (see lease4_release callout).

That would give you very efficient statistics gathering mechanism. It
would be accurate as long as no leases are expired. Unfortunately, we
don't have the proper expiration mechanism yet. Once it is implemented,
we'll likely add extra callouts: lease4_expire and lease6_expire.

However, this approach is a bit hacky. The proper solution for
statistics gathering will be more involved. In bind10 days, Kea had a
control socket that used to receive commands from bind10 framework. The
commands and the responses from the server were JSON structures. When we
removed the bind10 framework, we lost the communication channel. Kea now
has the capability to process the commands, just there's no way to
receive those commands or send responses. This is something we plan to
do in 0.9.1 release. It won't be super-fancy - probably just a unix
socket for now.

Currently Kea supports 3 commands: shutdown, libreload, config-reload.
As a temporary workaround, we use signals to trigger those commands.

It seems reasonable to extend that commands list with an additional
command, maybe 'stats-get'. If you are interested, please take a look at
ControlledDhcpv4Srv::processCommand in src/bin/dhcp4/ctrl_dhcp4_srv.cc.

As for the actual stats gathering, the statistics code should work
uniformly for all backends. We would probably need to extend the generic
API to LeaseMgr (see src/lib/dhcpsrv/lease_mgr.h) with something like
getStats() that would return an array with number of leases in each
subnet (or rather an array of structures, with each structure having
least count information. That way we could extra stats in the future
without changing the API).

Once LeaseMgr API is extended, we'd need to implement for specific
backends, e.g. Memfile_LeaseMgr (see src/lib/dhcpsrv/memfile_lease_mgr.h).

This is how I would do statistics. Please note that this is a napkin
style design. Just something Marcin and I discussed very briefly,
without giving it more thought. One thing to remember is that the number
of statistics will keep growing over time. For now, you only need lease
number, but after that, additional metrics will be requested, some of
which can't be extracted from the lease manager. For example - a number
of total leases, number of reserved hosts, number of reserved hosts that
have active leases, number of malformed packets received, number of
packets that caused subnet selection failures etc.

I suppose that's all I can offer at this time. Statistics is something
that we definitely will want to implement. What would be very useful is
if you could think about what type of statistics you'd want. We won't be
able to implement them all immediately, but knowing what will be needed
eventually, will be helpful with the design decisions.

Ok, this is my last mail to kea-dev for the next 2,5 weeks. IETF meeting
is wrapping up today and I'm going on vacation.


More information about the kea-dev mailing list