Typical deployment

This sections outlines some typical deployment environments for an ARM instrumented distributed system. Here we assume that the distributed system consists out of

• 2 client hosts running a client application
• 1 server host with a web and an application server
• 2 database hosts each running a database server

The clients requests services from the application server through the web server. The application server will process the requests and will use the two database servers according to the type of request. Each box in the following diagram represents a host with the host name in parenthesis within our local domain "local":

Figure: Deployment overview

Within such an environment we recommend to setup a separate MyARM server which hosts the following applications:

• a MySQL (or MariaDB) database for storing the ARM measurements. Note: Within the Community Edition just use the SQLite database.
• MyARM running a myarmdaemon process with an enabled TCP server to receive measured ARM data through an TCP socket.
• a web server with FastCGI (MyARM Web Edition only) support to deploy the MyARM web applications (e.g. myarmbrowser, myarmrtsbrowser , myarmrtsmonitor , myarmadmin).

Administration or the help desk can analyse performance trends or a specific performance problem using the MyARM web front ends.

Using TCP datasink

Once MyARM is installed on each host the configuration needs to be adopted to work properly. The following diagram gives an overview of our deployment example with black arrows representing writing data flow and gray arrows representing a reading data flow:

Figure: Deployment with TCP configuration

As shown in the diagram we can divide the diagram into three different areas:

1. The "Application area" which needs the MyARM configuration how to write the measured ARM data into the destination database.
2. The "MyARM area" where the myarmdaemon with the TCP server, the MySQL SQL database and the web server for providing the MyARM web front ends are running. Note: myarmadmin is used to administrate the MyARM infrastructure and is not taken into account here but shown for the sake of completeness.
3. The "Analyse area" where some web browsers are used to analyse the measured performance and response time data.

We start to configure the MyARM installation within the "MyARM area":

• To configure MyARM properly template configuration files exists in the directory ${MYARM_ROOT}/conf/templates. Since we want to use the myarmdaemon with a TCP server and a MySQL database we use the "tcp_mysql.conf" by creating a symbolic link (or by copying):

  ln -s ${MYARM_ROOT}/conf/templates/tcp_mysql.conf \
        ${MYARM_ROOT}/conf/myarm.conf

  To adopt this configuration template a configuration file named "user.conf" is used within the configuration ${MYARM_ROOT}/conf directory. In this file we will enter our changes which will override the MyARM default configuration properties.

• The myarmdaemon writes any received data into the "MySQL" database. Therefore we need to setup the database user "myarm" and password. The default configuration is to use "localhost" for connecting to the database thus that's all:

  1: db_mysql.user = myarm
  2: db_mysql.password = "dbpasswd"

  Configuration: Daemon database configuration
• On the "myarm.local" host the myarmdaemon is running a TCP server thus we need to configure the TCP part first. We define the host and port where the daemon is listening for new data connections (line one and two) and finally we limit the number of concurrent client connections to ten (line three):

  1: daemon.tcp.host = myarm.local
  2: daemon.tcp.port = 5557
  3: daemon.tcp.max_clients = 10
  

  Configuration: Daemon TCP configuration
• For configuring the MyARM web front ends two different options exist. First configuring a standalone HTTP server and FastCGI integration option to embed the MyARM web front ends into an existing web server infrastructure. Please read the web deployment section for details.

So finally our "user.conf" for the host in the "MyARM area" looks as follows:

daemon.tcp.host = myarm.local
daemon.tcp.port = 5557
daemon.tcp.max_clients = 10
db_mysql.user = myarm
db_mysql.password = "dbpasswd"

Now we need to configure the MyARM installations within the "Application area":

• To configure MyARM properly we use another template configuration file named "tcp.conf" by creating a symbolic link:

  ln -s ${MYARM_ROOT}/conf/templates/tcp.conf \
        ${MYARM_ROOT}/conf/myarm.conf
  

• Next we need to tell MyARM where the myarmdaemon with the TCP server is listening for new connections by creating the new file "user.conf" within the configuration ${MYARM_ROOT}/conf directory:

  1: sink_tcp.host = myarm.local
  2: sink_tcp.port = 5557
  

  Configuration: Client TCP configuration

  For further configuration properties read the TCP datasink section.

sink_tcp.host = myarm.local
sink_tcp.port = 5557

For the "Analyse area" no additional configuration is needed. Depending on the web deployment you used the different MyARM web application can be reached with the following URLs:

• Standalone HTTP server
  • myarmbrowser: http://myarm.local:8080
  • myarmadmin: http://myarm.local:8081
  • myarmrtsbrowser: http://myarm.local:8082
  • myarmrtsmonitor: http://myarm.local:8083
• FastCGI integration
  • myarmbrowser: http://myarm.local/fcgi-bin/myarmbrowser.fcgi
  • myarmadmin: http://myarm.local/fcgi-bin/myarmadmin.fcgi
  • myarmrtsbrowser: http://myarm.local/fcgi-bin/myarmrtsbrowser.fcgi
  • myarmrtsmonitor: http://myarm.local/fcgi-bin/myarmrtsmonitor.fcgi

Using file and TCP datasink

In the previous section we configured the MyARM agent to use directly a TCP connection to the myarmdaemon running on the "myarm.local". In some circumstances it is not wanted that each ARM instrumented application connects to a TCP server. For example if different command line tools are instrumented and are executed within a batch job its not a good idea to connect to the TCP server each time a batch command has some ARM measurements.

In such environments MyARM provides the file datasink to write ARM measurements to local hard disk instead of sending the data through a TCP connection. The myarmdaemon is used to collect these files on the "localhost" and sends the data to the myarmdaemon running on "myarm.local" using only one TCP connection:

Figure: Deployment with file and TCP configuration

• To configure MyARM in such a way we use the "file_tcp.conf" by creating a symbolic link:

  ln -s ${MYARM_ROOT}/conf/templates/file_tcp.conf \
        ${MYARM_ROOT}/conf/myarm.conf

• Now you have to make sure that the myarmdaemon is running on each application host otherwise the data is only stored onto local hard drive but not forwarded to the myarmdaemon running on "myarm.local".

  Under Windows you can install the myarmdaemon as a Windows service and under Linux the myarmdaemon.sh script can be used in the appropriate init systems.

  Since we already configured the TCP part we can just use the "user.conf" from the previous section.

• The file datasink has several configuration options to ensure that the local hard drive will have enough space left and to fine tune the forwarding of measured data.