[bind10-dev] Statistics features & tasks

[Shane Kerr]

Kambe-san,

On Fri, 2010-12-17 at 13:32 +0900, Naoki Kambe wrote:
> > 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.

Okay, understood. I trust your judgement here, especially since I don't
know anything about SNMP. ;)

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

Yes, I'm not sure either. Does anyone on the list have experience with
using the BIND 9 XML statistics to do some graphing or other
visualization?
 
> > 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.

I think I see. So a database here could be an in-memory cache-like
structure?

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

Like I said, I assume a separate process for each of these reporters.
Certainly having 3 methods of reporting information in a single process
seems like overloading it a bit too much, unless there is a very strong
reason to do that.

My thought was that the channel between the HTTP or SNMP reporters would
be the same as the channel between the bindctl and the stats daemon. But
you are correct, this model needs to be considered!

--
Shane