View Activities Data Collected by Aternity

Aternity collects a wide range of data for every activity reported. An activity is a user action which you monitor for performance, like a mouse click or a key press, to measure the time until the app's GUI responds, known as the activity response time. In Aternity, you can compare response times in any app across the enterprise, and troubleshoot performance by seeing when they perform slower. For example, you can monitor the launch of an application, or the time it takes for an application to respond to a menu choice.

You can view this information in most Aternity dashboards, including the Troubleshoot Application dashboard, Troubleshoot Activity dashboard and the Activity Resource Analysis dashboard.

There are two variants of Aternity SaaS: the full SteelCentral Enterprise License and the lighter SteelCentral Essentials License. This impacts on the types of activities available:

Type Description
SteelCentral Essentials License

SteelCentral Essentials License offers a ready-to-go version of SteelCentral™, with a focus on Aternity SaaS's monitoring of end user devices. You can add applications for enhanced monitoring, but you can only use predefined activities. To add monitoring for backend servers and create your own custom activities in business applications which are critical to your enterprise, upgrade to SteelCentral Enterprise Licenses.

SteelCentral Enterprise License

A SteelCentral Enterprise License offers complete flexibility to monitor end user devices or backend servers. You can also use predefined activities AND create and monitor your own custom activities in business applications which are critical to your enterprise.

Times Collected for an Activity

For every activity, Aternity measures the following times:

Field Description Source
Activity Response

An activity response is the time taken for an application to complete an activity in seconds.

Activity response time

Use the actual response times (not scores) to check the performance of chronic (long term) problems. You cannot rely on measurements based on the recent baselines, as those responses would be chronically slow for some time, thereby skewing baselines to make those times look normal.

The response times of activities are split into client time ( light blue), and the combination or union of the backend time ( dark blue) and the network time ( blue).

Server, network and client time

The Agent for End User Devices calculates the activity response time by measuring the time between the start event and the end event of an activity, as defined in the activity itself (its signature).

Client Time

Client time is the time used by the device itself as part of an activity to process data before sending its first message request to the server and after the last message response arrives back from the server.

Client time is the time on the device side to process data as part of the activity response

The Agent for End User Devices calculates the client time as the total activity response time minus the infra time.

Infra Time

Infra time is the total time spent outside the client. It starts with the first request to the server and ends when the final response arrives at the client.

Definition of infra time

This field is also known as Total Network Response Time.

The infra time is calculated as the total of network time and backend time. If there are multiple overlapping calls to one or more servers, the total infra time is the combination (union) of all server and network times.

Network Time

Network time is the total time (union) taken for all messages to cross the network in either direction, between the client and the target server, while performing an activity. This does NOT include the time used for processing the request on the server (backend time).

This forms part of an activity's infra time.

Network time is the time for all messages to cross the network and back as part of an activity response

The network time is calculated as the infra time minus the backend time.

Backend Time

Backend time is the time required by all the servers to process data on the backend, which is part of the overall response time of an activity. It starts when the client sends a request to the target server, when the last message of that request arrives at the target server side. It ends when the server sends out the first message of its response.

This forms part of an activity's infra time.

Definition of backend time in a client-server application

The backend time for a single request-response pair is from the last send to its first response minus the round trip time. If the activity calls a server more than once, or several servers, the reported time is the combination (union) of all the individual times together. If the target server calls other back-end servers, Aternity's backend time is the total (union) of all network times and server times of all back end servers in that chain, ending when the activity's target server sends its response to the client. For more server-side visibility, view the transaction details in SteelCentral AppInternals™.

Round Trip Time

Round trip time (RTT) is the time between sending a message to the server and the return of its echo acknowledgment back to the client.

Each request from the client generates an acknowledgment from the server that it received the request. RTT measures the time of a single request and its acknowledgment. It does NOT include the response of the request, which would require the server to process the request.

Aternity displays the Average Network Round Trip Time for all the RTTs performed while the activity is ongoing.

A single message and its acknowledgment, before any server processing

The Agent for End User Devices retrieves the RTT of each server connection from the logs of the Windows TCP/IP driver.

It also reports the time stamp when the activity occurred:

Field Description
Measurement Time

An activity's measurement time is the time stamp when the Agent for End User Devices on the device noted the occurrence of the activity. The time stamp is translated to the time zone of the Aggregation Server.

Server Analysis Time

Displays the timestamp when the Aternity servers received the report of an activity and analyzed it.

Measurements Accompanying an Activity

Alongside the core times of an activity, Aternity also collects several measurements which happen at the same time as the activity.

Field Description
CPU Usage of Application during Activity

View the percentage CPU utilization of this Windows process while it performs an activity, measured as a percentage of the total power of all CPU cores available.

During an activity, if an application uses resources (x% CPU or RAM), or sends x MB of network traffic, it is not the same as saying that it is because of the activity. They happen at the same time, so they are correlated (see Correlation vs. Causation). However, you can be reasonably confident that these device measurements occurred because of the activity.

Physical Memory (RAM) Usage of Application During Activity

View the amount of working set memory for this Windows process while it performs an activity. REST API returns memory usage values in bytes.

If the activity always coincides with a spike in memory consumption, this is probably the cause of slow performance.

During an activity, if an application uses resources (x% CPU or RAM), or sends x MB of network traffic, it is not the same as saying that it is because of the activity. They happen at the same time, so they are correlated (see Correlation vs. Causation). However, you can be reasonably confident that these device measurements occurred because of the activity.

Network Incoming / Outgoing Traffic

Aternity reports the total volume of network traffic in KB in both directions while an application performs an activity.

Remote Display Latency

The remote display latency is the average time taken for the round trip of a network data packet to travel between the front line user and a virtual server (both ways).

Practically, it is the time between performing an action in a virtual session on the front line user's machine, then sending that action to the virtual desktop server (VDI) or virtual application server, and then viewing that action back on the front line terminal again. This does NOT measure the time for the application to respond.

Effective response time of a VDI end user
Server Hostname

Displays the actual hostname of the server (NOT its DNS alias), when an application on the device contacts a server. For example, on a device using Outlook 365, the hostname might be outlook-emeacenter.office365.com while its DNS name is shortened to outlook.office365.com. This is a clearer definition to replace Target Server.

If you contact more than one server during an activity, it reports the server whose total backend time was longest during that activity.

Server IP

Displays the IP address of the server, when an application on the device contacts a server. For example, on a device using Outlook, it displays the IP address of the Exchange server. This is a clearer definition to replace Target Server.

If you contact more than one server during an activity, it reports the server whose total backend time was longest during that activity.

Server Name

Displays the DNS alias of the hostname of the server (not the computer's actual hostname), when an application on the device contacts a server. For example, on a device using Outlook 365, the DNS name might be outlook.office365.com while its full hostname might be outlook-emeacenter.office365.com. This is a clearer definition to replace Target Server.

If you contact more than one server during an activity, it reports the server whose total backend time was longest during that activity.

Target Server

Displays the name or IP address of the server which the device contacted as part of performing the activity. For example, if the activity is in SAP, this field would display the FQDN of the SAP server.

This is used for backward compatibility, but is now more clearly defined In the Server Hostname, Server IP and Server Name fields.

If you contact more than one server during an activity, it reports the server whose total backend time was longest during that activity.

Virtual Memory Usage of Application During Activity

View the amount of reserved memory (commit size) for this Windows process, while it performs an activity. REST API returns memory usage values in bytes.

If the activity always coincides with a spike in memory consumption, this is probably the cause of slow performance.

During an activity, if an application uses resources (x% CPU or RAM), or sends x MB of network traffic, it is not the same as saying that it is because of the activity. They happen at the same time, so they are correlated (see Correlation vs. Causation). However, you can be reasonably confident that these device measurements occurred because of the activity.

Activity Scores and Statuses

Aternity uses the collected data to calculate statuses and scores based on established baselines, as detailed below:

Field Description
Activity Score

The activity score is a value (0-100) which summarizes the statuses of all activity response times into a single value.

Use the score to measure short term (acute) recent or sudden changes from regular performance (baselined or manually predefined). For example, if a mail usually opens in 1.5s, (the baseline response time), it creates a minor baseline (small departure from the baseline) and a major baseline (significant departure). If performance is suddenly (acutely) much slower, like 5s, it would be beyond the major baseline, and therefore have a red status with a low score.

Use the actual response times (not scores) to check the performance of chronic (long term) problems. You cannot rely on measurements based on the recent baselines, as those responses would be chronically slow for some time, thereby skewing baselines to make those times look normal. In this example, if the activity for opening mails has been 5s for several weeks, Aternity adjusts its baselines to 5s, so this now looks normal, and therefore has a green status with a good score, which is misleading.

Aggregating many end user activities into a single score and status
Activity Status

The status of an activity is based on one response time compared to the recent expected response time (baselined or manually predefined). The statuses are measured in severity: Normal , Minor , Major or Critical .

Activity response measured time with a status
SLA Activity Status

The SLA status of an activity determines if the response time complies with the SLA requirement (colored green ), or if it crossed the internal SLA threshold showing you risk breaking the SLA (colored yellow ), or if it crosses the external SLA threshold showing you have broken your SLA (colored red ).

SLA internal and external thresholds