mod_arm4 Application Response Measurement (ARM) 4.0 Instrumentation Base mod_arm4.c arm4_module 2.0 and 2.1(?)

This module makes the Apache HTTP Server version 2.0 aware of and a participant in ARM instrumentation flows. This module requires the services of an ARM agent library. http://www.opengroup.org/tech/management/arm/

 ArmLoadLibrary Sets the path to the ARM4 agent shared library. ArmLoadLibrary file-path ArmLoadLibrary libarm4 (.dll on windows, .a on AIX, .so everywhere else) server config

The ArmLoadLibrary can be used to configure mod_arm4 to use a specific ARM4 agent library. File-path is the path to the ARM4 agent library. q: abs or relative path?

Example: ArmLoadLibrary libewlmarm4.so ArmLoadLibrary ewlmarm4.dll ArmTransactionName Sets the transaction name registered with the ARM agent ArmTransactionName string ArmTransactionName "HTTP Request" server config

The ArmTransactionName directive sets the name of the transaction registered to the ARM agent. (need more...)

Example: ArmTransactionName "HTTP" ArmApplicationName Sets the name of the application registered with the ARM4 agent ArmApplicationName string ArmApplicationName "Apache HTTP Server" server config

The directive is used to control the name of the application as registered with the ARM4 agent.

Example: ArmApplicationName "httpd" ArmInstrumentHandler Enables the arm_block/arm_unlock calls to be made across invocations of module handlers. ArmInstrumentHandler "on|off" ArmInstrumentHandler off server config

The ARM4 standard defines agent functions, arm_block() and arm_unblock() that can be called to record when a process is about to perform an 'out-of-process' operation (e.g., network i/o) and to record when that 'out-of-process' operation completes. Ideally, Apache HTTP Server handlers that go "out-of-process" would be instrumented to make use of the optional callbacks defined by mod_arm4, arm_ap_block_transaction() and arm_ap_unblock_transaction to record "out-of-process" events with the ARM4 agent.

Setting "ArmInstrumentHandler on" causes this module to call arm_block() and arm_unblock on behalf of a handler that is not instrumented. There are a couple of problems with using this directive as implemented. First, mod_arm4 has no knowledge if a handler really goes "out-of-process". Second, the arm_block() is called in the fixups hook and the arm_unblock is called in the logging hook, so it is relatively coarse grained. A lot of "in-process" cycles can be consumed between these two hooks which would be incorrectly attributed to the "out-of-process" activity.

Example: ArmInstrumentHandler on