httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <I...@cnet.com>
Subject RE: Hooks for management reporting (was RE:New Hook)
Date Mon, 11 Jun 2001 04:36:34 GMT
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:harrie@lisanza.net]
> Sent: Sunday, June 10, 2001 11:35 AM
> To: new-httpd@apache.org
> 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/
> 


Mime
View raw message