Documentation / Standard Edition / User Guide / Agent / Concepts


All MyARM supported ARM 4.0 language binding agents and analysis tools uses the following concepts.


The adaption of the MyARM agent to the current hard- and software environment is done using a set of configuration files. Each file contains name value pairs so-called config properties. For example setting the basic.time.use_utc property to true will instruct MyARM to show time information only in UTC.

basic.time.use_utc = true

For more and detailed information about the MyARM read the configuration chapter.

All MyARM agents and tools are using the MYARM_CONFIG_URL to get the configuration file.


The ARM standard is designed to transparently plugin into an instrumented application. Also in any circumstances the ARM agent should not interfere the application. The MyARM ARM agent uses log messages to report the current configuration, state changes, warnings and errors. The log messages can be written to different kinds of output media such as normal files, Windows event log or Unix syslog.

MyARM supports the following levels of log messages:

Error log messages to report errors
Warning log messages to report some unusal situations
Status log messages to report state changes within the ARM agent
Only informational messages
Logs the configuration used by the ARM agent

For more information read the section "Configuring Log facility".

ARM data buffer

During deployment of an instrumented application any measured and recorded ARM data is serialized and written to a so-called ARM data buffer. Therefore such an ARM data buffer can contain any kind of data like transaction response time measurements, log messages or even other kind of data like CPU utilization.

An ARM data buffer has a defined size in bytes which can be specified by a config property. Avoiding memory shortage due to high transaction measurements a maximum number of allocated ARM data buffers is defined. For more detailed information about configuring the ARM data buffer concept read the configuration properties section.


The datasink concept is used to transport and store any kind of measured and recorded ARM data in a constistent way. Datasinks within MyARM are plugins which are loaded during initilization phase according to the current configuration.

With this concept it is possible to use a chain of datasinks which will:

  1. store any measured data onto disk (filesink)
  2. read the measured data from the disk and send it to a central server using TCP/IP (tcpsink)
  3. finally storing the measured data into a MySQL database (mysqlsink).

For a detailed description of all available datasinks read section datasinks.


The datasource concept defines constistent interface to read in and manage measured and recorded ARM data stored in a database. Like datasinks they are implemented as plugins which are loaded during runtime. Each analysis tool uses this datasource concept to retrieve the measured ARM data from the database. A datasource exists for each supported database as described in section Databases.

File storage

The file storage concept is a sub-component of the MyARM agent which is used to read and write ARM data files. The reading and writing be used separately or combined within a program. It is used to efficiently store measured ARM data onto a hard disk and retrieve the data later from the hard disk within the following programs:

uses the file storage concept to collect all measured ARM data for the whole host. The myarmdaemon can be started as a Windows service or an Unix daemon process to collect all measured ARM data for the whole host.
myarmdaemon TCP server part
can use the file storage concept to save any data received through TCP/IP onto disk. Therefore it is secured that any incoming data is first stored onto local hard drive before further processing. The myarmdaemon itself will read in the stored ARM data if its configured datasink (database or another myarmdaemon accepting TCP data connections) is ready to accept data.
ARM agent
uses this concept to temporarily store ARM data if the configured datasink is currently not available (database or myarmdaemon are down). Later if the datasink resource is available again it will read in the ARM data and write it to the datasink.

For detailed information about configuring the file storage concept read the configuration properties section.

Resource watch dog

During deployment MyARM needs some resources (mainly memory) to operate correctly. The amount of memory needed depends highly on the number and frequency of transaction measurements. However MyARM should never interfere or to shorten the resources of the deployed application. Therefore MyARM provides various configuration properties to limit the amount of used resources. To monitor the used resouces by MyARM the resource watch dog (New since "1.3.x.4") provides a simple mechanism to log the used resources.

The resource watch dog can be separately configured for the following programs:

Runtime configuration

With the release 3.0 MyARM supports so-called runtime configuration. The runtime configuration can be created and managed by the myarmadmin web application and send to appropriate configured myarmdaemon processes.

The following runtime configurations can be used:

Real Time statistics (RTS)
defines transaction types to calculate statistics and to provide them in real time
Selective RunTime (SRT) configuration
defines transaction types to monitor current measurements and to discard or stop them after a defined period

Real time statistics

Real time statistics are used to monitor executed transactions within a production environment to get in overall picture of the performance and health of the whole system including end-to-end response times. Real time in this sence means that performance data is available 5 to 10 minutes after current time (presence). With this data just few minutes ago it is possible to react on hard or software failures very quickly!

To use the real time statistics MyARM needs to know which transactions are key performance indicators (KPI). Such a KPI can be directly derived from the ARM transaction definition by adding some important information. Within MyARM a key performance indicator is formed from the following data:

ARM transaction definition
is used to form the base data set for the key performance indicator. This transaction definition is defined by the application and therefore represents the applications typical character
Filter criteria
Besides the response time each ARM transaction measurement has several attributes associated. Therefore the following attributes can be used to form a specialized KPI for the given ARM transaction definition:
System address
defines the host or system the transaction was executed on. To monitor the performance on a specific system this filter criteria can be used.
within web environments each transaction measurement can be associated with the appropriate URI. Use this criteria to collect performance indicators for specific or groups of web applications.
a transaction measurement can be executed on behalf of an user. With this criteria a specific user can be monitored.
Context properties
a transaction measurement can have several context information associated with. For example within a load balancer the server name can be associated with the transaction measurement and be used as a KPI. Therefore different servers can be monitored simultanously.
Time interval
is used to aggregate all single measurements within this interval
Response time thresholds
are used to calculate a performance index to classify the performance of the transaction measurements. It is possible to define up to three thresholds:
Threshold 1
response times below this threshold are expected and judged to be good
Threshold 2
response times below this threshold are tolerated
Threshold 3
response times below this threshold are bad and response times above this threshold are inacceptable

To define these KPIs MyARM provides a web application to manage such information. For details read the myarmadmin chapter.

Selective runtime configuration

Selective runtime configuration is used to manage and control instrumented applications remotely. Appropriate configured myarmdaemon processes are listening for new runtime configuration connections from the myarmadmin web interface to receive new runtime configurations. Selective here means that currently the runtime configuration can only be managed by the myarmdaemon process and is not distributed to all instrumented applications using the TCP datasink. This feature will be implemented within MyARM 4.0.

The following type of runtime configuration are supported:

Transaction clearance
running transactions can be cleared (stopped by the agent and not by the application) or discarded if they are running to long. This can be achieved by configuring a clearance period for an ARM transaction definition.

For details how to configure these concepts please read the myarmadmin chapter.