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

Re: back-monitor API: monitor_subsys_t

> Hash: SHA1
> Hi,
> I'm looking over back-monitor's interface to get some more monitoring to
> back-ldap, mainly operation count, just like the one in
> cn=operations,cn=monitor and finishing the connection monitoring in
> ldap_back_monitor_conn_create.
> There is a part of the monitor API that is a bit unclear to me:
> In order to register an entry with register_entry(), one needs a
> monitor_subsys_t structure, but how to obtain one? Is it a
> back-monitor's job to appoint one or the monitored backend's?
> The only use of this structure outside back-monitor is back-ldap again,
> not relying on anyone when populating the structure, however a comment
> directly above that code reads: "set up the fake subsystem [...]", where
> the "fake" reads to me as "we shouldn't need one at all".
> I understand the monitoring in back-ldap is functionally a stub with the
> infrastructure *mostly* done, so maybe there was a rewrite of the
> relevant code planned? What else should I take into consideration and/or
> be looking into during my efforts?

Very quickly (sorry): I understand there is little if any public example
of dynamically adding contents to back-monitor; in fact, I mostly
developed custom, unpublished code.  Another note: the dynamic interface
of back-monitor was developed well ahead of back-config; it suffers from a
much poorer versatility.  For example, you can't define new subsystems,
and there might well be other so far overlooked issues related to
monitoring databases and overlays added and removed run-time using

In detail, in order to register an entry you either need a pointer to the
appropriate monitor_subsys_t structure, or you need to provide info about
how to locate it.  In practice, what one usually needs is
register_entry_parent(), which allows several ways to locate the parent
(and thus the subsystem): the base, scope and filter (much like a search).
 In those cases, the pointer to the subsys must be NULL.

With respect to back-ldap, as far as I remember, the infrastructure was
nearly entirely set up; what stopped me at that time was related to having
monitoring coexist with back-config.  Unfortunately I don't recall what
was the specific issue; since back-config evolved since then, those issues
may have well disappeared.