-----BEGIN PGP SIGNED MESSAGE----- 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?
- -- Ondrej Kuznik
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Ondrej Kuznik wrote:
-----BEGIN PGP SIGNED MESSAGE----- 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".
The backend in question creates the monitor_subsys_t and gives it to back-monitor. The "fake subsystem" is a container entry; the actual monitored connections would report their status in individual child entries of that fake entry.
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?
What you see is what you get. I don't believe Ando has any time to work on this at the moment so there's nothing else planned.
Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7l9F0ACgkQ9GWxeeH+cXuehwCglecsXz589XJq7g0ciHRstplp sNcAnA6DnU/elucCWUlOMF0mORVyvqLm =2C+Q -----END PGP SIGNATURE-----
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
-----BEGIN PGP SIGNED MESSAGE----- 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 back-config.
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.
p.
-
Howard Chu -
masaratiļ¼ aero.polimi.it -
Ondrej Kuznik