This screenshot displays measurements of a Python CDDB example. Transactions are drawn as colored boxes, the invocation order is indicated by vertical position.

1. Specification for the time period to be analyzed.
2. Show measurement for a specific system.
3. Restrict shown measurements to those with response times above threshold.
4. Measurements according to filter criteria with coloured ARM status.
5. A specific measurement has been selected (highlighted).
6. Statistical information for ARM transaction CDDB-Query.
7. Response time overview for a set of correlated measurements. Root transaction "HTTP" and several child transactions are displayed as rectangles with different background colours.
8. Percentage distribution of response times per ARM transaction.

This is a screenshot displaying the calling hierarchy of a Python CDDB example in a sequence diagram.

1. The sequence chart showing which application called which functionality within a complete distributed environment:
   1. The root measurement HTTP (also called transaction in the context of ARM) is drawn on the left side of the chart inside the httpd application box (myarm.info).
   2. It calls the CDDB-Request of the PyCDDB application.
   3. The PyCDDB application connects (DB-Connect) to the CDDB database.
   4. Fetches the discs (Fetch-Discs) ...
   5. ... and tracks (Fetch-Tracks).
   6. Finally, generate the output (Generate-Output).
2. On the right side of the chart the box with light blue background shows all context properties of the root transaction (here HTTP).
3. On the right side of the chart the box on the bottom shows a legend which displays each transaction name with its used color.

This is a screenshot displaying the transaction tree in a tabular layout, indicating the calling hierarchy by the indentation level in the table rows.

1. Specific measurement has been selected (and highlighted).
2. Detailed information associated with the selected measurement.
3. Transaction hierarchy with response time thresholds and a tree depth limited to 3 levels.
4. Percentage distribution of response times per ARM application.

This is a screenshot displaying the use of a filter acting on the URI (thus selecting measurements for CGI programs). In tree view below we have placed the mouse pointer above a coloured box. The associated transaction name and some measurement data are shown in a hover.

1. Filter by dissecting an URI matching the pattern "/cgi-bin/py%".
2. A reduced table with results is shown, notice the "/cgi-bin/" in the column labelled "Identification".
3. Response time overview diagram with hover over DB-Connect.
4. Detail information for DB-Connect after clicking on corresponding box (brown box in left diagram).

This is a screenshot displaying transaction statistics for those transactions with a response time above or equal to 25.0 ms (the unit default to ms but can be changed via preferences). Note that the diagram area at the bottom can be hidden in order to display larger results in the table.≈‚

1. A threshold for the response time has been set (25ms).
2. In the results table, the cells below "Identification" have been drawn with a color according to the application (see box with "Transaction distribution").
3. In the results table, the cells below "RT" have been drawn with a color according to the sigma interval the measurement belongs to.
4. Response times per application with associated colours. Used in the first column in the results table.
5. Transaction statistics (over all transactions) with color coding for five intervals. Used in the next-to-last column. Four of the measurements are slower than the mean value.

This is a screenshot showing a large table with measurements. The widgets on the left and at the bottom have been hidden. Layout-specific information can be saved in the database for reuse.

1. Response time distribution according to transaction. The colours in the pie chart are also used in the results table (below "Identification").
2. All widgets at the left (configuration and filter menus) have been hidden so there is more space for the results table (the Identification column can be quite large).
3. The widgets at the bottom (the diagrams) have been hidden.

This is a screenshot showing how almost the whole display are be used for showing the measurement table. All other widgets have been hidden.

The screenshot displays measurements of a Python CDDB example:

1. In the upper part some CDDB HTTP requests are shown with their start date and time, total response time and execution status (GOOD) executed on myarm.info.
2. In the lower part there is an overview of the response time distribution of the selected (grey) row from (a) shown.
3. The root measurement HTTP also (called transaction in the context of ARM) is drawn on the bottom of the diagram.
4. Any child transaction CDDB-Request of HTTP is drawn on top of it. Therefore a tree of transactions are shown with the leafs, here the Fetch-Tracks on the top.
5. On the top of the diagram the so-called response time overlay is shown. This overlay depicts the response time distribution at a glance.

The screenshot displays measurements of a Python CDDB example:

1. In the upper part some CDDB HTTP requests are shown with their start date and time, total response time and execution status (GOOD) executed on myarm.info.
2. In the lower part there is an overview of the response time distribution of the selected (grey) row from (a) shown. Also a grid (only with vertical lines) is rendered within the response time distribution diagram with a distance of 10ms.
3. The user selected with the mouse the first Fetch-Tracks measurement (ARM Transaction). The legend shows the start time relative to the root measurement (HTTP), the response time and status of the transaction. The details of the selected transaction is shown in (d).
4. The Details-Tab on the right side displays any details of the selected Fetch-Tracks transaction. The light blue highlighted attributes are user defined context values.

The screenshot displays measurements of a Python CDDB example:

1. In the upper part some CDDB HTTP requests are shown with their start date and time, total response time and execution status (GOOD) executed on myarm.info.
2. In the lower part there is an overview of the response time distribution of the selected (grey) row from (a) shown.
3. On the right a pie chart shows the overall response time distribution of the HTTPtransaction tree. The red pie part represents the sum of response times of the Fetch-Tracks measurements shown in (d).
4. The individual Fetch-Tracks response time measurements.

The screenshot displays measurements of a Python CDDB example. The sequence diagram shows a complete calling sequence starting with a request in the HTTP server and ending in several requests for fetching track information for CDs

1. We want to analyze transactions of the type HTTP.
2. The context property named "QueryString" shall contain a value starting with the string "artist".
3. A slow HTTP transaction with a response time greater than two time the mean value (see "Transaction statistics").
4. A custom sequence diagram for the measurement selected in the results table, all transactions are on ARM system myarm.info.
   1. Time axis starting at 0ms, same height as start of HTTP transaction drawn as lilac box. Transaction runs in application httpd.
   2. After about 40ms, the child transaction CDDB-Query starts in the application PyCDDB.
   3. The transactions DB-Connect and Fetch-Discs are started sequentially.
   4. Finally, several tracks are fetched as identified by the transaction Fetch-Tracks.
   5. The root transaction finishes after 261ms.
5. Displaying the context properties of the root transaction.

The screenshot displays measurements of a Python CDDB example. The screenshot shows that detailed information can be displayed for any box in the sequence diagram.

1. The drop down box shows us that there are 3881 measurements for the transaction HTTP in the database (in the selected time-frame).
2. Six measurements match our "Context properties" filter.
3. All diagrams show hovers with additional information pertaining to the element under the mouse pointer.
4. Details are shown for transactions when clicking on their corresponding boxes in the diagram (DB-Connect in our example).

The screenshot displays measurements of a Python CDDB example. The user has chosen to first select a ARM system and then the application.

1. Measurements shall be filtered first by System and then by Application.
2. 8218 measurements are in the database for the selected system myarm.info.
3. 8072 of the measurements are in the database for the application httpd (out of 8218 previously selected measurements).
4. Two of the shown measurements have the status FAILED.
5. One measurement has status ABORTED.

The screenshot displays measurements of a Python CDDB example. The user had first selected a system and then the HTTP application. By setting an appropriate transaction attribute filter, only FAILED transactions are shown in the result table.

1. Measurements shall be filtered first by System and then by Application.
2. 8218 measurements are in the database for the selected system myarm.info.
3. 8072 of the measurements are in the database for the application httpd (out of 8218 previously selected measurements).
4. Using Transaction attribute filters: Show transactions with status equal to "FAILED".
5. All transactions shown in the results table now have status "FAILED".

The screenshot displays an overview of real time statistics for the year 2013 of transaction measurements of a web-site:

1. RTS-Browser time period to aggregate statistics for
2. Coloring controls to adjust cell colors
3. Group names used for grouping transaction statistica
4. Transaction statistics with average response times and indicating cell color

The screenshot displays an overview of real time statistics from december 2012 until november 2013 grouped by month of transaction measurements of a web-site:

1. The transaction names to present statistics for
2. The response time average for each month and transaction
3. Time navigation buttons to browse one month into the future or into the past
4. Buttons to drill down into the appropriate month

The screenshot displays a days overview of real time statistics from of april 2013 of transaction measurements of a web-site:

1. Days are grouped into five working day and two days weekend by adding some margin between these days.
2. Days with no data are rendered in darker gray
3. On April 30th the no disc entries are fetched and the DB-Connect are rendered red, maybe there is a problem with the database?

The screenshot displays a hours overview of real time statistics from of 5th april 2013 of transaction measurements of a web-site:

1. Within this day nobody queried for REM
2. Within the night no measurements were recorded
3. DB-Connect transaction seems to have some problems

The manager with Browser tab opened showing measurements of HTTP transactions of an Apache web server:

1. Grayed tab-buttons are opened, none grayed tab-buttons can be clicked to launch the appropriate web-application (here RTSMonitor).
2. Here the browser tab is shown.

The manager with RTSBrowser tab opened showing aggregated statistics of selected measurements of the year 2014 of a web-site.

The manager with RTSMonitor tab opened showing aggregated statistics of 'todays' last 24 hours of a web-site

The manager with Admin tab opened showing the configured RTS configuration and some error log messages of a web-site