[kea-dev] Fwd: Fwd: Re: Statistics design proposal for 0.9.2

Thomas Markwalder tmark at isc.org
Thu Apr 16 16:50:48 UTC 2015

-------- Forwarded Message --------
Subject: 	Fwd: Re: [kea-dev] Statistics design proposal for 0.9.2
Date: 	Thu, 16 Apr 2015 12:49:43 -0400
From: 	Thomas Markwalder <tmark at isc.org>
To: 	dhcp-team at isc.org <dhcp-team at isc.org>

-------- Forwarded Message --------
Subject: 	Re: [kea-dev] Statistics design proposal for 0.9.2
Date: 	Thu, 16 Apr 2015 12:25:13 -0400
From: 	Thomas Markwalder <tmark at isc.org>
To: 	Tomek Mrugalski <tomasz at isc.org>

On 4/14/15 9:18 AM, Tomek Mrugalski wrote:
> Hi all,
> One of the features planned for 0.9.2 are statistics. Here is the
> proposed design: http://kea.isc.org/wiki/StatsDesign.
> This design is not the most advanced or fully featured. It's a
> compromise between what we could do and what actually can do in the
> limited timeframe of 0.9.2 release.
> The basic concept is that the statistics are currently simple, but they
> can evolve over future releases. Whatever evolution path we'll choose,
> the API should remain stable, if possible.
> Please review and comment.
> Tomek
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
Review Comments Statistics Design:

I do think it is wise to keep a concurrent solution in our thinking.  At
least, we should be
careful not to do anything that would preclude it from being done in the

Marcin hit a point that I'm not sure has been addressed.  What should
StatsMgr do upon a
reconfiguration?  Dependent on what has changed a fair amount of any
existing statistics might
be obsolete.  Personally, I think it would be acceptable to flush the
statistics upon reconfiguration.
At least for 0.9.2.

Regarding Control Commands:

Since this is paving the way for the remote API ( I agree with this BTW),
I think we should alter the command structure so that we have both symmetry
between Stats API and the future remote command API, as well as
I propose the following structure for command requests:

    "command": "cmd-value",
    "args" : { "arg1" : "val1", "arg2" : 777, "arg3" : ....}

This makes the command arguments (or "parameters" if you prefer), a
named map
which the JSON parsing code will return as a distinct ElementPointer
only the arguments.  In other words, the arguments are segregated into a
container which can be passed around, free of any other than fellow
This eliminates any code that needs the arguments from having to know the
first element (the command) is something that needs to be skipped or
It also allows their content to be arbitrarily complex yet shields outer
processing.  Note, their presence can still be optional for commands
that have
no required arguments.

We may also come to find that "commands" have other values common to
execution such as "priority" or "user-id". In other words values that
have to
do with performing a command in general, not arguments used by a specific
command.  For example we might some day want something like this:

    "command": "some-command",
    "user-id" " "tmark",
    "priority" : 99,
    "args" : { "arg1" : "val1", "arg2" : 777, "arg3" : ....}

By structuring it as "command" and "args" now, we have room to flex in
the future.

Regarding the Observation class:

It occurs to me that this class is very similar to ValueStorage template
class in libdhcprsv.  The primary difference is that rather than storing
name-value pairs as ValueStorage does, these would store timestamp-value

With the current design it would be possible for a developer to mistakenly
add a duration or a double to a statistic intended to be an integer counter.
There's no explicit way to say this statistic is of a one data type or

The class also seems to be missing attributes for retaining maximum samples
or sample age, values set by setStorage() methods. 

The name setStorage() is something of a misnomer. The name sounds like
it would
set everything to zero or something.  In fact, rather than overload it,
I think it would
be clearer to have two distinct methods: setMaxSampleCount() and
These two limits do not have to be mutually exclusive and using the same
name for both implies that the class enforces one limit or the other.

Regarding Context class:


 Since Context is intended to implement the hierarchy:


 it would need data member(s) which uniquely identify it such as "group" or
 "group_type" (for "subnet", "pool"...) and then an identifier within
the group,
 to store the subnet_id or interface name.  From a DBA view if you prefer,
 Contexts have no place to store their primary key.

 Also Context should have a reflexive relationship to model the fact that
 "A Context may 0 or more Contexts"

 Whether or not we implement hierarchical aspects in 0.9.2 or not, the
 should account for it now.

 As an aside, I would disagree with your description of Context as being
 invisible to the user and more of a performance optimization.  I think
it is
 useful to discuss statistics in terms of "contexts" within the user
 Users would grasp this notion fairly well.  As to their being a
 optimization, this could be true or false.  What is true is that they
 model/implement the statistics hierarchy. 


 Context and Observation ought to have toJSON (and possibly fromJSON)
 methods.  Each class is responsible for invoking that method on all its
 constituents. That way, extracting any portion of the statistics is a
 of selecting your beginning point in the hierarchy and invoking its


 Maybe you could tone down the colour on your diagram. That yellow is REALLY
 loud on the eyeballs. ;)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-dev/attachments/20150416/f1aaafb8/attachment.html>

More information about the kea-dev mailing list