[bind10-dev] Statistics features & tasks

[Naoki Kambe]

Hello,

Can I add some minor comments?

From: Shane Kerr <shane at isc.org>
Subject: [bind10-dev] Statistics features & tasks
Date: Thu, 16 Dec 2010 23:52:52 +0100

> First, we have the the features with a suggested ordering:
> 
>   High
>       * Extend collection of statistics from Auth
>       * HTTP/XML statistics reporting in BIND 9 style
>       * Add collection of statistics from Recursor
>       * Add collection of statistics from Xfrin/Xfrout
>       * Add/extend collection of statistics from such modules
>         - Boss
>         - Msgq
>         - Cfgmgr
>       * SNMP statistics reporting
>   Low
This High/Low is preference level for me, not complexity, but I think
implementing SNMP reporting into the stats daemon is very complex.

> 
> I think this matches my own preferences, although perhaps Larissa has
> other feelings.
> 
> A few new features were suggested:
> 
>  * Adopting visual graph drawing including third parties
This is like a MRTG. Integrating MRTG with SNMP is very easy.  But I
don't know what the best drawer can integrate with XML reporting.

> 
> I'm not exactly sure what the extend of this is. Is the idea to provide
> data in a format that specific 3rd party visualization tools can use?
> I'm not opposed to this in principle, although this will probably be
> "contrib"-style additions rather than core BIND.
> 
>  * Adopting statistics storage which is stored the data once
>    calculated by stats daemon
>    (It's like SQLlite or in-memory DB?)
> 
> The idea here is that the statistics will remain across reboots? That
> makes sense to me, assuming that is the idea.
I think this is a discussion point. Whether across reboot or not,
should the stats daemon calculate same data every time other modules
request stats? The calculated date is once stored into a DB, the stats
can easily extract the data from it, so it doesn't need to calculate
twice.

> 
>  * Management of statistics items
>    (It's currently defined in 'config_data' of the stats spec file.)
> 
> Okay, this is also important. Note that I'll be posting a version of
> Jerry Scharf's work on the BIND 10 command tool soon, which should help
> define how this will work. (Don't be scared, it's good stuff.)
OK. I'm looking forward to it.

> 
> 
> Moving on from the features to the task list:
> 
>   Task related to Stats:
>     - Overhauling the current design of the stats daemon for implement
>       HTTP/XML reporting
> 
> I think we need to discuss this. I assumed that HTTP/XML reporting was
> to be done by a separate process. That way if you don't want HTTP/XML
> reporting you don't have to run the code at all, plus any errors in the
> code won't affect other statistics reporting, and so on. These are all
> of the usual reasons for using separate processes for different
> functionality.
> 
> If the redesign is intended to support HTTP/XML functionality in a
> separate task then that is fine. If the redesign is meant to include
> this in the statistics collection daemon, then I'd like to know the
> motivations. 
In the current via-bindctl version, one process do both collecting and
reporting. If we adopt two process model, we need to consider how two
separate processes, for example collector and HTTP/SNMP reporter,
share the statistics data.

Thanks,
Naoki Kambe

> 
>   Tasks related to Auth (after #347):
>     - Merge IntervalTimer into lib/asiolink
>     - Definition of auth statistics to be tracked
>     - Review of definition of auth statistics to be tracked
>     - Code for configurable interval of submitting statistics via Cmdctl
>     - Review of code for configurable interval of submitting statistics
>     - Code for parsing response from statistics module
>     - Review of code for parsing response from statistics module
>     - Design for reducing performance overhead of auth statistics
>     - Review of design for reducing performance overhead of auth
> statistics
>     - Code for reducing performance overhead of auth statistics
>     - Review of code for reducing performance overhead of auth
> statistics
> 
> These other tasks all make sense to me. :)
> 
> --
> Shane 
> 
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev
>