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.
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:
Finally, can you explain what the ARM4 Module does in Apache 2?
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.).
