[kea-dev] Requirements for statistics module in Kea
stephen at isc.org
Thu Apr 9 12:18:54 UTC 2015
On 09/04/15 06:48, Shawn Routhier wrote:
> In reading through the requirements and Marcin’s comments I have
> concerns about overloading the servers with work to collect and
> maintain the statistics. I would move all the requirements to process
> the data out of the server and into something else. This could be
> a process that is supplied with Kea or a process that a user creates.
> (It isn’t clear from the requirements if you are already thinking along
> these lines or were considering having the server do all the work itself.)
I agree with Shawn.
Taking requirement 16 as a specific example, I don't think that the
server should be able to report the combinations of existing metrics.
It should report the raw data (e.g. number of assigned addresses in a
pool, maximum size of the pool) and leave it to an external program to
do any calculations.
> I would also consider if it is worthwhile having an easy method to disable
> the actual gathering of the statistics. Optimally this could be enabled / disabled
> without a restart of the system. I may not normally care about the stats
> but want to be able to enable them if something seems to be broken.
> (This would work better for some counters than others - starting to count
> the number of DISCOVERS is pretty easy to understand, starting to count
> the number of addresses in use would be a lot less useful.)
I see there as being two types of data that can be reported: simple
counters, and data that requires significant calculation to obtain.
An example of a simple counter is something like the number of packets
received, which is incremented on the arrival of each packet. There is
no point in disabling this, as the test required not to increment the
counter would likely have more overhead than incrementing it.
In contrast, determining the number of leases in a pool may require more
overhead, in some cases perhaps examining the pool to count addresses in
use. These should be determined only when requested.
> For 4 we may want a specific incrementCounter(“foo”) if that provides a
> useful performance improvement. I imagine that the great bulk of the calls
> will be a simple increment and so I think it is probably worth optimizing that
I agree. The assumption I made above is that incrementing a simple
counter is a trivial operation, e.g. "++counter". The suggestion in
requirement 4 that the operation is of the form "addCounter("foo", 5)
implies the opposite. I'd suggest that the implementation include a
faster form to set/increment the counters (e.g. "addCounterFoo(5)") at
the expense of more complicated code to retrieve them. This may mean
that we may need to change the MUST in requirement 13 to a SHOULD.
More information about the kea-dev