Configuration

Contents / C/C++ Edition / User Guide / Appendix / Configuration

Introduction

The configuration of the MyARM agent library is done mainly through configuration files which contain so-called named value pairs or just called properties. Each property is specified in one or more lines of the file in the following form:

name = value

where at least the name and the sign character have to be in the first line. Line concatenation have to be introduced by a backslash character at the end of a line. The name can be structured hierarchically by separating name parts with dots:

agent.sink.name = db_mysql
Configuration: Assignment

This example assigns the value of db_mysql to the property name agent.sink.name which consists of the three parts agent, sink and name. One use of these hierarchical names is to unify the configuration of one component within the system by it's first name part. In the above example the first name part is agent which means its a property of the agent library component of the MyARM system. The second name part sink specifies the sub-component and the third part name specifies the property of the sub-component. This configuration line configures the datasink name db_mysql to be used for the datasink of the MyARM agent.

A value can also refer to an environment variable which has to be enclosed by braces and prefixed by a dollar sign: ${VAR}. This gives you powerful possibilities in writing configuration files. For example you can write user independent configuration files.

agent.log.file = ${TMPDIR}/agent.log
Configuration: User-specific

To make configuration tasks easier, MyARM has the ability to include other configuration files. Just add a line

include filename
Configuration: Includes

in a configuration file and the file with the name filename within the configuration directory is included. The template configuration files makes use of the include mechanism.

Configuration files

There are three possibilities to specify a configuration file for a MyARM tool or an ARM instrumented application using MyARM. The first possibility overrides configuration settings in the following ones, etc.

  1. specifying a configuration file through command line options: -cf conf_file or --conf-file conf_file. This is only available for MyARM tools. The ARM standard defines no mechansim for accessing command line options. Therefore, it is not possible to configure an ARM instrumented application using this technique.
  2. specifying a configuration source through the $MYARM_CONFIG_URL environment variable. See section "Environment".
  3. providing the .myarmrc file in the $HOME directory of the current user.

User configuration file

MyARM provides a mechanism for user-specific configuration of MyARM. If the file user.conf exists in the current configuration directory of MyARM, it is loaded after all other configuration files. Each configuration property in this file will overwrite a previously loaded configuration property. Therefore, the user can place any configuration property in the file which should be different from the MyARM standard configuration.

Provided configuration files

By default MyARM provides ready-to-run configuration files for the all components. Thus all you need to do is to select your favourite configuration file from the templates directory and to change the values to your needs by overriding these values within the user.conf file.

Template configuration files

These template configuration files are the anchor to the MyARM configuration system and should be used with the setup.sh script or used with the MYARM_CONFIG_URL environment variable. They are located in the $MYARM_ROOT/conf/templates directory.

Under Unix-like systems a symbolic link from $MYARM_ROOT/conf/<conffile> to the $MYARM_ROOT/conf/templates/<conffile> configuration file is created automatically with the setup.sh script.

file_mysql.conf
Main configuration file for using the myarmdaemon process to collect data from the filestorage directory of instrumented applications and to store the ARM data within a MySQL database.
file_sqlite3.conf
Main configuration file for using the myarmdaemon process to collect ARM data from the filestorage directory of instrumented applications and to store the ARM data within a SQLite3 database.
mysql.conf
Main configuration file for using MyARM with a MySQL database without a myarmdaemon. Note this configuration will use the database directly from your instrumented application.
sqlite3.conf
Main configuration file for using MyARM with a SQLite3 database without a myarmdaemon. Note this configuration will use the database directly from your instrumented application.
tcp.conf
Main configuration file used by instrumented applications to forward collected ARM data to the myarmdaemon using the tcp datasink.
tcp_archive.conf
Main configuration file used by an instrumented application which uses a tcp datasink and the appropriate myarmdaemon stores the data into an archive datasink.
tcp_daemon_archive.conf
Main configuration file used by the myarmdaemon process to collect ARM data from instrumented applications by using the tcp datasink to store collected ARM data into MyARM binary files.
tcp_mysql.conf
Main configuration file for using the myarmdaemon process to collect ARM data from instrumented applications and to store the ARM data within a MySQL database.
tcp_sqlite3.conf
Main configuration file for using the myarmdaemon process to collect ARM data from instrumented applications by using the tcp datasink and to store the ARM data within a SQLite3 database.
Main configuration file

The main configuration file includes all supported configuration properties with their default values. Thus this is the place to look for a configuration property and to copy it to the user.conf file and changing its value. That's all.

Configuring components

Currently, the following components can be configured using properties where the base prefix is specified in parentheses:

Configuring basic attributes

Some properties are subject to all MyARM components and therefore can be configured in the basic section of the MyARM configuration. The following basic properties are available:

basic.usage
The basic usage property is used to specify the general usage of the MyARM agent. Depending on the following usage value, the appropriate configuration properties set meaningful values (see configuration properties below):
min
Minimum agent usage can be used for few (1-100) measurements per second. Uses the minimum value of the properties listed below.
normal
Normal agent usage can be used for about 100 up to 1000 measurements per second. Uses the default value of the properties listed below.
high
High agent usage can be used for about 1000 to 5000 measurements per second. Uses half of the maximum value of the properties listed below.
max
Maximum agent usage can be used for about 5000 to 100000 measurements per second. Uses the the maximum value of the properties listed below.

Note that the agent can handle such high numbers of measurements per second, but the underlying datasink needs to handle also such a high measurement volume. So this configuration is able to handle very high measurement peaks!

user
The user is responsible for setting all configuration properties listed below.

Configuration properties directly set by the basic.usage property (if not using user):

basic.time.use_utc
this boolean property is used to switch display of times between UTC (true) and local time (false).

Default is false.

basic.time.format (New since "4.0.x.0")
specifies the format pattern to use for displaying time values. See "Configuring time formats" section for details.

Default is HH:MM:SS.ZZZ.

basic.time.date.format
specifies the format pattern to use for displaying date values. See "Configuring date formats" section for details.

Default is DD.MM.YY.

Archive configuration properties

basic.archive.enable
Boolean which indicates if MyARM uses the archive concept to store measured ARM data (true) or not (false).

Default is false.

This property is normally set by a template configuration file. For example the tcp_archive.conf template file contains the following lines:

# set sink for transporting ARM data to the myarmdaemon
agent.sink.name = sink_tcp
# only ARM instrumented applications are allowed in this config
# thus disable daemon
daemon.disabled = true
# no database in the config thus disable tools
tools.disabled = true
# global property to allow any part of MyARM to check if archive
# is enabled or not
basic.archive.enable = true
# MyARM - include main (all) configuration sections                     #
include main.conf
Configuration: TCP Archive template example
basic.archive.directory
Final root archive directory for the storage of MyARM data files. This directory is used by the myarmarchive tool and the myarmdaemon archive component to read data from.

Default is ${MYARM_VARLIB_DIR}/archive/final/.

basic.archive.transaction.filepattern
File pattern (including directories) for selecting the appropriate file for transaction measurements.

Default is transactions/$m/$s/%Y%m%d_%H%M%S_tran.

The following format options are supported:

$m
is replaced by a string defining two directories with timestamps in seconds since epoch (1.1.1970). The first directory represents the seconds for each day at midnight (beginning of the day) and the second directory represents the beginning of each minute within the day of the first directory. For example the timestamp 4th december 2017, 16:12:00 will create the folling two directories: 1512345600/1512403920.
$s
is replaced by the appropriate system address
$a
is replaced by the appropriate application name
%Y
is replaced by the year of the start timestamp of the transaction
%m
is replaced by the month of the start timestamp of the transaction
%d
is replaced by the day of the start timestamp of the transaction
%H
is replaced by the hour of the start timestamp of the transaction
%M
is replaced by the minute of the start timestamp of the transaction
%S
is replaced by the second of the start timestamp of the transaction
${ENV}
is replaced by the contents of the ENV environment variable
basic.archive.definition.filepattern
File pattern (including directories) for selecting the appropriate file for ARM definition data.

Default is definitions/$s_defs.

The following format options are supported:

$s
is replaced by the appropriate system address
$a
is replaced by the appropriate application name
${ENV}
is replaced by the contents of the ENV environment variable
basic.archive.threshold.enable
Boolean which indicates if MyARM should monitor transactions which exceed configured thresholds (true) or not (false).

Default is false.

If this option is turned on, thresholds for certain transaction definitions can be activated within the myarmdaemon by using the appropriate myarmdaemon command.

basic.archive.threshold.filepattern
File pattern (including directories) for selecting the appropriate file for threshold data.

Default is thresholds/thresholds_%Y%m%d%H/%M.

The following format options are supported:

%Y
is replaced by the year of the start timestamp of the transaction
%m
is replaced by the month of the start timestamp of the transaction
%d
is replaced by the day of the start timestamp of the transaction
%H
is replaced by the hour of the start timestamp of the transaction
%M
is replaced by the minute of the start timestamp of the transaction
%S
is replaced by the second of the start timestamp of the transaction
${ENV}
is replaced by the contents of the ENV environment variable
basic.archive.database.url
Specifies the database connection parameters using the URL syntax (including host, user and optional password). See Database URL notation for details.

Default is mysql://myarm@localhost:3306/?connections=4.

basic.archive.database.export.basename
Specifies the base name of database instances used by the myarmdaemon archive component to export matching transactions from the archive into the configured database (basic.archive.database.url). Each export will use basename as the prefix plus a given name to create a new database instance.

Default is MyARMIncidients_.

basic.archive.database.threshold.name
Specifies the database instance name to be used for storing threshold data within the database. This property is only used if basic.archive.threshold.enable is set to true.

Default is MyARMThresholds.

basic.archive.late_data
Defines the period in the past to define data as late. Any data which arrives later in the archive will not be forwarded to the Apache Spark connector.

Default is 15m (15 minutes), minimum is 1m (1 minute), maximum is 1h (1 hour).

basic.archive.cleanup.enable
If set to true old archive data will be deleted periodically.

Default is true.

basic.archive.cleanup.interval
Specifies the period to periodically delete old archive files.

Default is 1h (1 hour), minimum is 1m (1 minute), maximum is 24h (24 hours).

basic.archive.cleanup.keep_data
Specifies the period to keep archive data within the archive. Files older than current time minus this period will be deleted.

Default is 28d (28 days), minimum is 1d (1 day), maximum is 365d (365 days).

basic.archive.user.context.script
Specifies a shell script which is used by the myarmbrowser to provide context specific archive queries.

Default is "browser" (empty string).

The script needs to support at least the --list-attributes option to return a list of available options. Each supported option is specified by by a comma separated tuple of Command-option, Name, a Regular-Expression matching a valid input of the attribute and a Description. Each entry can be quouted with double-quotes to include a comma as well. Here is an example:

# command-option, name, reg-exp, description
--user=,User,^.+ .+$,"Enter username (forename, surname or fore- and surname)"
--email=,Email address,^.+@.+\..+$,Enter a valid email address

ARM data buffer configuration properties

basic.armdata.buffer.size
various MyARM components are collecting ARM data into a memory buffer before further processing. The buffer size for this purpose can be configured using this property. By default this buffer is 16384 bytes of size which is also the minimum value for this property. The maximum size if 512KB.
basic.armdata.buffer.pool.size
number of ARM data buffers to pre-allocate during initialization of MyARM.

Default is 32, Minimum is 8, Maximum is defined by the basic.armdata.buffer.pool.max

basic.armdata.buffer.pool.max
maximum number of ARM data buffers MyARM will allocate. If this limit is reached, any data which should be written to an ARM data buffer is dropped and appropriate dropped counters are increased.

Default is 512, Minimum is 256, Maximum is 1024.

File storage configuration properties

The following configuration properties belongs to the file storage reader part:

basic.filestorage.reader.directory
defines the directory to scan for new ARM data files.

Default directory is ${MYARM_VARLIB_DIR}/myarmfiles.

basic.filestorage.reader.directory.scan.period
defines the number of seconds to scan the directory for new files.

Default is 5s (5 seconds), minimum is 1s (1 second), maximum is 5m (5 minutes).

basic.filestorage.reader.directory.scan.keep_corrupt
boolean which defines if corrupted ARM data files should be kept or not. If kept the file is renamed by adding the suffix .corrupt.

Default is true.

The following configuration properties belongs to the file storage writer part:

basic.filestorage.writer.workfile
specifies the complete filename (including directory names) for the work file. An unique suffix will be appended for each running process. The ARM data is written to this file and when its closed it is moved to the configured file storage reader directory (basic.filestorage.reader.directory).

Default is ${MYARM_VARLIB_DIR}/myarmfile.data.

basic.filestorage.writer.rolling.seconds
specifies the number of seconds after which a new work file will be used. The old work file will be moved to the configured directory.

Default is 60s seconds.

basic.filestorage.writer.rolling.size
specifies the maximal size in bytes of the work file. If the work file gets bigger a new work file is opened and the old work file is moved to the configured directory.

Default is 128KiB (128 kilobytes).

basic.filestorage.writer.diskusage.max_used
specifies the maximal size in bytes of all ARM data files in the file storage reader directory (basic.filestorage.reader.directory). If this limit is reached any new ARM data files will be dropped and an error will be reported.

Default is 100MiB (100 megabytes).

basic.filestorage.writer.diskusage.min_free
specifies the minimal free size in bytes of the file system the file storage reader directory (basic.filestorage.reader.directory) resides. If this limit is reached any new ARM data files will be dropped and an error will be reported.

Default is 200MiB (200 megabytes).

Runtime configuration properties

basic.runtime.config (New since "4.0.x.0")
defines the local absolute filename to be used for storing and reading the runtime configuration.

Default is ${MYARM_VARLIB_DIR}/runtime.cfg.

basic.runtime.config.period (New since "4.0.x.0")
defines the number of seconds to check for a new runtime configuration stored in the basic.runtime.config file.

Default is 5m (5 minutes), minimum is 1m (1 minute), maximum is 1h (1 hour).

basic.runtime.config.client.host (New since "4.0.x.0")
defines the host from which new runtime configuration connections are accepted. This is the host or IP address where the myarmadmin web application server part runs on.

Default is localhost.

basic.runtime.config.port (New since "4.0.x.0")
defines the port to listen for new runtime configuration connections.

Default is 5577.

Configuring the ARM agent

The behaviour of MyARM can be changed by the following agent properties. Note: not all properties are used for the different language binding agents. See the binding information for each property.

agent.correlator.add_user
can be set to yes or no and, if enabled the ARM agent adds a passed user identity to the generated correlator. This user identity within the correlator is afterwards used by sub-transactions and starts the sub-transactions on behalf of this user. Note: This will override the user identity passed with the standard ARM 4.0 API.

Bindings: arm40c, arm40java, arm40c#.

agent.disabled
with this boolean property the complete MyARM agent can be disabled.

Default is false.

Bindings: arm40c, arm40java, arm40c#.

agent.flush.period
defines the number of seconds after which all cached ARM data are written to the configured backend.

The default is 10s (10 seconds), minimum is 1s (1 second), maximum is 5m (5 minutes).

Bindings: arm40c, arm40java, arm40c#.

agent.api.log.error
if this boolean property is set to true, any invalid parameters passed through the ARM API are logged.

Default is false.

Bindings: arm40c, arm40java, arm40c#.

agent.api.log.warning
if this boolean property is set to true, any warnings regarding ARM 4.0 standard compliance are logged.

Default is false.

Bindings: arm40c, arm40java, arm40c#.

agent.sink.name
defines the name of the datasink to use. See "MySQL configuration example".

Bindings: arm40c, arm40java, arm40c#.

agent.transaction.pool.size
number of pre-allocated transaction instances for the transaction pool. Increase this value if high frequency transaction measurement is expected. When the instrumented application stops or the resource watchdog concept is enabled, a short message is written to the log file which reports the number of used transaction instances. With this information, it is possible to adjust the initial transaction pool size so that no memory allocation is needed during runtime.

Default is 128. Minimum is 32, Maximum is defined by the agent.transaction.pool.max property.

Bindings: arm40c, arm40java, arm40c#.

agent.transaction.pool.max
maximum number of transaction instances which are allocated by MyARM. If this limit is reached and the instrumented application starts a new transaction measurement, an error is returned and the transaction dropped counter is increased by one.

Default is 1024. Minimum is 512, Maximum is 8192.

Bindings: arm40c, arm40java, arm40c#.

agent.transaction.waiting
waiting time in milliseconds to try to process an transaction before dropping it. In environments with high measurement frequencies increasing this waiting time will result in less dropped transactions.

Default is 1 millisecond. Minimum is 0 (disabling waiting), Maximum is 1000.

Bindings: arm40c, arm40java, arm40c#.

agent.metric.pool.size
number of pre-allocated metric instances for the metric pool. Increase this value if high frequency transaction measurement with metrics are expected. When the instrumented application stops or the resource watchdog concept is enabled, a short message is written to the log file which reports the number of used metric instances. With this information, it is possible to adjust the initial metric pool size so that no memory allocation is needed during runtime.

Default is 64. Minimum is 16, Maximum is defined by the agent.metric.pool.max property.

Bindings: arm40c, arm40java.

agent.metric.pool.max
maximum number of metric instances which are allocated by MyARM. If this limit is reached and the instrumented application tries to allocate new metrics a warning is returned and the metric dropped counter is increased by the number of metrics that could not be allocated.

Default is 512. Minimum is 256, Maximum is 4096.

Bindings: arm40c, arm40java.

agent.log
configures the logging facility of the agent. See appendix "Configuring log facility" for details.

Bindings: arm40c, arm40java, arm40c#.

agent.log.datasink.level
configures the logging level of log messages which also should be written to the datasink and not only to the configured logging destination. With this feature, logs can be centralized within the configured database.

Default is error.

Bindings: arm40c, arm40java, arm40c#.

agent.filestorage
configures the agent to use (true) or not to use (false) the file storage concept for temporarily storing ARM data if the configured datasink is not available.

Default is true.

Bindings: arm40c, arm40java.

Configuring agent binding API

agent.binding.api.return_ok
boolean which defines whether all API calls should return ok (zero) even if an error was detected.

Default is false.

Configuring the log facility

ARM postulates that in any circumstance the instrumented application has to continue working regardless of errors within the ARM agent or with the current instrumentation. Therefore any error or inconsistency within the ARM agent has to be hidden from the application. But in many situations the instrumentor should know if an error occurred within the ARM agent. Therefore, MyARM supports error and information reporting which can be configured using the following configuration parameters:

<component>.log.type
Specifies the type of the reporting facility. One of the following types can be used:
none
No reporting at all
file
Reports to the file specified via log.file
syslog
Reports to the system log service (Unix)
stderr, stdout
Reports to standard error/output (file) channel (Unix)
<component>.log.level
Specifies the level of detail for logging. Currently the following levels are supported:
none
no logging at all
error
only log errors
warning
log warnings and errors
status
also log status information
info
some more information
config
log the read configuration of the different MyARM components
max
maximum logging information
<component>.log.datasink.level
Specifies the log level for which log messages should also be reported to the datasink (e.g. will be stored in the centralized database). Default is error.
<component>.log.file
Specifies the file to write any reporting information to.
<component>.log.file.mode
Specifies the mode to open the file specified via log.file. Mode can be either "w" to open the log file and possibly truncate the existing file or "a" to append to the existing file.
<component>.log.file.size
If log.file.generation is enabled, this property specifies the maximum size of the log file in bytes. If this limit is reached, a new log file will be opened.

Default is 1048576 (1MB).

<component>.log.file.generation
Specify the maximum number of log files which will be generated by the MyARM log component. In conjunction with the log.file.size property, MyARM will not use more bytes of hard disk space than the arithmetic product of these two properties. If this property is zero, the log file generation rotation is disabled and only one log file will be used. The latest log file has a suffix of .0 and the oldest log file generation has a suffix of .<generation>-1.

Default is 5.

<component>.log.format
Specifies a template string used to format the log message. The following format specifiers can be used:
%A
is replaced with the name of the MyARM application (e.g. myarmdaemon). For the agent log the last registered application definition name is used.
%P
is replaced with the current process id.
%H
is replaced with the current host name.
%T
is replaced with the internal thread id.
%C
is replaced with the component name.
%N
is replaced with the log message number.
%I
is replaced with the log message ID.
%M
is replaced with the log message. If this specifier is omitted, the log message is appended at the end of the line.
<component>.log.show.level
Indicates that the log level should be logged (true) or not (false).
<component>.log.show.time
Indicates that the time of the log should be logged (true) or not (false).
<component>.log.flush
Specifies, if true, that after each log message a flush should be performed so that it is immediately written to its destination without any buffering. Error log messages will be flushed always.
<component>.log.syslog.facility
Specifies the facility to use for syslog service. It supports 'local0' to 'local7' and 'user'. Default is 'user'.

Configuring the resource watchdog

The following configuration properties controls logging of resources:

<component>.resource.watchdog.period
defines the period to log the resource usage. If the period is zero, the resource usage is only reported on program termination.

Default is 5m (5 minutes), minimum is 0s (0 seconds), maximum is 1h (1 hour).

<component>.resource.watchdog.log.entities
boolean which indicates to log (true) recorded, processed, stored and read entities or not (false).

Default is false.

<component>.resource.watchdog.log.tranpool
boolean which indicates to log (true) transaction pool allocation or not (false).

Default is true.

<component>.resource.watchdog.log.metricpool
boolean which indicates to log (true) metric pool allocation or not (false).

Default is false.

<component>.resource.watchdog.log.armdatapool
boolean which indicates to log (true) ARM data buffer pool allocation or not (false).

Default is true.

<component>.resource.watchdog.log.dropped
boolean which indicates to log (true) dropped entities or not (false).

Default is true.

<component>.resource.watchdog.log.transaction.calls
boolean which indicates to log (true) number of calls to the appropriate ARM 4.0 C transaction function calls. Especially for arm_start_transaction() and arm_stop_transaction().

Default is true.

The <component> can be either:

Configuring the datasink component

This section describes how to configure a datasink which should be used to store all ARM data. MyARM supports a wide range of different datasinks, therefore the configuration of a datasink depends on its type. The common datasink properties are described below. For specific datasink configuration such as for a MySQL or MariaDB database see the appropriate sections in datasinks.

<name>.type
specifies the type of the datasink (e.g. mysql or sqlite3).

The name placeholder can be replaced by any other word. For example if you use a MySQL database you can use the word db_mysql to clearly specify which datasink you configure. To actually use this datasink configuration just specify the name as the value for the <component>.sink.name property of the appropriate component. For example, to use the MySQL datasink directly from the instrumented application use the following lines in your configuration file:

agent.sink.name = db_mysql

db_mysql.type                = mysql
db_mysql.host                = myhost
db_mysql.user                = myarm
db_mysql.database.definition = MyARM_Def
db_mysql.database.application= MyARM_App
db_mysql.database.transaction= MyARM_Tran
Configuration: MySQL example

Configuring command line tools

The following configuration properties are used to change the behaviour of all command line tools.

tools.source.name
configures the name of the datasource to be used. This property is normally set by a template configuration file. For example the tcp_sqlite3.conf template file contains the following lines: 
# set sink for transporting ARM data to the myarmdaemon
agent.sink.name = sink_tcp
# set myarmdaemon database
daemon.sink.name = db_sqlite3
daemon.source.name = db_sqlite3
daemon.collection.mode = tcp

# set database name for command line tools
tools.source.name = db_sqlite3
tools.sink.name = db_sqlite3

include main.conf
Configuration: TCP SQLite3 template example
tools.sink.name
configures the name of the datasink to be used by all tools (e.g. myarmimport). This property is normally set by a template configuration file. See template example above.
tools.rtformat
configures the response time format used by all tools. See "Configuring response time formats" for details.

Default is ms.

Configuring date formats

Date values can be represented in various ways. MyARM supports the following date formatting patterns. Examples are given for the eleventh December 2009.

DD.MM.YYYY
day.month.year; for example 11.12.2009
YYYY-MM-DD
year-month-day; for example 2009-12-11
MM/DD/YYYY
month/day/year; for example 12/11/2009
DD.MM.YY
day.month.year with two digit year; for example 11.12.09
YY-MM-DD
year-month-day with two digit year; for example 09-12-11
MM/DD/YY
month/day/year with two digit year; for example 12/11/09

Configuring time formats

Time values can be represented in various ways. MyARM supports the following time formatting patterns:

HH:MM:SS
hour:minute:second; for example 16:29:37 for nearly half past four in the afternoon.
HH:MM:SS.ZZZ
hour:minute:second.millisecond; for example 16:29:37.546 for nearly past four in the afternoon including millisecond precision.
HH:MM:SS AP
hour:minute:second; in 12-hour clock notation for example 04:29:37 PM for nearly half past four in the afternoon.
HH:MM:SS.ZZZ AP
hour:minute:second.millisecond; in 12-hour clock notation for example 04:29:37.546 PM for nearly half past four in the afternoon including millisecond precision.

Configuring response time formats

Response times can be in a wide range of time intervals according to their corresponding transactions. For long running transactions it is not useful to display the response time in micro- or even nanoseconds. But if you want to measure low level transactions it may be necessary to use such short time units. For this purpose, you can configure how MyARM tools display and parse response times:

rtfmt can be one of the following strings (letters in parentheses can be omitted):

ns
response times in nanoseconds
µs or mic(s)
response times in microseconds
ms
response times in milliseconds, nanoseconds remainder is omitted
s(ec)
response times in seconds, nanoseconds remainder is omitted
m(in)
response times in minutes, microseconds remainder is omitted
h(our)
response times in hours, microseconds remainder is omitted
d(ay)
response times in days, milliseconds remainder is omitted
MyARM   Copyright © 2005-2021 MyARM GmbH, last change Fri, 17 Dec 2021