Ian Holsman wrote:
>
> > > 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
Doing an SNMP walk or retrieve some N number of variables
would require this being executed multiple tims within a small
timeframe.
> > >
> > > 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.
>
> eg.
> snmpwalk tcp.tcpConnTable
> would map to
> mgmt_get_vars("tcp.tcpConnTable.*")
> snmpwalk tcp.tcpConnTable.tcpConnEntry
> would map to
> mgmt_get_vars("tcp.tcpConnTable.tcpConnEntry.*")
>
> the results of each hook call would come back in a hash
> table (with embedded hash tables)
The way you present this you are correct. However, there is
one difference with arbitrary values of Apache and your
TCP example. The TCP example has already a TCP-MIB module
defined for it. So you could create the mapping straight
forward. For arbitrary Apache variables there is no
MIB standardized for it not to say even defined.
Thus, there is not way one can define up front how this
needs to be mapped in a MIB used in an SNMP agent.
> > 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.
Thus, the SNMP portion already needs to have detailed knowledge of
the management data stored.
> >
> > 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.
I agree on the concept, but maybe less on the implementation.
I would rather see something like the ap_mpm_show.
If a certain variable does not exist it returns some error code
AP_NOT_IMPLEMENTED.
Then together with a specific group of detailed information you
register the function on how to retrieve this information.
>
> >
> >
> > 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.
This is the problem with the approach. But when human readable names
are used you can have the same conflict some day. There needs to
be some mechanism to register the numbers or the names.
This is maybe a task/possibility the ASF should provide.
(Thinking here like the lines of an IANA as used in the Internet).
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/
