Agent architecture

The MyARM agent architecture is designed to be flexible, efficient and robust. Figure "MyARM overall architecture" gives an overview:

Figure: MyARM overall architecture

Figure: MyARM overall architecture legend

1. The ARM instrumented applications (C/C++, C#, Java and Python) uses the ARM 4.0 interfaces to measure ARM transactions
2. The MyARM agent implements the ARM 4.0 interfaces and is linked (dll or jar) against the instrumented application
   1. The MyARM agent implementation uses a datasink (backend) concept to store the measured ARM data. The following different kinds of datasinks can be used.

      file datasink

      The file datasink writes the measured ARM data to a file which will be collected by a myarmdaemon

      tcp datasink

      The tcp datasink writes the measured ARM data over a TCP/IP connection to a myarmdaemon

   2. The runtime configuration is used to change the behaviour of a running instrumented application. The runtime configuration is distributed to the instrumented application through a myarmdaemon process which receives runtime configuration data through a TCP/IP connection from the myarmadmin web application
   3. A handler uses runtime configurations to adopt the behaviour of the MyARM agent
   4. Filestorage component to write/read ARM data to/from a temporary file if the datasink is currently not able to store the data (TCP/IP connection down)
3. The myarmdaemon is configured
   1. to read in any ARM data files which were written by the file datasink of an instrumented application
   2. It will forward the ARM data to a connected myarmdaemon configured as a TCP server
   3. reading runtime configurations from disk when new configuration were stored by the TCP datasink
4. The myarmdaemon collects and aggregates ARM data received and provides interfaces for MyARM web applications
   1. receives runtime configuration data from the myarmadmin web application using a TCP/IP connection, stores the data into a local file and distributes the runtime configuration to connected myarmdaemon processes
   2. aggregates the received ARM data into so-called real time statistics (rts handler)
   3. stores any received ARM data depending on configuration
      1. into a database
      2. or in the filesystem based MyARM archive
5. Database support is provided for SQLite3, MySQL and MariaDB
6. Multiple database connections can be opened to the MySQL or MariaDB database for high transaction loads
7. MyARM archive SQLite3 database used to store ARM metadata (such as application and transaction names)
8. filesystem based MyARM archive to store ARM transaction measurements efficiently and a scalable search using by the myarmbrowser web application
9. CSV export TCP/IP interface to export ARM transaction measurements exactly once
10. MyARM HTTP server started by the myarmdaemon
    1. myarmbrowser for individual case analysis
    2. myarmrtsbrowser and myarmrtsmonitor for statistical analysis and 24 hours monitoring
    3. myarmadmin to configure the MyARM system globally
11. A standard web browser can be used to access all MyARM web applications
12. MyARM applications
    1. myarmmanager provides a simple graphical user interface to access all MyARM web applications
    2. Command line tools (such as myarmquery) are able to connect to the database directly (besides SQLite3 database)