httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <b...@wstoddard.com>
Subject Re: ARM4 module for Apache 2, any interest?
Date Wed, 11 Aug 2004 19:25:27 GMT
Paul Querna wrote:

> So, after a quick look at the website, it looks like ARM4 is some sort
> of SNMP on Steroids?
> 
> Also, the License is quite important for any possibility of donating any
> module to the ASF....  I think that needs to be pinned down before any
> discussion can really move forward.

The license for the module will bs ASL 2, no question. I need to check up on the license of
the ARM4 API 
header files.

> 
> Finally, can you explain what the ARM4 Module does in Apache 2?  
The ARM architecture is based on ARM 'clients' communicating with a centralized ARM instrumentation
data 
collection point. A piece of software that is ARM instrumented makes calls into an ARM client
to tell the ARM 
client things like when it was started, when it is stopped, when it handles an 'event' (and
HTTP request in 
our case), etc. mod_arm3.so ARM 4 instruments Apache 2. Consider the following configuration:

client --- Apache 2 ------ application_server ------ database

If you ARM instrument apache 2, application_server and database, it is possible for a centralized
ARM 
collection point (that is not an official term btw) to have an end-to-end view of the life
of an HTTP request 
flowing through the system, from the point it enters Apache 2 through the app server and database
and back 
again. You can see precisely where the transaction spends most of its time (or even if the
transaction 
completes properly or not).

So how does this work?  When Apache 2 is started, it registers its presence to an ARM client
with a call to 
the following ARM4 APIs:

arm_register_application(), arm_register_transaction() and arm_start_application(), all called
out of the 
child_init hook.

For each request that flows into the server, ARM APIs are called when the request is first
received (to note 
the time of the request and to assign a unique identifier or correlator to the request) and
when the request 
is finished (post_read_request and logger phase respectively in this particular implementation).
 The 
correlator is passed on to application_server via an HTTP header (ARM_CORRELATOR for now,
don't remember if I 
made this configurable or if it is part of the spec...).  If appliocation_server sees an ARM_CORRELATOR,
it 
can use this correlator on a call to its ARM client to register recipt of the request (and
time of recipt). 
database can do the same. The ARM clients can communicate the instrumentation data that they
collect to a 
central collection point where the data can be displayed. The ARM_CORRELATOR enables the ability
of doing the 
end-2-end view. ARM is not an architecture for controlling applications.

Hopefully that explanation gives you a rough feel for what ARM is all about.

The source code is not much more difficult than the explanation above (need ablity to stringify
correlators 
for addition to HTTP header fields, ability to load arbitrary arm4lib DSOs, etc. All pretty
much boilerplate 
stuff.).



Mime
View raw message