[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Feature Request - 'cn={Databases,Backends,Connections},cn=Monitor'



>>>>>> "Pierangelo" == Pierangelo Masarati <ando@sys-net.it> writes:
>
>     Pierangelo> I don't think there's much more.  In fact,
>     Pierangelo> back-monitor is basically sitting there waiting for
> Pierangelo> input (e.g. sysadmin requests, possibly accompanied by
> Pierangelo> patches :).  Please file an ITS with a detailed
>     Pierangelo> description of what you'd like to see there; if you
> Pierangelo> only have a rough idea, we can discuss the topic.
>
> Oki. I see. I'll look at the code and see if there's ANYTHING I can
> do...
>
> Do you want each request as separate ITS' or do you want them all in one
> (I assume separate, but I thought I'd ask :)?

You may group issues according to their level of integration;
ven a single ITS, if you have a clear view, would be fine.

>
> Before I go dig the back-monitor code, is it POSSIBLE (just by changing
> that part of the code) to have a 'log' of connections, or does that
> have to be added elsewhere?

You mean a history of the connections?  At present, only a count
of the currently running ("Current") and of the total accepted
("Total") connections is available, plus details about each
current connection ("Connection X") in separate entries below
the "cn=Connections,cn=Monitor" branch are available.  An historical
log could be possible if we do not delete no longer available
connections from the cache.

> Is monitor backend writable (for the server,
> not by the user) or is all values gathered 'on the fly' when requested?

It depends on a case by case basis.  Some of the entries
aregenerated; some are cached (they're read only), some
are cached and selected attributes or attribute values
are only updated (e.g. the "cn=Current,cn=Time,cn=Monitor" entry)
some are client-writable ("cn=Log,cn=Monitor": by changing
the "managedInfo" attribute one can select the log level,
by combining the names of the desired levels).

>
> I looked at it very quickly, trying to understand the
> 'cn=Connection X,cn=Connections,cn=Monitor;description' entries, and it
> seemed to me that it's gathered on the fly...

Currently, it is.  It contains the overall info about the
connection in a synthetic string form, mostly for comatibility
with the previous implementation, plus some extra details
in separate attributes.  It could be extended, by splitting
the info in synthetic form in separate attributes, to ease
automatic info extraction, and entries could be cached, so that
only new connections need to be logged; however, this would
require to change connection code in order to generate the
entries when the connection is created, otherwise info would
be lost.  I considered it, but it would have created too many
dependecies between unrelated pieces of code, but it might be
worth for the purpose you suggest.  There are a few flags in
each monitor subtree that define if subentries of that subtree
are generated on the fly, need update or are basically static.
In any case, subtreegeneration/update is delegated to related
operations.

In the case you propose, e.g. add statistics to each database
entries, all you need to do is hack the update function for that
subtree (if any, otherwise add one) and change the values in the
entry according to previously gathered statistics.  This may
require changing the backend data as well, unless you can count
on common operations (e.g. each backend could be given an ABI
function that computes the number of entries, which, if present,
is used by back-monitor to update the related figure in the
database entries.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it