Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Pool usage monitoring in Kea ? (Chaigneau, Nicolas)
2. Re: Pool usage monitoring in Kea ? (Tomek Mrugalski)
----------------------------------------------------------------------
Message: 1
Date: Fri, 14 Nov 2014 13:43:29 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] Pool usage monitoring in Kea ?
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84143cd...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="utf-8"
Hello,
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.
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 ?
Or any other suggestion on how to achieve this would be very welcome :)
Regards,
Nicolas.
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
------------------------------
Message: 2
Date: Fri, 14 Nov 2014 08:01:03 -1000
From: Tomek Mrugalski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [kea-dev] Pool usage monitoring in Kea ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
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.
Cheers,
Tomek
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 8, Issue 4
*************************************
