> -----Original Message-----
> From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 08, 2001 3:35 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Hooks for management reporting (was RE:New Hook)
>
>
> HI,
>
>
> At this very moment I am trying to understand what Ian really wants.
> This is what I understand of it.
>
> We need to have a hook that each time actively updates data.
> Meaning it will update at a certain point all data for all modules.
> I beleive this is not really the way to go. FIrst of all, when do you
> have a certain state change or something usefull to register.
> Most likely the time (or place in the code) will be for all modules
> different.
not exactly.
there are 2 needs:
1. to see what is going on right now, when I am fighting a fire
2. to see what has been going on over time, for capacity planning
for #1 I need to see EVERYTHING, as I have no idea what is the problem,
but the numbers will show me what is wrong, or where I should go looking
#2 I usually need to see more generic stuff, and will probably shove the
values in a database/rrd so I can make pretty reports
some of these numbers are grabbed from the scoreboard, others would be
from the error log hook, and others would come from custom modules we have written.
The things I want to report on are fairly static, and could be configured
in the config file, via module specific config params. There could be a level
parameter (like extended status) which I coul say only show this metric at
level X or greater.
>
> This is what I think is neccessary to serve the management processes/
> applications better. These could be either mod_status, mod_backhand,
> mod_xml_status (this is just status in XML format), SNMP whatever.
>
> There needs to be a generic ability for administration of
> key/value pair. Via this generic system every module may
> register a key/value pair. The Key would then be the item
> that uniquely identifies the registered value. The value
> itself needs to be of arbitrary sort, meaning it may be a
> structure. The value is then a pointer to the memory where
> the perticular module updates (if the module thinks is needed)
> the information in the value.
yep, that would work you could have status set this up 'post-config'
and have the module provide a callback for the more complex data-structures
(non int/char) which could convert it to a char* or maybe a array of ints/chars
>
> Why is the value part a pointer to some struct and
> not the real value. For instance, if a module just
> wants to maintain a counter that module can do,
> counter++, where counter is the varialbe updated.
> Otherwise, that module needs to dofirst a retrieval
> of the variable, then a counter++ and a store.
> On top of this I am maybe even thinking this needs to
> be a pointer to a function, because that way we
> can have always the same API towards the management
> data and changes within the management data are
> possible. The ap_mpm_show(...) is here an example of.
>
> Any management module, can if needed require the kay/value pair
> and have the information assoicated. How the management module
> will handle this and present it to the user is up to the module.
> Also the management module must have knowledge of the key/value pairs
> it needs for perticular information and how it is stored. Unfortenate,
> but I beleive we can not go really around this. If I use SNMP as an
> example, I can provide an SNMP-based access to the information
> in the scoreboard. However, the SNMP module needs to know the
> correct mapping from the structure representing the scoreboard into
> the managed objects of the MIB module.
it would need to know the mapping between the 'apache Key' and the OID in the mib.
maybe the above callback could be smart enough to do this (via a hash?)
this could make it so you have one key for the process table, which would
return multiple values for one key.
>
> For those who would say if it reagrds a structure we need
> to split this into multiple key/value pairs it would become
> way to quick a mess to maintain single values. The management
> module (if needed) needs to sort this out for itself, together
> with the module that registered it. For instance, I know
> that lots of management data in SNMP is or single value or
> row-based. Mod_status is equal, it present a table with rows
> containing information of the current activity.
>
> What type of hook do we really need it a management data registration
> hook and a a management process fork hook. I beleive this can be
> done within 1 single hook. That hook needs to be made just after the
> scoreboard is made. Although, one could argue that the creating of
> the scoreboard is also registration of management data.
>
> This hook is needed inside the MPM and I am thinking of
> something as followed.
>
> 1) Setup scoreboard
> 2) Execute hook: register management data/fork management processes.
> NOTE: not all management processes need to fork of a process.
> NOTE: The management data could be shared memory and registering
> the access to it.
> 3) normal MPM execution as implemented already.
>
> Why do I believe that the hook can be combined.
> The management processes do not relly need to register
> management date in the generic key/value pair mechanism.
> They can and need to maintain to manage it internal.
> Therefore, the management registration in the modules
> can be done first in the same hook after which the management
> processes can fork off.
>
> I would like to note that I use forking as an example, if
> a system would not support forking it may as well be a thread.
>
> Just as a side note I would like to mention that sometimes a push
> mechanism is needed for having, for instance, an SNMP notification
> (trap), you could use therefore the new error_log hook. SNMP
> notification are normally only used for exceptional situations and
> those (if SNMP not used) should also be logged in the error-log.
>
I wasn't think of something so complex when I thought of this
more of a way for modules to report on some key metrics
(like ad calls since start, unique users ) maybe limiting
the number of things a module reports on by passing it a value
but I think this method you described may lead to more interesting things
later on
..Ian
> Harrie
> --
> address: Covalent Technologies, 645 Howard St, San Francisco,
> CA - 94105
> phone: +1-415-536-5221
> fax:+1-415-536-5210
> personal website: http://www.lisanza.net/
>
