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

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
extensibility. 
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
containing
only the arguments.  In other words, the arguments are segregated into a
single
container which can be passed around, free of any other than fellow
arguments.
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
ignored.
It also allows their content to be arbitrarily complex yet shields outer
level
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
command
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
pairs.  

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

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
setMaxSampleAge().
These two limits do not have to be mutually exclusive and using the same
method
name for both implies that the class enforces one limit or the other.

----------------------------------------------------------------------
Regarding Context class:

Context:

 Since Context is intended to implement the hierarchy:

    "Subnet[0].pool[1].assigned_addresses"

 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
design
 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
space. 
 Users would grasp this notion fairly well.  As to their being a
performance
 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
matter
 of selecting your beginning point in the hierarchy and invoking its
toJSON()
 method.

----------------------------------------------------------------------

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


Thomas





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