[kea-dev] Statistics design proposal for 0.9.2
sar at isc.org
Tue Apr 21 02:31:47 UTC 2015
I continue to have some concerns about the possible performance impact
of the design. But I agree that we should go forward with the current design
and get some experience with how the code performs and how people may
want to use it before trying to optimize it.
As with Marcin I had questions about the way the subnets were being named,
clearly stating in the document that the naming won’t change if a subnet is
added or removed might be useful.
In the description of data types the text shows keeping the packet received statistics
for the last 5 minutes. Later the text shows an example of the return with 3 instances
of the received-packets. This needs to be well documented, especially if we are
capable of processing some 5k requests / second. By default I would assume that
saying “save 5 minutes of packets” would get me say 300 instances (1 per second).
not potentially millions.
Should there be a way for the requestor to restrict what instances they get?
Continuing the example - I may want to be keeping the last 5 minutes of packets
received for some reason but most of the time will only want to get the current
number and if it is not what I expect then to look backwards and see when something
One area I’m unclear on is if the requestor can ask for some related group
of statistics - for example all the stats for a single context or all of the stats
for packet processing (packets received, packets sent, different types of packet
errors etc) - easily or if one would need to have a separate item in the request
for each of the desired stats.
In a cross between the performance issues and getting groups of statistics
I also wonder if we will eventually want to return something more like an array
or structure, something without the names and with the data all in the same
places. Again this is probably something we can defer for now, but we probably
don’t want to rule it out. (SNMP eventually needed to add the bulk command
in order to reduce the number of round trips it took to extract some tables.)
One item I don’t see is how the requestor determines the statistics that
are available. Is this something that you expect to be compiled in to the
requestor? or should there be a way for it to ask for the names of the various
objects (maybe the requestor can do a get-all?)
Following on that idea will there be a way for the requestor to determine what
the stat represents? Or is it assumed they know from something else such as
reading the documentation?
And I suppose that also bring up the question of if there is or should be some
sort of versioning information available. I can see a possible use for the version
of Kea, the stats collector, and the stats extraction protocol. As with the performance
discussion I’m not sure if any of those are truly useful and they may be something
we can defer.
More information about the kea-dev