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/
