httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harrie Hazewinkel <har...@covalent.net>
Subject Re: [PATCH] mgmt_get_vars hook
Date Tue, 12 Jun 2001 19:18:07 GMT
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.

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.
> 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].

> 
> 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.

> >
> > If these 2 questions are answered YES. It will create a problem
> > for management applications which are not HTTP-request based
> > and this solution will not work with SNMP.
> >
> what about this scenario..
> 
> I am running a SNMP agent on the machine
> it has a 'GET' request for a OID.
> IF it is part of the server it would run the hook, otherwise it could grab the data via
HTTP
> and convert it to SNMP (ugly, but doable)

Indeed very ugly.

> 
> 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.

> 
> 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.


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.)

3) Maybe the module number can provide the highest level and in
each module the module needs to do this themselves.

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: http://www.lisanza.net/

Mime
View raw message