how about this prototype?
it registers a 'test' hook which generates somes values,
I envison that this would be similliar to how the this would work
for the 'get/walk' type commands
(the actually hook code is ugly, but it is there for demonstration only)
..Ian
> -----Original Message-----
> From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, June 10, 2001 11:35 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Hooks for management reporting (was RE:New Hook)
>
>
> Ian Holsman wrote:
> [snip]
> >
> > 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
>
> If you fight a fire there is some situation that creates a problem.
> In normal live you call the Fire Department and Apache needs to
> log this in the log file. Now with the new hook, you can make your
> management module act upon the logged message.
>
> >
> > #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
>
> IMHO, making pretty reports is part of the management application and
> should not be done on an operational system. The only thing you need
> is enough information to create the report.
>
> >
> > 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.
>
> As is done now already. IMHO, we only need to create a more generic
> schema to have arbitrary modules register in a generic form access to
> management information.
>
>
> > >
> > > 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
>
> Although, this also depends on the MPM and maybe you want to make this
> information persistent.
>
> [snip]
> >
> > 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.
>
> Indeed the management module needs to know what information is behind
> which 'key'. However, I don't think we can go that far of
> making generic
> mappings to OIDs for a MIB module. Unless, Apache is willing to create
> standardized MIB modules. Which will not really, work if you want to
> create enterprise specific extensions.
>
> The only thing we need to decide is whether we want to have the
> interface
> acting upon data structures of functions. Or even a combination.
> Data structure have the problem that they need versioning if we later
> change the structure and want to havebinary compatibility
> with previous
> versions. Functions can handle this like the ap_mpm_show does. Return
> an error message and have the values in the parameters of the
> function.
> We need some combination if we want to have certain information in
> multiple instances (like tables).
>
>
> [snip]
> > >
> >
> > 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
>
> I hope so. From all the years I made the SNMP extensions I believe
> having a generic access to have access to generic management
> information
> of
> an Apache module is a big step forward. Now having the error logging
> hook is another. However, I see a need in the logging hook to have
> aditional
> levels, such as, specialized NOTIFICATION generation or fault
> reporting
> mechanisms.
>
> >
> > ..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/
> > >
>
> --
> 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/
>
mod_mgmt.c
mod_mgmt.h
