Transport

Transport datasinks

In the following transport datasinks for performance improvement of delivering ARM data to storage datasinks are described briefly.

Null datasink

The null datasink is a really no operation datasink. Say you have setup a complete environment with ARM instrumentation enabled, but in some circumstances you want no transactions to be measured. Just configure the use of this null datasink and no data will be recorded at all:

# agent uses a datasink named noop
agent.sink.name = noop
# noop defines a null datasink type
noop.type = null

That's all!

Route datasink

The route datasink can be used to route measured data to more than one datasink. This can be useful in many cases. For example you want to store all measured ARM data in a database, but also to be passed through the trigger datasink to trigger some action based on measurements. The following properties can be used for the route datasink: .

<name>.sinks

specifies a list of datasink names to route data to. For example:

# agent uses a datasink named sink_route
agent.sink.name = sink_route
# sink_route defines a route datasink type
sink_route.type = route
# the following sink names are configured for the route sink.
sink_route.sinks = tcp1 trigger1
# route all transaction of the application ImportantApp to the
# trigger sink
trigger1.filter.tran = filter tran=ImportantApp:*
# a TCP datasink sending all ARM data to a running myarmtcpd
tcp1.type = tcp
tcp1.host = myhost
tcp1.port = 10815
# a Trigger datasink logging all failed transactions
trigger1.type = trigger
trigger1.tran.list = failed
trigger1.failed.filter=match tran=*:* {tran.status==tran:failed}
trigger1.failed.execute= log: %a.%t failed

<sinkname>.filter.app

defines a filter application and transaction instances for the sink named sinkname .

<sinkname>.filter.tran

defines a filter transaction instances for the sink named sinkname.

Routing filter

For both application and/or transaction filter the following EBNF grammar describes the syntax of the filter where the following terminals are

APPNAME

application definition name of the current transaction or an asterix for matching any application definition name.

TRANNAME

transaction definiiton name of the current transaction or an asterix for matching any transaction definition name.

Thread datasink (New since "1.3.x.0")

The thread datasink is to run a configured number of threads to parallelise the processing of ARM data to a destination datasink. For example if you use a database on a multi-core or multi-processor machine you can start more than one thread to write ARM data to the database. Each thread will open its own database connection and therefore the database will serve each thread as a single client. In addition to the standard datasink properties the thread datasink uses the following properties:

<name>.number (New since "1.3.x.0")

specifies the number of threads to start. Default is 4. Minimum is 2. Maximum is 64. Default is 32. Minimum is 16. Maximum is 1024.

<name>.sink.name (New since "1.3.x.0")

name of the destination datasink for each thread.

<name>.queue.size (Obsolete since "1.4.x.2")

Configuration example

# agent uses a datasink named sink_thread
agent.sink.name = sink_thread
# set up sink type
sink_thread.type = thread
# set up number of threads to start
sink_thread.number = 4
# each thread opens an own connection to the MySQL database sink.
sink_thread.sink.name = db_mysql

TCP datasink

The tcp datasink is used in conjunction with the myarmtcpd tool. It connects to the myarmtcpd program and hands all ARM data to the myarmtcpd process through a TCP socket connection. Note that the tcp datasink retries to connect to the myarmtcpd daemon periodically as long as ARM data available to send to the myarmtcpd daemon. If there is no ARM data available to send for at least <name>.connection.idle time the connection is closed.

In addition to the standard datasink properties the tcp datasink uses the following properties:

<name>.host

name of the host to connect to the myarmtcpd process. Default is localhost.

<name>.port

port number the myarmtcpd process is listening and accepts connections. Default is 5557.

<name>.connection.idle (New since "1.3.x.0")

number of seconds to wait before closing the connection to the myarmtcpd if no ARM data needed to be send. Default is 300s. (New since "1.3.x.7") is the minimum of 30s and the maximum of 3600s for the connection idle time.

<name>.connection.keepalive (New since "1.2.x.5")

number of seconds to send a keep alive message to the myarmtcpd if no ARM data are send. Default is 60s. (New since "1.3.x.7") is the minimum of 30s and the maximum of the half of the <name>.connection.idle property for the keepalive time.

<name>.connection.reconnect (New since "1.4.x.0")

defines an interval value in seconds to wait before MyARM retries to connect to the myarmtcpd process again. Default is 30 second, the minimum is 10s and the maximum is 300s.

<name>.readwrite.timeout

timeout value in milliseconds to wait for reads or writes of ARM data through the connection. Default is 500ms. (New since "1.4.x.2") is the minimum of 250ms and the maximum of 2000ms.

<name>.reply.timeout (New since "1.3.x.7")

timeout value in milliseconds to wait for a reply from the myarmtcpd daemon. Default is 2000ms, the minimum is 500ms and the maximum is 4000ms.

<name>.connection.deferred (Obsolete since "1.3.x.7")

Configuration example

# agent uses a datasink named sink_tcp
agent.sink.name = sink_tcp
# set up sink type
sink_tcp.type = tcp
# set up host myarmtcpd is running on
sink_tcp.host  = localhost
# set up port myarmtcpd is listening for incoming connections
sink_tcp.port = 5557
# read/write time out interval in milliseconds
sink_tcp.readwrite.timeout = 1000
# the interval for reconnecting to the daemon in seconds
sink_tcp.connection.reconnect = 60