httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <>
Subject RE: [PATCH] mgmt_get_vars hook
Date Tue, 12 Jun 2001 19:54:48 GMT

> -----Original Message-----
> From: Harrie Hazewinkel []
> Sent: Tuesday, June 12, 2001 12:18 PM
> To:
> Subject: Re: [PATCH] mgmt_get_vars hook
> Ian Holsman wrote:
> > > 1) Is the approach you have based upon handling a request??
> > > At the moment a request is handled you execute this hook??
> > 
> > YES
> Then this is not reall usefull where you don't have a request.
> FOr instance, SNMP has already a problem on how to figure
> out the protocol used for a server_rec, for instance HTTPS or HTTP.
> Maybe the port could give an indication, but what is it when
> the port is 8080.
> As soon an HTTP-request is being handled it know of course 
> the protocol.
> However, SNMP provides information not directly associated with the
> HTTP-request. It then has only the server_rec and needs to make
> an educated guess based on the port.
the parameters to the hook are a 'pool' to allocate memory from
a 'variable' to retrive info about
and a 'hash table' to store the results in.
It doesn't need a request rec structure present.

> If this hook is to provide/log the activity for management 
> purposes you could use the normal logging hook.
> > >
> > > 2) Can I only get management data via the new hook??
> > > I.E. do I always have to run thru this hook and get everything??
> > >
> > YES
> > and no
> > you can run the hook
> > mgmt_get_vars("scoreboard.process.request_count")
> > which would return a int.

this would be the toal request count (a summary)
so you wouldn't need to go down the next level.

> > mgmt_get_vars("scoreboard.process.request_count.*")
> > which would return a hash table with a entry for every 
> process/thread

> I beleive this string based approach is a huge overhead. If this
> is really what you want you need to provide it based on
> 'sysctl' which works via an array of integers. Array position
> determines a level and for instance int[1] provides more detail of
> int[0].
readability vs efficency.. 
we could go number based, but I don't think it is such a overhead.
unless you plan to call the hook every second
> > 
> > or
> > mgmt_get_vars("*")
> > would perform like a SNMP walk.
> This is not real usefull for an SNMP walk from the SNMP perspective.
> While doing a real SNMP walk on the SNMP agent you need each time the
> next managed object. Now you place a huge burden on the SNMP agent
> to first retrieve all data and then select the only one you need.
I'm not sure I follow here.
the variable names are organized in a tree.
so are MIBS.
providing the MIB and the variable names are the same tree structure

you would need to 1 call to the hook to get the data required.

snmpwalk tcp.tcpConnTable
would map to 
snmpwalk tcp.tcpConnTable.tcpConnEntry
would map to

the results of each hook call would come back in a hash
table (with embedded hash tables)
> > 
> > doing it via shared-mem outside of the server is a PITA,
> > as      1. the SNMP has to know the structure
> That is needed somehow any way. I beleive that the management
> modules who want make use of this need to know the specifics
> anyway. Otherwise, it makes no sense.
> SO, I don;t see this as a disadvantage.
> >         2. i would need to modify the SNMP agent if I want 
> to monitor
> >            something non-standard, or if I have a custom module
> You have to do that anyway, since you need to write a
> MIB module for it. You could make a very generic MIB module
> based on just a table where each row has a colunm of description
> and value. However, this is not real usefull to management 
> application.
> They need to know wy to much information which is not 
> possible to learn
> from a MIB module.
> So, I don't see this ad a disadvantage. Needs to be done anyway.

I as a module develpoer could write the hook, and supply a MIB with it.
the SNMP agent would a method of tranlatting the MIB OID into the variable name.

> > 
> > holding a global structure is also a pain
> >         1. pointers in shared mem don't work, so I couldn't 
> store pointers
> >            to functions to execute to get the info
> >         2. storing this is process-memory would be too much 
> of a resource drain
> >            as the structure would consume a bit of memory 
> for each process
> IMHO, these two point are not real a problem. That is an 
> implementation
> detail and maybe even depends on the kind of information you
> have.
> >         3. summary data couldn't be held, and would have to 
> be generated by the
> >            SNMP agent itself
> Needs to be done anyway, to provide things via a usefull MIB module.

here's the main argument.
My 'opinion' is that how a module does things should be kept to itself
If I want to change my internal structure I can do this without having
to change other parts of the system.
as long as I don't change the interface by which external things can get to the
information I'm cool.

> What I start beleiving is that this is somehow an apporach 
> with which we
> start getting on track. But this approach as is will not work well.
> 1) I believe that module which provide management data need to handle
> updates of it themselves. Meaning they need to/can use the standard
> hooks.
> 2) The management data registration needs to have a more integer
> array based apporach. Unfortenately, this will demand
> that there needs to be an authoritave assigment scheme.
> (like sysctl on FREEBSD, that each number can be represented
> by a name is something else.)
or just use a name.
> 3) Maybe the module number can provide the highest level and in
> each module the module needs to do this themselves.
yep.. but I wouldn't go with a number as there is no way to control
the main numbers unless apache has a 'registration' system where people
can get assigned a number.

> 4) I am not sure if predefined dataypes/structures are not better
> for this. A module then provides a specific structure or
> even a function that could return data.
> The management modules need to have then knowledge of what is 
> provided,
> but they need to know that anyway. Just having managemen data is
> not interesting, knowing what is is makes in management information.
> -- 
> address: Covalent Technologies, 645 Howard St, San Francisco, 
> CA - 94105
> phone: +1-415-536-5221                               
> fax:+1-415-536-5210
> personal website:

View raw message